Criteoの商品カタログ／フィード入稿ガイド｜作成・更新・検証の流れ

この記事の要点

• CriteoのProduct Catalogは、動的広告に使う構造化商品データです。
• Criteo公式ヘルプでは、既存のGoogleまたはFacebook商品フィードを再利用できると案内しています。
• 再利用時も、商品ID、価格、在庫、画像、URL、カテゴリが期待どおりに読み込まれたかを確認します。
• スケジュール更新を設定した後は、最終取込時刻、商品件数、エラー、除外商品を監視します。

Criteoの商品カタログとは何か

CriteoのProduct Catalogは、商品情報を構造化して保持し、動的かつパーソナライズされた広告で利用するためのデータです。Product Feedはそのカタログへ商品データを取り込む元ファイルです。

Criteo公式ヘルプは、Product Catalogによって最新の商品情報を広告へ反映し、商品グループによるセグメントや自動更新を利用できると説明しています。

既存Google・Facebook系フィードを再利用できる

Criteoは公式ヘルプで、GoogleまたはFacebookの商品フィードをすでに利用している場合、同じファイルをProduct Catalog設定に再利用できると案内しています。

これは新規媒体追加の工数を抑えやすい利点です。ただし「追加フォーマットが不要」という説明を、検証まで不要と解釈しないようにします。

既存フィードがGoogle向けに最適化されていても、Criteo側の商品分類やイベントIDと合うかは別の確認です。

再利用時の差分確認

再利用時は次を確認します。

項目	既存フィードで確認	Criteo取込後に確認
商品ID	一意か	イベントIDと一致するか
商品名	実商品を表すか	文字化けや欠損がないか
価格	サイトと一致	読込価格が正しいか
在庫	最新か	欠品状態が反映されるか
画像	URL取得可	広告用に利用できるか
商品URL	正常	正しい商品へ遷移するか
カテゴリ	自社/Google分類	商品グループに使えるか

特に商品IDは、Criteo側のイベント計測と揃える必要があります。

商品IDとイベントの一致

動的広告では、ユーザーがどの商品を閲覧したかをイベントで識別し、カタログの商品と対応付けます。

EC側がSKU-001-BLK-Mをイベントで送るのに、カタログが親IDSKU-001だけなら、意図した商品へ結び付かない場合があります。

サイトイベント、購入イベント、カタログのID体系を同じ表で管理します。

価格と在庫の更新

Criteoの広告に最新の商品情報を使うには、価格と在庫の更新が必要です。Criteo公式ヘルプは、スケジュールされた日次インポートによる商品データ更新を案内しています。

在庫変動が日次より速い事業では、利用環境で可能な更新方法を確認します。価格と在庫が古いと、広告クリック後に表示内容と商品ページがずれます。

画像とURL

画像URLは外部から安定して取得できる必要があります。CDNの期限付きURL、アクセス制限、削除済み画像は取込エラーの原因になります。

商品URLも定期確認します。販売終了商品のURLが404になったままカタログへ残ると、広告品質とユーザー体験を損ないます。

取込スケジュール

Criteoの公式ヘルプでは、Product Feedを設定し、日次インポートをスケジュールし、取込アクティビティを監視する流れが案内されています。

運用側では次を記録します。

• 予定取込時刻
• 最終成功時刻
• 商品件数
• 新規件数
• 更新件数
• エラー件数
• 除外件数

件数が前日から大きく減った場合は、媒体送信前のフィード生成に問題がないかも確認します。

フィールドマッピングと変換ルール

既存フィードを再利用するときも、Criteo側で項目がどう解釈されるかを確認します。

例えば商品カテゴリを広告グループや商品セットに使いたい場合、既存Googleカテゴリだけで十分か、自社product_typeの方が運用しやすいかを検討します。

共通マスターにCriteo専用項目を直接追加するのではなく、Criteo差分として管理すると他媒体への影響を抑えられます。

商品グループを運用目的で分ける

商品カタログは単なる保管場所ではなく、広告運用で商品群を分ける基準になります。

例えば売れ筋、在庫過多、セール、粗利、カテゴリなどで商品群を作り、広告戦略と接続します。自社の商品分類が粗すぎると、媒体追加後に広告運用で使えません。

商品マスター段階で「カテゴリ」「粗利帯」「在庫方針」「季節性」を持てると、複数媒体で再利用しやすくなります。

取込成功と広告利用可能は分けて確認する

ファイル取込が成功しても、全商品が広告利用可能とは限りません。画像エラー、URL問題、イベントID不一致、除外条件などが残る場合があります。

監視を2段に分けます。

1. フィードが正常に取込されたか
2. 商品が広告利用に必要な条件を満たすか

「取込成功」の1項目だけで運用監視を終わらせないようにします。

よくある失敗

Googleフィードをそのまま流して終える

再利用はできても、Criteo側のID整合と商品状態確認が必要です。

手作業修正をCriteo側だけで行う

次回取込で上書きされます。恒久修正は元データか変換ルールへ戻します。

更新停止に気づかない

日次取込が止まると価格と在庫が古くなります。最終成功時刻を監視します。

商品カテゴリが広告運用に使えない

カテゴリ粒度が粗い場合、商品グループ設計に必要な分類を追加します。

実務チェックリスト

• 既存Google/Facebook系フィードの再利用可否を確認した
• 商品IDがサイトイベントと一致する
• 価格がサイトと一致する
• 在庫が最新
• 画像URLを外部取得できる
• 商品URLに404がない
• カテゴリが商品グループ設計に使える
• 取込スケジュールを決めた
• 最終成功時刻を監視している
• 商品件数の急減を検知できる
• 取込後のエラーと除外を確認している
• 修正を元データまたは変換ルールへ戻している

公式情報と更新時点

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

• Criteo Product Catalog
• Criteo Product Catalog setup

Criteoの管理画面とフィード仕様は変更される可能性があります。実際の設定前に公式ヘルプの確認を推奨します。

Criteo追加時の媒体差分台帳

既存Googleフィードを再利用するときは、共通項目とCriteo確認項目を台帳化します。

共通項目はID、名称、価格、在庫、画像、URL。Criteo側ではイベントID一致、商品グループ、除外条件、取込スケジュールを追加確認します。

取込エラーの再発防止

同じエラーが繰り返される場合、Criteo側で手修正せず元データまたは変換ルールへ戻します。

エラー種別、発生日、対象SKU、原因、恒久対応を記録し、次回取込で再発しないことを確認します。

商品除外の基準

販売終了、長期欠品、法的・ポリシー上広告不可、利益が出ないなど、カタログへ残しても広告対象にしない商品があります。

除外条件を手作業で個別設定せず、商品マスターやラベルから再現できるルールにします。

Googleフィード再利用時の変更影響

Google向けタイトルやカテゴリを改善した結果、Criteo側にも同じ変更が流れる場合があります。

1つの共通フィードを再利用するなら、Google最適化がCriteo広告表示にどう影響するかを確認します。媒体差分が必要なら、共通マスターから別出力に切り替えます。

日次取込の障害通知

予定時刻を過ぎても取込成功が確認できない、商品件数が前日比で大きく減った、価格空欄が増えた場合は担当者へ通知します。

数値閾値は自社の商品変動幅から決めます。

既存フィードの品質が悪い場合は再利用しない

Googleフィードを再利用できても、そのフィードに価格不一致、画像欠損、カテゴリ混乱があるなら問題も引き継ぎます。

媒体追加前に共通マスターを監査し、再利用元の品質を整えます。

商品グループの命名規則

商品グループを増やす場合、カテゴリ_目的_期間のように命名規則を決めます。

例: スニーカー_セール_2026秋。

広告担当者が見て条件を推測できる名称にし、条件そのものは台帳へ記録します。

Feed Rulesの変更管理

Criteo側のフィードルールやマッピングを変更する場合、変更日、対象項目、旧ルール、新ルールを残します。

媒体側だけで加工が増えると、元フィードとの違いが分からなくなります。恒久的な変換は可能なら共通変換層へ戻します。

取込件数の異常を基準化する

前日比で商品件数が大きく減った場合に通知する仕組みを作ります。

通常の販売終了や新商品追加でどの程度変動するかを1〜2か月記録し、その範囲を超えたら異常として扱います。

Criteo追加後の30日レビュー

導入後30日では、広告成果だけでなく次を確認します。

• 取込失敗回数
• 商品件数の差分
• イベントID不一致
• 価格・在庫不一致
• 画像エラー
• 除外商品の残存
• 商品グループの使いやすさ

運用上の修正が多い場合、既存Googleフィードの再利用方式を続けるか、Criteo専用出力を持つかを再判断します。

代表商品による取込テスト

Criteoへ全件投入する前に、通常商品、セール商品、在庫切れ、バリエーション、高価格、画像複数の商品を選びます。

取込後に商品ID、価格、在庫、画像、URLが意図どおりかを確認します。

イベント側のIDテスト

商品詳細、カート、購入などのイベントがカタログ商品IDと一致するかを代表商品で検証します。

親商品とSKUの単位が混在している場合は、商品種別ごとにサンプルを取ります。

価格更新の反映時間を測る

価格変更時刻、フィード生成時刻、Criteo取込時刻を記録し、反映遅延を測ります。

セール商品で許容遅延を超える場合、取込スケジュールや更新方式を見直します。

在庫切れ商品の扱い

一時欠品と販売終了を分けます。一時欠品は再入荷時に同じIDで戻せるようにし、販売終了は広告対象から除外します。

運用引き継ぎ資料

フィードURL、取込時刻、ID規則、除外条件、商品グループ、通知先、直近のエラーを文書化します。

既存Googleフィードを再利用している場合、その依存関係も明記します。

再利用方式を続けるかの判断

Google/Facebook系フィードの再利用で毎回Criteo専用の手修正が発生するなら、共通マスターからCriteo専用出力を生成する方が保守しやすくなります。

判断材料は、月間修正件数、媒体固有ルール数、取込エラー、変更時の影響範囲です。

カタログ品質の定例確認

週次で取込成否と件数、月次で商品ID、価格、在庫、画像、除外条件を監査します。広告成果だけでなく、データ運用品質を別指標として持ちます。

仕様変更時の対応

Criteo側の項目や管理画面が変わったら、既存Googleフィード再利用に影響があるかを先に確認します。影響属性だけを差分修正し、共通フィード全体を不用意に変えないようにします。

導入完了の判定

連続した定期取込が成功し、代表商品のID、価格、在庫、画像、URLが正しく、イベントIDも一致する状態を導入完了の基準にします。

広告成果の評価はその後に行います。

運用負荷の見直し

既存フィード再利用で毎月の手修正が増えるなら、Criteo専用出力へ切り替える判断があります。修正件数と作業時間を記録し、再利用のメリットが残っているかを定期評価します。

定例で再利用方式の妥当性も確認します。

監査結果も保存します。