Metaカタログ広告のデータフィード設計｜商品ID・価格・在庫・画像の実務チェック

この記事の要点

• Metaカタログ広告では、カタログの商品IDとウェブ/アプリイベントの商品IDを一致させることが実装の中心です。
• 商品IDが合っていても、価格、在庫、画像、商品URLが古いと広告内容と遷移先がずれます。
• バリエーション商品は親商品とSKUのどちらをイベント単位にするかを先に決めます。
• カタログ更新、イベント計測、広告配信を別工程として監視すると、障害原因を追いやすくなります。

Metaカタログのデータフィードは何を担うのか

Metaのカタログ広告では、商品やサービスの情報をカタログへ登録し、広告配信に利用します。商品ID、商品名、価格、在庫、画像、リンク先などを商品単位で管理します。

動的広告では、サイトやアプリでユーザーが閲覧した商品とカタログの商品を結び付ける必要があります。そこで商品IDの一致が重要になります。

商品フィードだけ正常でも、PixelやConversions API側で別のIDを送っていれば、ユーザー行動と商品データが結び付きません。

商品IDを最初に固定する

商品IDは途中で変えない前提で設計します。ECリニューアルや商品マスター移行でも、広告計測との連続性を考えます。

よくある不一致は次です。

• カタログは親商品ID、イベントはSKU
• カタログはSKU、イベントは親商品ID
• ハイフンや大文字小文字が違う
• 先頭ゼロがCSV保存で消えた
• 商品ページと購入イベントで別IDを送っている

デバッグ時はブラウザ上のイベント、サーバー側イベント、カタログの3か所を突合します。

バリエーション商品のID設計

色やサイズで価格と在庫が違う商品は、SKU単位で商品情報を持つ方が整合しやすい場合があります。

例えばTシャツの赤Mだけ在庫切れなのに、親商品IDだけで在庫を管理すると、赤Mの閲覧者に在庫ありとして広告が出る可能性があります。

一方、EC側の商品ページが親商品単位でしかURLを持たない場合は、バリエーション選択状態をURLで表現できるかも確認します。

価格をサイトと一致させる

広告表示価格と商品ページ価格が違う状態は避けます。セール開始時刻や終了時刻がある場合、サイトとカタログの反映順序を揃えます。

更新遅延が起きる場合は、価格だけ高頻度で更新する仕組みを検討します。全商品説明まで毎回再送する必要はありません。

価格変更の前後では、送信ログとカタログ側の更新時刻を確認できる状態にします。

在庫をどう扱うか

在庫は、ユーザーが広告クリック後に購入できるかを左右します。欠品商品が広告候補に残ると、広告費だけでなく体験も悪化します。

在庫変動が大きいカテゴリでは、1日1回更新で足りない場合があります。SKUごとの販売速度と欠品頻度から許容遅延を決めます。

予約商品、受注生産、取り寄せ商品など、単純な在庫あり/なしでは表せない商品は、Meta側の許可値と自社表示を実装時に確認します。

画像URLの確認

画像URLはMeta側から取得できる必要があります。認証が必要なURL、短時間で期限切れになる署名URL、robotsやアクセス制限のあるURLは避けます。

バリエーション商品では、赤の商品に青の画像が付いていないかをSKU単位で確認します。商品マスターの画像紐付けが親商品単位しかない場合は、媒体向けに子SKU画像を持つ必要があるか判断します。

商品ページURLの確認

広告クリック後に該当商品のページへ遷移できるかを確認します。販売終了商品、URL変更商品、リダイレクトループ、404は定期的に検査します。

計測パラメータを付ける場合は、商品URLの生成ルールを一元化します。担当者が手作業でUTMを追加すると商品ごとの表記揺れが起きます。

カタログ生成とイベント計測を分けて監視する

Metaカタログ運用では、少なくとも3つの状態を分けます。

工程	正常条件	主な障害
フィード生成	商品件数と必須項目が正常	0件、欠損、文字化け
カタログ取込	商品が登録・更新される	取込エラー、画像取得失敗
イベント連携	商品IDが一致する	content ID不一致

広告が出ないときに「カタログがおかしい」と決めつけず、どの工程で切れているかを確認します。

更新頻度の決め方

更新頻度は商品属性ごとに違って構いません。

• 価格: セールや価格改定頻度に合わせる
• 在庫: 欠品速度に合わせる
• 商品名: 商品登録・改名時
• 説明: 更新頻度低め
• 画像: 制作更新時

すべてを同じバッチで1日1回更新する構成が簡単でも、在庫だけは30分以内に反映したい、といった要件があれば経路を分けます。

既存Googleフィードを再利用する場合

共通商品マスターやGoogle向けフィードを基にMetaカタログへ展開する運用は可能ですが、項目差分を確認します。

Google向けのtitleやカテゴリがMetaでも最適とは限りません。共通ID、価格、在庫、画像は再利用しやすく、媒体固有項目は変換層で調整します。

CriteoはGoogle/Facebook系フィードの再利用を公式に案内しているため、複数媒体では共通マスターの価値が高まります。

検証用商品の選び方

初回は次の代表商品を選びます。

• 通常価格商品
• セール商品
• 在庫切れ商品
• 色・サイズバリエーション商品
• 高価格商品
• 画像複数商品

それぞれでイベントID、価格、在庫、画像、URLを確認します。全商品取込が成功してから代表商品を確認するのではなく、少数商品で先に構造を検証すると修正が早くなります。

よくある失敗

商品IDをECリニューアルで変更する

広告イベントと過去カタログの連続性が切れます。変更が必要なら移行計画を作ります。

価格だけ手作業で直す

次回フィード更新で元データに戻ります。修正は正データ側または変換ルールへ反映します。

カタログ登録数だけを監視する

登録数が同じでも、画像取得失敗やID不一致は起こります。

SKUの画像が親商品画像のまま

色違い商品の広告で画像と商品が一致しない場合があります。

実務チェックリスト

• カタログ商品IDの生成ルールが固定されている
• Pixel/CAPIのcontent IDと一致する
• 商品詳細、カート、購入イベントでID体系が一致する
• 価格がサイトと一致する
• セール終了時刻を反映できる
• 在庫更新の許容遅延を決めた
• 画像URLをMeta側から取得できる
• SKUと画像が一致する
• 商品ページURLに404がない
• フィード生成とカタログ取込を別々に監視する
• 更新失敗の通知条件がある
• 媒体仕様を実装時に公式ドキュメントで再確認する

更新時点

最終確認日: 2026年8月29日。

Metaのカタログ、Commerce Manager、Pixel、Conversions APIの仕様は変更されます。必須項目や対応形式は実装時にMeta公式ドキュメントの確認を推奨します。

基礎構造はデータフィード広告とは、共通の属性改善は商品フィード最適化の基本で確認できます。

カタログ全件数とイベント対象件数を突合する

カタログに10,000商品あるのに、イベントで送られるIDが実際には8,000商品分しかない場合、2,000商品は動的広告との対応が取れない可能性があります。

商品マスターID一覧、カタログID一覧、イベントID一覧を定期突合し、差分を出します。

EC移行時はID対応表を作る

カートシステム変更でSKU体系が変わる場合、旧ID→新IDの対応表を作り、カタログとPixel/CAPIの切替時刻を揃えます。

移行期間に旧イベントIDと新カタログIDが混在しないようにします。

商品削除の反映を確認する

販売終了商品を元フィードから削除した後、Metaカタログ側でも非表示または削除されているか確認します。欠品と販売終了は同じ扱いにしません。

価格・在庫差分の自動監査

カタログからサンプル商品を取得し、ECサイトの価格・在庫と比較する監査を定期実行します。

不一致が一定件数を超えたら更新バッチを確認します。カタログ登録数だけでは鮮度問題を検知できません。

Meta側の仕様変更を月次確認する

カタログ項目、Commerce Manager、イベント仕様は更新されます。月次で公式情報を確認し、必須項目や推奨項目の変更があれば変換ルールへ反映します。

カタログ品質を商品群別に見る

全体のエラー率だけでなく、カテゴリ、ブランド、在庫帯、価格帯で分けます。

例えばアパレルだけ画像不一致が多いなら、親商品画像を子SKUへ流用する商品マスター設計が原因かもしれません。

イベントIDの検証方法

代表商品を5〜10件選び、商品詳細閲覧、カート追加、購入まで実際に操作し、送信されるIDを確認します。

親商品、色違い、サイズ違い、セール商品を含めると、SKU体系の不一致を見つけやすくなります。

カタログ更新のロールバック

誤った価格や在庫を全件送った場合に戻せるよう、直前の正常フィードを保存します。

変換ルール変更もバージョン管理し、問題が起きたら前バージョンへ戻せるようにします。

セール開始・終了の運用

セール価格は開始時だけでなく終了時の反映が重要です。終了時刻を過ぎてもsale_priceが残らないよう、サイトとカタログの更新時刻を合わせます。

セール終了日の深夜バッチだけに依存すると、数時間のずれが出る場合があります。

商品URL変更時の注意

ECのURL変更では、カタログのlinkとイベント計測の対象ページを同時に確認します。

旧URLから新URLへのリダイレクトがあっても、カタログは最終URLへ更新した方が管理しやすくなります。

カタログの新商品監視

新商品が商品マスターへ追加されたら、24時間以内にカタログへ入り、イベントIDと一致するかを確認します。

新商品のみを抽出できる登録日フィールドや社内ラベルを持つと監視しやすくなります。

カタログ終了商品の監視

販売終了商品は、カタログへ残す期間と削除方法を決めます。一時欠品と販売終了を同じ扱いにしないよう、商品状態を分けます。

画像更新時の確認

画像差替え後は、カタログ側が新画像を取得したかを確認します。URLを変えずに上書きする場合、キャッシュで旧画像が残る可能性があります。

カタログと注文データのID統一

広告イベントだけでなく、注文データでも同じSKU体系を使えると、商品別の広告成果を売上・粗利へつなげやすくなります。

注文側が親商品ID、広告側がSKUの場合は、対応表を用意します。

運用権限の整理

カタログ編集、イベント設定、広告配信の権限を必要な担当者へ限定し、異動・退職時の削除手順を決めます。外部支援会社へ付与する権限も定期確認します。

カタログ監査の月次項目

月次では、商品件数、画像エラー、価格不一致、在庫不一致、イベントID不一致、新商品未登録、販売終了商品残存を確認します。

不具合が特定カテゴリへ偏る場合は、媒体側より商品マスターや変換処理を疑います。

商品マスターへ戻す修正

カタログ上だけで価格や画像を手修正すると、次回更新で戻ります。恒久対応は元商品マスターまたはMeta向け変換ルールへ反映します。

変更履歴

商品ID規則、価格変換、画像URL生成、イベント実装を変更したら日付と影響SKUを残します。EC改修と広告設定変更が同時に起きる時期ほど履歴が役立ちます。

カタログ運用の完了条件

商品登録数だけでなく、主力商品のイベントID一致、価格・在庫一致、画像取得、終了商品削除まで確認します。

この状態を満たしてから、広告クリエイティブや配信設定の改善へ進みます。

担当者交代時の確認

商品ID規則、フィード生成場所、Pixel/CAPIのイベントID、更新時刻、エラー確認方法を引き継ぎます。特に親商品とSKUの使い分けは文書化します。

仕様更新の影響確認

Meta側のカタログ項目やイベント仕様が変わった場合、商品ID、価格、在庫、画像、イベント連携のどこへ影響するかを切り分けます。変更履歴と対象SKUを残し、全件へ反映する前に代表商品で確認します。