【2026年版】Google Merchant Center補助フィード実装ガイド｜属性不足をあとから埋めてROASを落とさず改善する運用設計
Google Merchant Centerで商品データを運用していて、「主フィードを直接書き換えるのは難しいが、いくつかの属性だけ後付けで上書きしたい」「不承認になった商品のタイトルや説明文を一括で修正したい」「広告運用側だけでカスタムラベルを管理したい」という場面は珍しくありません。こうした「属性を後から差し込む・上書きする」用途で使われるのが、Google Merchant Centerの補助フィード（supplemental feed、別名「補完フィード」）です。主フィードを汚さずに運用要件だけを上書きできる柔軟な仕組みですが、フィードルールとの使い分けや主フィードとの責任分担を誤ると、商品データが二重管理になり、かえって運用工数を増やしてしまう副作用もあります。
本記事では、Google Merchant Centerの補助フィードを「実装と運用の判断軸」まで踏み込んで解説します。公式ドキュメントや一般的な解説記事では触れにくい「主フィードと補助フィードの分業設計」「補助フィードで埋めるべき属性の優先順位」「P-MAX・ショッピング広告のROAS改善との接続」「補助フィードでは解決できない問題の見極め」まで、広告主と運用代行の両方の視点から整理しました。私たちハーマンドットはGoogleショッピング広告・P-MAX・Merchant Center運用代行を継続的に手掛けており、フィード改善でROASを底上げした実例から、再現性のある手順をまとめています。属性不足をあとから埋めて商品データの精度を上げ、広告成果を落とさずに改善したい方は、最後までお読みください。
目次
- Google Merchant Center 補助フィードとは何か：主フィードとの役割の違い
- 補助フィードで埋めるべき属性：実務でよく使う7パターン
- 主フィードと補助フィードの切り分け方：実装テンプレート
- 補助フィードのアップロード方法：手動・スケジュール・API
- 補助フィードを使ったROAS改善の典型シナリオ
- 補助フィードでは解決できないこと：失敗パターンの見極め
- 補助フィードとP-MAX・ショッピング広告の運用接続
- 補助フィードを活かす運用体制と社内ルール
- ハーマンドットがMerchant Center補助フィード運用代行で選ばれる理由
- まとめ：補助フィードで広告成果の土台を底上げする
- まずは無料で広告アカウント診断を
Google Merchant Center 補助フィードとは何か：主フィードとの役割の違い
Google Merchant Centerにおける補助フィード（supplemental feed）は、主フィードに後から属性を追加・上書きするための補助的なデータソースです。主フィードがECカートやPIM、自社CMSから直接出力する「商品データの原本」であるのに対し、補助フィードは「主フィードに足りない情報」「広告運用上の特殊要件」「不承認回避のための上書き」といった目的別の差分情報だけを差し込む役割を担います。ECカート側を改修せずに、運用要件だけを後付けで反映できるため、開発工数を抑えながら商品データを最適化できるのが最大の利点です。
補助フィードはあくまで「主フィードを補強する」ためのもので、単体では機能しません。商品ID（id属性）をキーにして主フィードの商品データと突き合わせ、補助フィード側に書かれた属性だけを上書き・追加するという挙動を取ります。同じ商品IDが両方のフィードに存在し、属性値が異なる場合は補助フィードの値が優先されるのが原則です。この仕様を理解せずに補助フィードを設定すると、想定外の属性が上書きされて広告審査に通らなくなるケースもあります。補助フィードは「主フィードを書き換える権限を持つ強力なツール」だと位置づけて運用設計するのが、後の事故を防ぐ最大のポイントです。
主フィード・補助フィード・フィードルールの3層構造
Merchant Centerの商品データは、主フィード・補助フィード・フィードルールという3層構造で組み立てられます。主フィードが商品データの原本であり、補助フィードがその差分上書きを担い、フィードルールが「正規表現や条件分岐でデータを加工するルールエンジン」として機能します。実務ではこの3層の役割を分けて運用することで、ECカート側に手を入れずに広告運用要件を満たせる柔軟性が得られます。
主フィードはAPI連携・XMLファイル・Googleスプレッドシート連携・FTPの自動取得など多様な方法でアップロードでき、ECサイトの商品マスタを反映する役割を持ちます。補助フィードは主フィードに含まれない属性（custom_label_0〜4、追加画像、配送オプション、価格の例外など）や、主フィードに含まれていても運用上書き換えたい属性（タイトル、説明文、商品カテゴリなど）を差し込む差分データです。フィードルールはアップロード済みのデータに対して、Merchant Center内部で実行される加工処理で、属性のマッピング・正規表現置換・条件付き設定などをコードを書かずに設定できます。
3層の使い分けで迷ったら、まずは主フィードでECカートが自然に出力できる属性をすべて反映し、ECカート側で対応が難しい運用要件を補助フィードで差し込み、最後にフィードルールで全商品共通の軽微な加工（半角全角統一、特定文字列の置換、属性の自動生成など）を行う、という順序で考えると整理しやすくなります。補助フィードとフィードルールはどちらも商品データを加工できるため混同されがちですが、「データ自体を持ち込む」のが補助フィード、「持ち込んだデータに条件付きでルールを適用する」のがフィードルールです。
補助フィードを使うべき典型シーン
補助フィードが本領を発揮するのは、ECカート側の改修コストが高く、なおかつ運用要件が頻繁に変わる場面です。たとえば、楽天・Shopify・自社CMSなどから出力される主フィードの属性は固定されており、広告運用側が独自に管理したいカスタムラベルや、月次キャンペーン用の上書きタイトルを差し込めないことがあります。こうしたケースでは、補助フィードに広告運用専用の差分データだけを入れて主フィードに重ね合わせるのが現実解です。
不承認対応も補助フィードの代表的な用途です。一部商品のタイトルが医薬品的な表現に該当して不承認となった場合、ECカートのマスタを変更すると他チャネルへの影響が出るため、Merchant Center側だけでタイトルを上書きしたいことがあります。補助フィードで対象商品のタイトル属性だけを差し替えれば、ECカートに触らずに不承認を解消できます。同じく、商品カテゴリ（google_product_category）の誤分類を後から修正するのにも補助フィードは有効です。
もう一つの代表用途が、広告運用側で完結したいデータの管理です。カスタムラベル0〜4には、利益率帯・在庫リスク・季節指数・販売チャネル区分など、広告運用者だけが意識する戦略タグを差し込めます。これらをECカート側のマスタに混ぜると本来の商品情報が汚れますが、補助フィードに分離すれば、広告チームが運用ルールを変えるたびにエンジニアへ依頼する必要がなくなります。
Merchant Center全体の構造や、不承認・停止対応については、以下の記事も合わせて確認してください。
補助フィードで埋めるべき属性：実務でよく使う7パターン
補助フィードに入れる属性は無制限ですが、実務でよく使うのは特定のパターンに集約されます。属性ごとに「ECカート側で出すべき」「補助フィードで上書きすべき」の判断基準を整理しておけば、運用が始まってから「どこを直すべきか分からない」迷子状態を防げます。ここでは、運用代行の現場で頻出する7パターンを、補助フィード活用の難易度順に整理します。
| 用途 | 対象属性 | 難易度 | 運用効果 |
|---|---|---|---|
| カスタムラベル付与 | custom_label_0〜4 | 低 | P-MAX・ショッピング広告の入札分割に直結 |
| タイトル上書き | title | 中 | 不承認回避・CTR改善・キーワード強化 |
| 説明文上書き | description | 中 | 不承認回避・関連性スコア改善 |
| 商品カテゴリ修正 | google_product_category | 低 | 誤分類による不承認・配信制限の解消 |
| 追加画像の差し込み | additional_image_link | 中 | 商品リスティングの見え方を強化 |
| 価格・在庫例外 | price / availability | 高 | 特売・限定価格・在庫不一致の調整 |
| GTIN・MPNの後付け | gtin / mpn | 高 | マッチング精度・配信機会の改善 |
カスタムラベルで広告運用の戦略タグを差し込む
カスタムラベル0〜4は、Google Merchant Centerの中でも特に補助フィードと相性が良い属性です。商品本体のマスタには含まれない、広告運用上の戦略タグを5系統まで自由に設定できます。代表的な使い方は、利益率帯（高利益・中利益・低利益）、在庫リスク（過剰在庫・標準・欠品リスク）、販売季節（春夏・秋冬・通年）、新商品フラグ（新商品・既存・廃番予定）、販売チャネル（自社EC専売・Amazon併売・楽天併売）など、運用判断の軸になる情報をラベル化することです。
カスタムラベルが設定されていれば、P-MAXのアセットグループやショッピングキャンペーンの商品グループを、利益率や在庫リスクで分割できるようになります。たとえば、高利益商品のグループだけROAS目標を緩めて配信量を伸ばし、低利益商品はROAS目標を引き締めて利益を確保する、といった経営判断と直結した運用が可能になります。カスタムラベルは設定の難易度が低いわりに改善効果が大きい、補助フィード活用の入り口として最適な属性です。
タイトル・説明文の上書きで不承認とCTRを同時に改善
タイトル（title）と説明文（description）の上書きは、補助フィードでもっとも頻繁に使われる用途のひとつです。ECカートが出力する商品名には、医薬品的な訴求や効果効能を断定する表現、競合との比較を匂わせる文言など、Google広告のポリシーに抵触しがちな表現が混ざることがあります。これらが原因で不承認になった商品を、ECカート側のマスタに手を入れずに補助フィードでタイトルだけ書き換えれば、他チャネルへの影響を遮断したまま広告配信を復活させられます。
不承認回避だけでなく、CTR改善目的でのタイトル上書きも実務で多く使われています。ECカート側のタイトルが型番中心で検索クエリと噛み合っていない場合、補助フィードで「ブランド名＋商品ジャンル＋特徴＋容量・カラー」のような検索クエリに寄せた表現に書き換えることで、ショッピング広告のCTRが目に見えて改善することがあります。説明文も同様に、ECカート側のSEO向け文章ではなく、広告のショッピングタブで読まれることを意識した短文へ差し替えると関連性スコアの底上げに繋がります。
商品カテゴリと追加画像の補完
商品カテゴリ（google_product_category）の誤分類は、想像以上に成果を毀損します。ECカートのカテゴリ階層とGoogleの標準カテゴリは一致しないことが多く、たとえば「美容家電」のはずが「家電」全般に分類されていると、不承認や配信制限の対象になることがあります。補助フィードで該当商品のカテゴリだけGoogleの正しい階層に差し替えれば、不承認解消と同時に配信母集団も増えるという二重の効果が出ます。
追加画像（additional_image_link）も補助フィードで差し込みやすい属性です。ECカートが1枚しか画像を出していない商品でも、補助フィードで2枚目以降のサブカット画像を追加することで、商品リスティングでの見え方が改善し、CTRが伸びることがあります。撮影が追加で発生するため運用工数はかかりますが、売上構成比の高い主力商品に絞って追加画像を整備すれば、投資対効果は十分に回収できます。
価格・在庫・GTINの例外対応
価格（price）と在庫（availability）の上書きは、補助フィードの中でもっとも慎重な運用が求められる領域です。Google Merchant Centerは、フィードの価格・在庫とランディングページの表示価格・在庫が一致しているかを自動でクロール検証しており、ここに乖離があると不承認・停止のリスクが上がります。原則としてECカートが出す主フィードの値を信頼すべきですが、フラッシュセールや一時的な特価販売など、主フィードが追従しにくい例外的なタイミングだけは補助フィードでの上書きが現実解になります。
GTIN（JAN・EANなどの国際商品識別コード）とMPN（メーカー型番）の後付けは、特に並行輸入品やオリジナルブランドで重要です。これらが空欄のまま運用していると、Googleが商品をユニークに識別できず、ショッピング広告の関連商品グルーピングや、AI最適化の精度が下がります。補助フィードでGTIN・MPNだけを別管理シートから差し込めば、ECカートの仕様を変更せずに識別子だけを補えます。並行輸入や少量輸入のEC事業者では、補助フィードによるGTIN補完が広告成果を大きく動かす隠れた打ち手になります。
主フィードと補助フィードの切り分け方：実装テンプレート
補助フィードを使いこなす最大のコツは、「どの属性を主フィードに残し、どの属性を補助フィードに移すか」の切り分け基準を最初に決めることです。基準が曖昧なまま補助フィードを増やすと、同じ属性が両方に存在して片方が片方を上書きする状態が生まれ、デバッグが極端に難しくなります。実装段階で4つの判断軸を整理し、運用ルールとしてドキュメント化しておくのが、補助フィード運用を破綻させないための最短ルートです。
主フィード vs 補助フィードの切り分け4基準
- 変更頻度：日次以上で変わるなら主フィード、月次以下なら補助フィードでも可
- 変更主体：ECカート管理者なら主フィード、広告運用者なら補助フィード
- 他チャネルとの整合性：Amazon・楽天と同期すべきなら主フィード、Google広告だけなら補助フィード
- 事故時の影響範囲：間違ったときに在庫表示が崩れるリスクがある属性は主フィード固定
主フィードに置くべき属性と補助フィードに移すべき属性
主フィードに置くべきは、商品データの「真実」を表す属性です。商品ID、ブランド、メーカー、JAN、価格、在庫、商品ページURL、商品本体の画像など、ECカートのマスタと一致していないと事故になる属性は主フィードで完結させます。これらの属性を補助フィードで上書きしてしまうと、Merchant CenterとECサイトの間に齟齬が生まれ、Google側のクロール検証に引っ掛かるリスクが高まります。
補助フィードに移すべきは、商品データの「演出」や「分類」を担う属性です。広告運用上のカスタムラベル、検索意図に合わせたタイトル上書き、ショッピング広告のショーケース向けの説明文、追加画像、配送オプションのプロモーション値など、運用都合で頻繁に変えたい属性は補助フィードに置く方が運用ルールを単純化できます。「事業の数字を直接動かす属性は主フィード、運用の表現を担う属性は補助フィード」という原則を貫けば、複数フィードを並行運用しても破綻しません。
商品IDマッチングと突合キーの設計
補助フィードを有効に機能させるには、主フィードと完全に一致する商品ID（id属性）を補助フィード側に持たせる必要があります。商品IDが1文字でもずれていれば突合できず、補助フィードの値はMerchant Centerに無視されます。Shopifyや楽天・Yahoo!ショッピングなど、IDのフォーマットがプラットフォームごとに微妙に違うECカートでは、補助フィードを作る前にIDの完全一致をスプレッドシートで検証する工程を必ず入れる必要があります。
同一商品が言語別・地域別に複数IDで管理されているケースでは、補助フィードを地域・言語ごとに分けるのが基本設計です。Merchant Center側で対象国・対象言語をフィードごとに指定できるため、補助フィードをグローバル展開の規模感に応じて分割すれば、管理コストを抑えながら大規模運用も可能になります。グローバルEC事業者では、地域ごとの補助フィードに分けることで、地域別のキャンペーンや特売・税率の違いを柔軟に反映できるようになります。
運用開始前のチェックリスト
補助フィード運用を始める前に、運用設計のチェックリストを通しておくと事故率が大きく下がります。属性別の切り分けが終わっていること、商品IDの突合検証が済んでいること、フィードルールとの優先順位が決まっていること、変更ログの管理体制が決まっていること、Googleシート・FTP・Content APIなどアップロード方法が決まっていること、これら5項目を入稿前に確認するルールを置きます。
補助フィード運用 開始前チェックリスト
- 属性別の役割分担表が完成しているか（主フィード / 補助フィード / フィードルール）
- 商品IDが主フィードと補助フィードで完全一致しているか
- 補助フィードとフィードルールの適用順序が文書化されているか
- 変更履歴をGoogleシートのバージョン管理またはGitで残しているか
- アップロード経路（手動 / スケジュール / FTP / Content API）が決定済みか
補助フィードのアップロード方法：手動・スケジュール・API
補助フィードをMerchant Centerに取り込む方法は、運用規模に応じて4種類から選びます。Googleスプレッドシート連携、ファイルの手動アップロード、FTPやURLからのスケジュール取得、Content API for Shoppingを使ったAPI連携、それぞれにメリットと制約があります。日次運用するなら手動アップロードは非推奨で、商品数が数千件を超えるならスプレッドシート連携もパフォーマンス上の制約に当たるため、運用規模で適切な経路を選ぶことが重要です。
Googleスプレッドシート連携での運用
もっとも手軽に始められるのが、Googleスプレッドシートと補助フィードをリンクさせる方法です。Merchant Centerの管理画面から補助フィードを新規作成する際、データソースとしてGoogleスプレッドシートを選び、自動生成されたテンプレートにデータを記入するだけでアップロード経路が完成します。スプレッドシートを更新すれば、最短15分・最長24時間以内にMerchant Centerに反映されます。商品数が数百から数千件規模、変更頻度が週次から月次の運用ではこの方法がコストパフォーマンス的に最適です。
スプレッドシート連携の制約は、行数が大きくなると更新が遅延しやすいこと、複数人で同時編集すると行ズレや属性破壊が起きやすいこと、変更履歴の追跡がGoogleシートの履歴機能に依存することです。1万行を超えるような規模では、CSVファイルのアップロードやAPI連携に切り替えるべきタイミングが来ます。チーム編集の事故を防ぐには、編集権限を最小限に絞り、編集前にバックアップシートをコピーするルールを徹底することが効果的です。
スケジュール取得・FTPでの自動化
商品数が大きく、自社のECカートやPIMから定期的にファイルを書き出せる体制が整っているなら、FTP・SFTP・HTTPSのURLからMerchant Centerが指定時刻にファイルを取得する「スケジュール取得」が向いています。1日1回、深夜帯にECカート側で補助フィード用のCSVを自動生成し、Merchant Centerが翌朝それを取得して反映する、というオペレーションが組めます。
スケジュール取得の前提条件は、補助フィード用のCSVを安定して生成できるバッチ基盤があることです。ECカートのデータベースから差分を抽出する処理、属性のフォーマット変換、CSVへのエクスポート、FTP/SFTPサーバへの配置までを自動化できれば、運用は劇的に楽になります。一方で、バッチが失敗した日にMerchant Center側が古いデータをそのまま使い続けるリスクがあるため、生成失敗時の通知設計とフォールバック手順は事前に設計しておく必要があります。
Content API for Shoppingでの大量更新
大規模ECで数万〜数十万商品を扱う場合は、Content API for Shoppingを使ったプログラム連携が現実解です。Merchant Centerの管理画面を介さずに直接APIで商品データを送信できるため、リアルタイム性・スケーラビリティ・エラーハンドリングの自由度が桁違いに高まります。補助フィード相当の差分データもAPI経由で扱えるため、ECカートのバックエンドとMerchant Centerを密結合させた運用が可能になります。
API連携のハードルは、エンジニアリングリソースが恒常的に必要なことです。APIスキーマの変更追従、認証情報の管理、エラー時のリトライ設計、レートリミット管理など、運用に乗せるには相応の体制が求められます。広告運用代行と並行してContent API連携の保守も外部委託したい場合は、Merchant Center運用に強い代理店を選ぶことが前提条件になります。規模が大きい事業者ほど、補助フィードの自動化はAPI連携で完結させた方が、長期の運用コストが下がります。
大量商品のフィード運用については、商品フィード最適化全般の考え方も合わせて参照してください。
補助フィードを使ったROAS改善の典型シナリオ
補助フィードの真価は、単なる属性補完ではなく、広告成果の改善に直結する活用にあります。ここでは、私たちが運用代行で実際にROASを底上げした典型シナリオを3つ紹介します。いずれもECカート側を改修せずに、補助フィードだけで完結する打ち手であり、再現性が高いものを選んでいます。
不承認商品をタイトル上書きで復活させる
美容・健康・ファッション領域のECでは、商品タイトルの一部表現がGoogle広告のポリシーに抵触して不承認になるケースが恒常的に発生します。ECカートのマスタを書き換えると、Amazonや楽天への商品データ連携にも影響が出てしまい、業務調整が複雑化します。このような場合、補助フィードで該当商品のtitle属性だけを安全な表現に差し替えれば、Merchant Center側だけで不承認を解消できます。
具体的な手順は、不承認商品リストをMerchant Centerからエクスポートし、対象商品のIDと差し替え後のタイトルだけを記載した補助フィード用のCSVを作成、Googleシート連携でアップロードする、というシンプルなものです。重要なのは、Googleが不承認の理由として挙げた具体的な表現を、ポリシー違反にならない言い換えに置き換えること、そして広告審査の再申請時に該当のキーワードを意図的に取り除いた表現にしておくことです。不承認の3〜5割は補助フィードによるタイトル上書きで復活でき、これだけで広告母集団が一気に増えるケースがあります。
カスタムラベルで広告グルーピングを最適化
P-MAXやショッピング広告の入札を細かくコントロールするには、商品をどう分類するかが鍵になります。利益率帯・在庫リスク・販売季節などの戦略軸でカスタムラベルを設定すれば、それを使って広告グループやアセットグループを分けられるようになります。たとえば、高利益商品にcustom_label_0 = “high_margin”、低利益商品に “low_margin” というラベルを補助フィードで設定し、P-MAX側でラベルごとにキャンペーンを分割すれば、利益率に応じたROASターゲット運用が可能になります。
カスタムラベルが設定されると、商品グループの粒度を運用要件に合わせて自由に設計できます。これまでは「全商品を1つのキャンペーンで配信せざるを得ない」状態だった事業者でも、補助フィードでラベルを差し込むだけで「高利益商品キャンペーン」「在庫過剰商品キャンペーン」「新商品キャンペーン」のように事業戦略に直結した運用に切り替えられます。広告予算の配分が利益と整合するため、同じ広告費でも事業利益への寄与度が大きく変わります。
価格・在庫の例外対応で機会損失を抑える
フラッシュセールや短期間の特売、限定地域でのキャンペーン価格など、主フィードが追従しにくい一時的な価格変更にも補助フィードは有効です。ECカート側の主マスタを変更すると後で戻し作業が必要になり、運用が煩雑になります。補助フィードで対象期間だけ価格属性を上書きし、キャンペーン終了後に補助フィードのデータを削除すれば、主マスタを汚さずに期間限定価格を反映できます。
同様に、特定地域だけの在庫例外、店舗受け取り限定の在庫表示、配送オプションのプロモーション値なども補助フィードで処理できます。Merchant Centerは商品の地域フィードや配送フィードも補助的に差し込む仕組みを用意しており、これらと組み合わせることで「地域×期間×商品」の細かな例外を運用フローに組み込めます。機会損失を最小化したいECでは、補助フィードでの例外対応を運用カレンダーに組み込むことが標準オペレーションになります。
補助フィードでは解決できないこと：失敗パターンの見極め
補助フィードは強力なツールですが、何でも解決できる魔法ではありません。むしろ、補助フィードに頼ろうとして根本問題から目を逸らしてしまうと、長期的に成果が頭打ちになります。ここでは、補助フィードでは解決できない領域を整理し、別のアプローチを取るべきタイミングを示します。
商品データそのものの欠陥は補助フィードでは直らない
そもそも商品画像が低画質、商品ページの内容と商品情報が一致していない、商品ページがクロールできない、価格表記がランディングページと根本的に乖離している、といった「商品データの土台が崩れている」問題は補助フィードでは解決できません。これらはECカート側、もしくは商品マスタの整備で根本対応する必要があります。補助フィードで表面的に取り繕っても、Googleのクロール検証で再び引っ掛かるため、いつまでも不承認のループから抜け出せません。
商品ページのコンテンツ品質が低い場合、補助フィードで広告側のタイトルや説明だけ綺麗に整えても、ランディングページの品質スコアが上がらないため、結果として広告ランクが低位に留まります。商品の魅力を伝える写真・説明文・スペック表・レビューなど、ランディングページ側の改善とMerchant Centerの補助フィードによる広告表現の改善を、両輪で進める必要があります。
ポリシー違反の根本対応は補助フィードでは対応不可
禁止商材・規制商材を扱っている、効果効能の断定表現で薬機法に抵触している、誇大広告や根拠のない競合比較を行っている、といったポリシー違反は補助フィードでタイトルを書き換えても解決しません。Googleはランディングページのコンテンツも審査対象としており、表面的な言い換えでは長く配信を維持できないのが現実です。ポリシー違反は、商品自体の取り扱い見直し、ランディングページの全面改修、社内のリーガルチェック体制の構築、といった根本対応に踏み込む必要があります。
美容・医療・健康・金融・ギャンブルなど審査が厳しい領域では、補助フィードでの応急処置に頼り過ぎず、商品データそのものを設計段階からGoogle広告ポリシーに準拠させるアプローチが必要です。私たちが運用代行する案件でも、規制業種では商品仕様書のレビューから入り、Merchant Centerに乗せる前の段階で表現を整えるオペレーションを組んでいます。
フィードルールで対応すべきケースとの切り分け
補助フィードとフィードルールは似た領域をカバーしますが、用途は明確に分かれます。「特定商品の特定属性を個別に上書きしたい」のが補助フィードの守備範囲、「全商品に共通の変換ルールを適用したい」のがフィードルールの守備範囲です。たとえば、半角全角の統一、特定文字列の一括置換、属性の組み合わせから新しい属性を生成する処理は、フィードルールで実装すべきです。これらを補助フィードで処理しようとすると、商品ごとに行を作る必要があり、運用コストが爆発します。
逆に、商品ごとに異なる値を個別に入力する必要がある属性、たとえば商品Aだけタイトルをこう書き換えたい、商品Bだけ追加画像をこのURLにしたい、といった個別最適は補助フィードでないと表現できません。「全商品共通か、特定商品限定か」が補助フィードとフィードルールの分岐点で、これを誤ると運用コストが数倍に膨らみます。
補助フィードとP-MAX・ショッピング広告の運用接続
補助フィードで属性を整えただけで満足してしまうと、せっかくの改善が広告成果に繋がりません。補助フィードのデータを前提に、P-MAXやショッピング広告の運用設計を組み直すところまでセットで進めるのが、ROAS改善の正しい道筋です。ここでは、補助フィードと広告キャンペーンの接続パターンを実例で紹介します。
カスタムラベルでアセットグループ・キャンペーンを切る
補助フィードでcustom_label_0〜4を設定したら、P-MAXのアセットグループまたはショッピングキャンペーンの商品グループをそのラベルで分割します。たとえば、custom_label_0 = “high_margin” の商品だけで構成されるアセットグループに対しては、ROASターゲットを200%・300%といった攻めの数値で設定し、配信量を最大化します。一方、”low_margin” の商品アセットグループは ROAS 500%以上といった厳しめのターゲットで、無駄な広告費を抑え込みます。
同様に、季節商品のラベル付けと組み合わせれば、シーズン前から指数を上げて先取り配信、シーズン中はROASターゲットを緩めて配信量最大化、シーズン終了直後は配信を絞って在庫消化に切り替える、という事業サイクルに合わせた運用が組めます。広告運用のオペレーションが、商品マスタとは別軸で柔軟にコントロールできるようになります。
ROASターゲットの設計と入札分割
補助フィードで利益率帯ラベルが付いたら、ROASターゲットは利益率に応じて逆算で設計します。粗利率20%の商品にROAS500%を求めるのは過度に厳しく、機会損失を生みます。利益率30%の商品ならROAS350%程度、利益率15%の商品ならROAS650%程度、というように、商品の利益構造に応じてターゲットを変えれば、同じ広告予算でも事業利益への寄与度が変わります。
P-MAXのスマート入札は、設定されたROASターゲットに沿って入札を調整しますが、ターゲットの設計が雑だと最適化が空回りします。補助フィードでラベルを整え、ラベル別にROASターゲットを変えれば、P-MAXの機械学習が利益軸で動くようになります。補助フィードはP-MAXの入札戦略を「事業利益と連動した運用」に進化させるための土台です。
パフォーマンス計測と継続改善のサイクル
補助フィードで属性を変更したら、変更前後のCTR・CVR・ROAS・配信量・不承認率を必ず比較計測します。属性変更が広告成果に与える影響は商品カテゴリやシーズンによって異なるため、A/Bテスト的に小規模に試して効果を確認してから全商品に展開する手順が安全です。Google Analytics 4と連携してランディングページのコンバージョン率も並行計測すれば、補助フィードの改善が事業のCV数全体にどう響いたかが見えます。
計測サイクルは、変更直後の48時間で初動を確認、1週間で短期影響を測定、4週間で長期トレンドを評価、というステップで進めます。短期で改善が見られても4週間後に揺り戻しが起きることがあるため、必ずスパンの違う3点での評価を行います。改善が確認できた変更だけ標準化して、運用マニュアルに組み込んでいくと、補助フィードを起点にしたROAS改善が再現性のあるオペレーションに育ちます。
P-MAXの入札戦略やショッピング広告のアカウント構成についても、合わせて確認しておくと運用全体の解像度が上がります。
補助フィードを活かす運用体制と社内ルール
補助フィードは仕組みだけ整えても運用に乗りません。誰が変更を提案し、誰がレビューし、誰がアップロードするか、変更履歴をどこに残すか、事故時に誰がロールバックを行うか、というオペレーション設計まで含めて整備して初めて、補助フィードは恒常的な改善ドライバーになります。ここでは、運用代行で繰り返し見えてきた「うまくいく体制」のパターンを紹介します。
役割分担：誰が変更を提案し、誰が承認するか
もっとも事故が起きやすいのは、変更権限を持つ人が一人だけ、もしくは無制限という状態です。広告運用者が自由に補助フィードを書き換えられる体制では、ECチームが想定しない属性が変わって、商品ページとMerchant Centerの間に齟齬が起きやすくなります。最低でも、変更を提案する人とレビュー・承認する人を分け、変更内容をプルリクエスト形式やチケット起票で記録に残す体制が望ましいです。
具体的には、広告運用代行が「補助フィードでこの属性をこう変えたい」という提案票を作り、社内のECチーム責任者が業務影響を確認したうえで承認し、最後に運用担当がアップロードする三段階のフローを敷きます。属性変更の影響範囲が小さい場合は提案票を簡略化し、影響が大きい場合は事前に少数商品でA/Bテストを行う、というように影響範囲に応じてフローの厚みを変えると現実的に運用できます。
月次・週次オペレーションの組み立て
補助フィードを継続的に活用するには、定期的な見直しサイクルを組み込みます。週次では、不承認商品のチェック、カスタムラベルの実態と運用要件のズレ確認、シーズン変動への追従などを行います。月次では、属性別の改善効果のレビュー、ROASターゲットとラベルの整合性確認、補助フィードのデータ量とパフォーマンス指標のクロス分析を実施します。
四半期に一度は、補助フィード全体の棚卸しを行います。古くなったキャンペーン用のラベル、もう使っていない上書き設定、運用要件が変わって不要になったルールなどを整理し、データを軽くしておきます。補助フィードが肥大化すると、Merchant Centerのフィード処理が遅くなったり、変更時のデバッグが困難になったりするため、定期的な掃除は事故予防にも繋がります。
代理店活用を判断するタイミング
補助フィードの設計と運用は、ECカートの仕様理解と広告運用ノウハウの両方が必要なため、社内に経験者がいない場合は外部の運用代行に依頼する方が結果として早道になることがあります。判断軸は、商品数、月間広告費、社内のエンジニアリングリソース、フィード障害時の事業影響の4点です。商品数が数千以上、月間広告費が数百万円以上、社内に専任エンジニアがいない、フィード障害で1日の売上が大きく毀損する事業、これらのいずれかに該当するなら、外部の専門家を巻き込んだ方が安全です。
運用代行に依頼する場合も、Merchant Centerと補助フィードの設計に強い代理店を選ぶことが重要です。リスティング広告の運用は得意でもMerchant Center設計の実績が浅い代理店だと、フィード周りで詰まることが多いため、契約前に「補助フィードの活用事例」「フィード障害対応の実績」「Content API連携の経験」を必ずヒアリングしましょう。補助フィード運用は、広告運用代行の中でもエンジニアリング寄りのスキルが要求される領域です。
ハーマンドットがMerchant Center補助フィード運用代行で選ばれる理由
ハーマンドットは、Google広告・ショッピング広告・P-MAX・Merchant Center運用を組み合わせた総合的な広告運用代行を提供しています。補助フィード単体のコンサルティングではなく、商品データの整備・広告キャンペーン設計・成果計測までを一気通貫で支援することで、短期の改善だけでなく長期のROAS底上げを実現します。Merchant Centerの不承認解消から、P-MAXの利益率連動運用まで、現場で再現性のある手順を持っています。
支援の特徴は、ECカートの仕様調査から入り、主フィードと補助フィードの役割分担を設計してから運用に乗せる点です。多くの代理店は補助フィードを単発のタクティクスとして使いますが、私たちは恒常的な改善ドライバーとして組み込みます。これにより、月次・週次の運用オペレーションの中で補助フィードが自然に成果を生み出す状態を作れます。Merchant Centerの不承認対応・P-MAXの入札戦略設計・Content API連携など、隣接領域も含めた相談が可能です。
広告運用代行の費用感や代理店選びの判断軸については、以下の記事も合わせて参照してください。
まとめ：補助フィードで広告成果の土台を底上げする
Google Merchant Centerの補助フィードは、ECカート側を改修せずに広告運用要件を後付けで反映できる強力な仕組みです。属性の役割分担を明確にし、運用ルールを文書化し、定期的な見直しサイクルを回せば、補助フィードは広告成果の継続的な改善ドライバーとして機能します。属性補完で終わらせず、P-MAXやショッピング広告のキャンペーン設計と接続することで、事業利益と直結した運用が可能になります。
- 補助フィードは主フィードの「差分上書き」専用。役割分担を最初に決めることが事故防止の最短ルート。
- カスタムラベル・タイトル上書き・追加画像など、低リスクで効果の大きい属性から導入するのが王道。
- 商品データの欠陥やポリシー違反は補助フィードでは解決できない。根本対応との切り分けが重要。
まずは無料で広告アカウント診断を
Merchant Centerの補助フィードを活かしきれていない、不承認が頻発している、P-MAXのROASが頭打ちといった課題があるなら、まずは現状のフィード設計と広告アカウントを診断するところから始めるのが現実的です。ハーマンドットでは、補助フィードの設計状況・商品データの欠損・広告キャンペーンの構造を無料で診断し、改善の優先順位を可視化するメニューをご用意しています。
商品データの整備は時間がかかる領域だからこそ、早く着手するほど競合との差が広がります。初回相談は完全無料・所要時間30分・オンライン対応可能です。Merchant Centerと広告運用をまとめて立て直したい方は、お気軽にご相談ください。