--- title: "データフィード広告の運用：カスタムラベルの設計と商品データ自動更新の体制" url: "https://www.issoh.co.jp/column/details/18967/" published: 2026-10-27 updated: 2026-10-27 categories: ["マーケティング"] publisher: "株式会社一創" --- # データフィード広告の運用：カスタムラベルの設計と商品データ自動更新の体制 データフィード広告の運用は、商品データを広告媒体へ送り続け、そのデータの切り方で入札と予算を動かす仕事です。Googleのショッピング広告やP-MAXでは、検索語ではなく商品データが配信の起点になるため、運用者が触るのは管理画面の入札よりもフィードの中身になります。この記事では、Google広告のフィード運用で毎週こなす作業、カスタムラベルで商品グループを分ける設計、最終更新から30日で期限切れになる商品データの更新の仕組み、2026年8月に終了したContent API for Shoppingからの移行を順に整理する構成です。ECや基幹システムの商品マスタからフィードを自動で作る構成と、運用を誰が持つかの判断も示します。 ## まとめ：データフィード広告の運用は商品データの鮮度とラベル設計で決まる データフィード広告の成果を左右するのは、商品データが常に実物と一致していることと、利益や在庫の事情を反映したラベルで商品を分けて入札していることの2点です。入札戦略を自動入札に任せても、どの商品群にいくら使うかの線引きは運用者の設計に残ります。 実務の優先順位ははっきりしています。最初に、価格と在庫をフィードへ毎日流す更新の仕組みを固めること。次に、カスタムラベルで「利益率」「在庫」「価格帯」などの軸を決め、ショッピング広告やP-MAXの商品グループをその単位で分けること。そのうえで、Merchant Centerの診断に出る不承認を週次で潰し、商品単位のROASで月次にラベルを振り直します。 更新の仕組みを手作業のCSVで回しているなら、広告の改善より先に商品マスタからの自動生成に切り替えてください。Content API for Shoppingは2026年8月18日に終了しており、独自連携を持つ企業はMerchant APIへの移行が済んでいるかを確かめる時期です。 ## データフィード広告の運用が指す作業範囲とDFO・出稿判断との役割の違い ### データフィード広告の運用担当者が毎週こなす4つの作業と頻度の目安 データフィード広告の運用は、出稿を始めた後に回し続ける作業を指します。中身は大きく4つで、頻度も違います。 - 毎日：価格・在庫の更新がフィードに反映されているかの確認 - 毎週：Merchant Centerの診断に出た不承認と警告の解消 - 毎月：商品単位の成果を見てカスタムラベルの値を振り直す - 随時：セールや新商品の投入に合わせた商品グループの組み替え このうち、毎日の更新確認は仕組みで自動化できる部分です。人の判断が要るのは週次と月次の2つで、運用担当者の時間はここに寄せます。データフィードという仕組みそのものの定義や、フィードを作る工程（生成・媒体への変換・項目の整備）の切り分けは[DFOの定義とツール料金比較・媒体別フィード仕様の実務](https://www.issoh.co.jp/column/details/7977/)で解説しています。 ### Google広告のフィード運用でMerchant Centerと広告管理画面が持つ役割 Googleのデータフィード広告では、商品データはMerchant Center、配信の設定と入札はGoogle広告の管理画面という分担になっています。フィードの不備は広告管理画面ではなくMerchant Center側で直し、入札や予算はGoogle広告側で動かします。 この分担を知らないと、配信が止まった原因を広告管理画面だけで探して時間を失います。ショッピング広告では、入札をキーワードではなく商品グループに設定します。広告の配信量は「どの商品が承認されているか」と「商品グループがどう切られているか」で決まるわけです。ショッピング広告の仕組みや、出稿そのものを見送るべき商材の条件は[ショッピング広告（PLA広告）の仕組みと出稿判断](https://www.issoh.co.jp/column/details/4900/)にまとめています。検索広告を含む広告運用全般の業務は[広告運用の仕事内容と自動入札時代の役割](https://www.issoh.co.jp/column/details/18126/)を参照してください。 ## カスタムラベルで商品を分けて入札と予算を配分するための運用設計 ### custom\_label\_0〜4の仕様と属性ごとに1,000個までの固有値上限 カスタムラベルは、商品データに運用者が自由な値を付けるための属性です。Merchant Centerのヘルプ[カスタムラベル 0［custom\_label\_0］〜カスタムラベル 4［custom\_label\_4］](https://support.google.com/merchants/answer/6324473?hl=ja)によると、属性は0〜4の5種類で、値は1〜100文字、アカウント全体で属性ごとに最大1,000個の固有値まで登録できます。 上限を超えたラベルは、レポートと入札で考慮されません。商品IDやSKUをそのままラベルの値に入れると、商品数が1,000を超えた時点で入札の分割に使えなくなります。ラベルの値は「高」「中」「低」のように少数の区分にとどめるのが設計の前提です。 ラベルの中身は広告には表示されません。社内の管理用の区分なので、「利益率A」のような社内用語をそのまま入れてかまいません。 ### 利益率・在庫日数・価格帯・季節性の4軸で商品にラベルを振る設計例 5つの枠に何を入れるかは、入札を分けたい理由から逆算します。EC事業者で使われることの多い軸を、値の例と入札への効き方で並べると次のとおりです。 | ラベル | 入れる軸 | 値の例 | 入札での使い方 | | ---------------- | ------- | ---------- | --------------- | | custom\_label\_0 | 粗利率の区分 | 高・中・低 | 粗利の高い群に予算を寄せる | | custom\_label\_1 | 在庫日数の区分 | 過剰・適正・僅少 | 過剰在庫の群を強めに出す | | custom\_label\_2 | 価格帯 | 3千円未満など4区分 | 価格帯別に目標ROASを分ける | | custom\_label\_3 | 季節性 | 春・夏・秋・冬・通年 | 季節外の群を絞る | | custom\_label\_4 | 成果の区分 | 売れ筋・平常・不振 | 月次の振り直しに使う | 実務で最初に入れるべきなのは粗利率です。売上ベースのROASで入札すると、値引き商品や粗利の薄い商品に予算が流れやすくなります。粗利の区分は広告管理画面には存在しない情報なので、商品マスタや原価データから作ってフィードに載せるしかありません。この「広告側に無い社内データを入札に持ち込める」点が、カスタムラベルを設計する最大の理由です。 ### ショッピング広告とP-MAXで商品グループを分ける単位と入札の決め方 Google広告のヘルプ[ショッピング広告でカスタムラベルを使用する](https://support.google.com/google-ads/answer/6275295?hl=ja)のとおり、カスタムラベルを付けると、ショッピングキャンペーンとMerchant Centerのデータを使うP-MAXキャンペーンで、より細かい商品グループを作れます。 分ける単位は、目標ROASや予算を変えたい単位と一致させます。粗利「高」と「低」で目標を変えたいなら、その2つは別の商品グループかキャンペーンに分けます。逆に、同じ目標で回すなら分けません。商品グループを細かくしすぎると、1グループあたりのコンバージョンが少なくなり、自動入札が学習に使えるデータが痩せます。 分割した結果、多くのグループでコンバージョンが月に数件しか付かなくなったなら、分けすぎを疑ってください。ROASの計算式と目標値の置き方は[ROASの計算式・目安とROIとの違い](https://www.issoh.co.jp/column/details/4741/)で確認できます。 ## 商品データの鮮度を保つ更新の仕組みとContent API終了後の移行 ### 最終更新から30日で期限切れになる商品データと更新頻度の決め方 Merchant Centerのヘルプ[Merchant Center アカウントで商品を管理する](https://support.google.com/merchants/answer/14996874?hl=ja)には、アカウント内の商品は最終更新から30日後に期限切れになると書かれています。更新の方法として案内されているのは、商品データソースの再送信か、定期的なアップロードのスケジュール設定です。 30日は「最低限これを下回るな」という線にすぎません。実際の更新頻度は、価格と在庫がどれだけの頻度で動くかで決めます。 - 価格改定や在庫切れが毎日起きるEC：1日1回以上の自動取得 - セールを時間単位で切り替える：API経由で変更分だけを即時送信 - 型番商品で価格がほぼ動かないBtoB：週1回の取得で足りる 在庫切れの商品を「在庫あり」のまま出し続けると、クリック費用を払って売れないページへ誘導することになります。更新頻度の設計は、広告の無駄打ちを止める設計でもあります。属性ごとの必須条件は[商品データ仕様](https://support.google.com/merchants/answer/7052112?hl=ja)が正です。 ### 構造化データによる自動商品更新で補える範囲と補えない価格・在庫の不一致 Merchant Centerには、商品ページの構造化データ（schema.org）を読み取って商品データを直す「自動商品更新」があります。ヘルプ[Merchant Center による商品情報の自動更新について](https://support.google.com/merchants/answer/12157888?hl=ja)によると、対象は価格（price）、セール価格（sale\_price）、在庫状況（availability）、状態（condition）の4属性で、既定で有効です。 ただし、同じヘルプは自動更新を「定期的な商品データ更新の代わりにはならない」と位置づけています。1日に何度も価格や在庫が変わる商品ではうまく働かない場合があり、不一致が多すぎると更新自体が止まる場合もある仕組みです。取り消し線付きの参照価格を誤って読む可能性もあるため、複数の取り消し線価格を表示するページでは価格の自動更新を無効にするよう推奨されています。 結論として、自動商品更新は保険です。フィードの更新が1日遅れたときの穴埋めには効きますが、更新の仕組みを持たない言い訳にはなりません。 ### 2026年8月のContent API終了とMerchant APIへの移行で確かめる点 自社システムからAPIで商品データを送っている企業は、移行の済み具合を確かめてください。Googleの開発者向けドキュメント[Content API for Shopping のスタートガイド](https://developers.google.com/shopping-content/guides/quickstart)には、Content API for Shoppingが2026年8月18日に終了し、2026年9月1日からリクエストに段階的なエラーが出ると明記されています。移行に時間が要る場合の延長申請フォームも案内されています。 後継は[Merchant API](https://developers.google.com/merchant/api/overview)です。商品・在庫・レポート・アカウントなどのsub-APIに分かれた構成で、商品やアカウントの変更をプッシュ通知で受け取れます。認証はOAuth 2.0かサービスアカウント、呼び出しはgRPCとRESTの両方に対応しています。 運用担当者が見るべきは、エラーが出ているかどうかより「フィードの最終更新日時が止まっていないか」です。APIの呼び出しが失敗しても管理画面上は商品が残るため、30日の期限切れが来るまで気づかない恐れがあります。ECカートの標準連携やDFOツール経由で送っている場合は、提供元がMerchant APIに対応済みかを確認すれば足ります。 ## EC・基幹システムの商品マスタからフィードを自動生成する連携構成 ### カート標準連携・DFOツール・自社開発の3構成を比べる判断軸 フィードを作る経路は、ECカートの標準連携、DFOツール、自社開発の3つに分かれます。どれを選ぶかは、ラベルに載せたい社内データがどこにあるかで決まります。 | 構成 | 向いている条件 | 限界 | | ----------- | ------------ | -------------- | | カートの標準連携 | 商品情報がカートに揃う | 粗利などを載せにくい | | DFOツール | 複数媒体へ同時に出す | 月額費用と変換ルールの属人化 | | 商品マスタから自社開発 | 原価や在庫が基幹側にある | 開発と保守の体制が要る | 商品情報がカートの中で完結し、配信先がGoogleだけなら、カートの標準連携で十分です。複数の媒体へ出すならDFOツールが候補に上がり、ツールの種類と料金の水準は[DFOツールの3タイプと料金水準の比較](https://www.issoh.co.jp/column/details/7977/)で比べられます。 自社開発を選ぶのは、粗利や在庫日数のように入札に効く情報が基幹システムや在庫管理システムの側にあり、カートからは取れない場合です。この情報をラベルに載せられないと、前の章で示したラベル設計は絵に描いた餅になります。 ### 基幹の在庫と価格をフィードに流すときに詰まりやすい項目と対処 商品マスタからフィードを作るとき、つまずく場所はほぼ決まっています。開発に入る前に、次の5項目の持ち主を決めておくと手戻りが減ります。 | 項目 | 起きやすい問題 | 先に決めること | | ----- | ------------- | ----------- | | 在庫数 | 倉庫とECで値がずれる | どの在庫を正とするか | | 販売価格 | 税込と税抜が混ざる | 税込で出す変換の場所 | | 商品ID | 型番変更でIDが変わる | 不変のIDを1つ決める | | 画像URL | 差し替えで旧URLが残る | 画像の保管場所と命名 | | 粗利の区分 | 原価が月次でしか確定しない | 区分の更新頻度 | なかでも商品IDは後から直すのが難しい項目です。IDが変わると、Merchant Centerは別の商品として扱うため、それまでに溜まった成果の履歴が引き継がれません。在庫の正をどこに置くかは、複数のECモールや実店舗と在庫を共有する場合に特に揉めます。在庫の引当と管理の仕組みは[在庫管理システムの入出庫管理と引当の仕組み](https://www.issoh.co.jp/column/details/10832/)、複数チャネルの在庫を束ねる範囲は[マルチチャネルにおけるEC多店舗の統合範囲](https://www.issoh.co.jp/column/details/6740/)を参照してください。自社ECとあわせてAmazonにも出品している場合は、広告予算をどちらに寄せるかも決める必要があります。[Amazon広告と自社ECの広告の予算の分け方を確認する](https://www.issoh.co.jp/column/details/18969/)と、計測の限界を含めて判断材料がそろいます。 ## データフィード広告の週次・月次の運用で見る指標と不承認対応の手順 ### 診断画面の不承認と警告を週次で潰すための商品点検手順と優先順位 週次の点検は、Merchant Centerの診断（商品の問題の一覧）から始めます。全件を眺めるのではなく、影響の大きい順に処理します。 1. アカウント単位の問題（警告・停止）が出ていないかを最初に見る 2. 不承認の商品数を、前週から増えた理由ごとに並べる 3. 売上上位の商品が不承認に含まれていないかを確かめる 4. 価格・在庫の不一致は、更新の仕組みの不具合として開発側に回す 5. 属性の不足や画像の問題は、商品マスタの入力ルールを直す 手順4と5を分けているのは、同じ不承認でも直す人が違うからです。不一致の原因の多くは更新の遅れで、フィードを手で直しても翌日の取得でまた同じ値に戻ります。不承認を広告運用者が個別に直し続けている状態は、元データの問題が放置されている兆候です。 ### 商品単位のROASでカスタムラベルを振り直す月次の成果判断基準 月次では、商品単位の成果を見てカスタムラベルの値を振り直します。成果の区分（custom\_label\_4の例）を「売れ筋」「平常」「不振」に分けておくと、振り直しが機械的に進みます。 判断の基準は単純に置きます。クリックが一定数以上あるのに売上がゼロの商品は「不振」に落とし、入札を下げるか配信から外すのが対応方針です。表示回数がほとんど無い商品は、入札より先に商品名や画像などフィードの中身を疑います。ROASが目標を大きく上回る商品は「売れ筋」に上げ、予算を寄せます。 見落としやすいのは、粗利の区分と成果の区分の掛け合わせです。売上のROASが高くても粗利「低」の商品ばかりが売れているなら、広告の利益は出ていません。月次の報告には、売上のROASと粗利ベースの数字を並べて載せてください。広告の効果の測り方全般は[リスティング広告の仕組み・費用と運用の始め方](https://www.issoh.co.jp/column/details/13009/)も参考になります。 ## データフィード広告の運用を内製・代行・開発に分ける判断と見送り場面 ### 広告運用・EC担当・システム担当の責任分担を決める判断の条件 データフィード広告の運用には、広告の運用者、ECの商品担当、システムの担当の3者が関わります。誰が何を持つかを決めないまま始めると、不承認の対応が担当者の間で宙に浮きます。 分担の原則は「データの持ち主が直す」です。入札とラベルの設計は広告の運用者、商品名や画像の品質はECの商品担当、更新の仕組みと基幹からの連携はシステムの担当が持ちます。広告の運用だけを代理店に出す場合も、この原則は変わりません。代行会社の費用体系と選び方は[Web広告の運用代行の費用相場と代理店の選び方](https://www.issoh.co.jp/column/details/16317/)で比べられます。 判断を言い切ると、粗利や在庫の情報が基幹側にある企業が、広告の運用だけを外に出して終わりにするのは避けるべきです。代理店は管理画面の中しか触れないため、ラベル設計に必要な社内データに手が届きません。一創の[Webマーケティング戦略の支援](https://www.issoh.co.jp/service/web/marketing/)では、ラベルと入札の設計から、商品マスタとの連携開発まで一続きでご相談いただけます。 ### データフィード広告の運用を始めるべきでない4つの場面と先にやること 次のどれかに当てはまるなら、データフィード広告の運用を本格化させるのは見送ります。 - 商品データをCSVの手作業で月1回しか更新できない - ECサイトの価格表示と基幹の価格が日常的に食い違っている - 商品数が数十点で、検索広告で型番を押さえれば足りる - 購入完了のコンバージョン計測が設定されていない 最初の2つは、広告を回すほど不承認と無駄なクリックが増える状態です。先にフィードを商品マスタから自動で作る仕組みを整えてください。商品数が少ない場合は、ショッピング広告より検索広告の方が管理の手間に見合います。計測が無い状態では、ラベルの振り直しも入札の判断もできません。ECサイトの構築方法や「既製で足りるか、開発すべきか」の判断は[ECサイトの種類・構築方法と開発判断の基準](https://www.issoh.co.jp/column/details/12826/)で整理しています。 ## よくある質問 データフィード広告の運用を検討する方から寄せられやすい質問に、ここまでの内容を踏まえて答えます。 ### データフィード広告の運用とDFOは何が違いますか？ DFOは、商品データを媒体の仕様に合わせて整える作業や、そのためのツールを指す言葉として使われます。データフィード広告の運用は、そのデータを使って出稿した後に、入札と予算、ラベルの設計、不承認の対応、成果の振り返りを回し続ける仕事です。DFOが「材料を整える工程」なら、運用は「材料を使って成果を出す工程」にあたります。両者は担当者も分かれやすく、DFOをツールに任せても、ラベル設計と入札の判断は運用側に残ります。 ### Google広告のフィードはどのくらいの頻度で更新すべきですか？ Merchant Centerの商品は最終更新から30日で期限切れになるため、30日以内の更新は最低条件です。実際の頻度は価格と在庫の動き方で決めます。価格改定や在庫切れが毎日起きるECなら1日1回以上の自動取得、時間単位のセールがあるならAPIで変更分を即時送信するのが目安です。構造化データからの自動商品更新は補助の位置づけで、定期更新の代わりにはなりません。 ### カスタムラベルには何を入れるのがよいですか？ 入札や予算を分けたい理由から逆算して決めます。最初に入れる価値が高いのは粗利率の区分で、広告管理画面に無い社内データを入札に持ち込めます。続いて在庫日数、価格帯、季節性、成果の区分などが候補です。値は「高・中・低」のように少数の区分にとどめてください。属性ごとの固有値は最大1,000個で、超えた分はレポートと入札で使えなくなります。 ### Content APIを使った独自連携は今も動きますか？ Content API for Shoppingは2026年8月18日に終了し、2026年9月1日から段階的にエラーが出ると公式に案内されています。独自連携でContent APIを呼んでいる場合は、Merchant APIへの移行が必要です。ECカートの標準連携やDFOツールを使っている場合は、提供元が対応済みかを確認してください。どちらの場合も、Merchant Centerでフィードの最終更新日時が止まっていないかを先に見るのが確実です。 ### データフィード広告の運用は代理店に任せれば十分ですか？ 入札と配信設定の操作だけなら任せられますが、それだけでは成果に限界があります。不承認の原因の多くは商品データの更新の遅れや入力ルールにあり、代理店は社内の商品マスタや基幹システムに手が届きません。粗利や在庫日数をラベルに載せる設計も、社内データを持つ側の協力が要ります。代行に出す場合も、商品データの持ち主と更新の仕組みの担当を社内か開発会社に置いてください。 ## 関連記事 - [DFO（データフィード整備）とは？ツール料金比較と媒体別フィード仕様の実務](https://www.issoh.co.jp/column/details/7977/)：フィードの仕様の実数値とDFOツールの料金比較 - [PLA広告とは？ショッピング広告との関係と出稿判断](https://www.issoh.co.jp/column/details/4900/)：ショッピング広告の仕組みと出稿を見送る条件 - [広告運用とは？仕事内容と自動入札時代の役割・内製と外注の判断基準](https://www.issoh.co.jp/column/details/18126/)：検索広告を含む広告運用全般の業務 - [ROASとは？計算式・目安・ROIとの違い](https://www.issoh.co.jp/column/details/4741/)：商品グループの目標ROASを置くときの計算 - [ECサイトとは？種類・構築方法・費用相場と開発判断](https://www.issoh.co.jp/column/details/12826/)：フィードの元になるECサイトの構築判断 --- 出典: [データフィード広告の運用：カスタムラベルの設計と商品データ自動更新の体制]()（株式会社一創）