バリエーションとitem_group_id
4色6サイズのシャツは、フィード上では24行ですが、買い手にとっては1つの商品です。この買い手の感覚とGoogleの認識を一致させるためにあるのがitem_group_idであり、これを誤ると、気づきにくい形で大きな損失を生みます。
バリエーションの仕組み
購入可能なバリエーションはそれぞれが独立した商品であり、固有のid、価格、在庫状況、そして何より固有の画像を持ちます。それらを結びつけるのが共通のitem_group_idと、各バリエーションを区別する属性（カラー、サイズ、素材、パターン、年齢層、性別）です。
起こりやすい失敗
- item_group_idがない。24件の無関係な商品として扱われ、同じオークション内で互いに競合し、パフォーマンスデータも24分割されてしまいます。
- グループidはあるが、区別する属性がない。Googleがバリエーションを区別できず、重複商品と判断される可能性があります。
- カラー違いで画像を共用している。ブルーのバリエーションにレッドの写真が表示され、コンバージョンを損なうだけでなく、情報の不一致による不承認のリスクも生じます。
- idが安定していない。カタログを書き出すたびにバリエーションのidを再生成すると、そのたびに全バリエーションのパフォーマンス履歴が失われます。
- 親商品だけを送信している。サイズ情報のない「シャツ」1行だけでは、サイズで絞り込んだ検索にはまったく対応できません。
idは記憶そのものです。フィード内の他の情報が変わっても、idは安定させてください。Googleがこれまでのデータと同じ商品であると認識できるのは、idがあるからです。
すべてのバリエーションを送信すべきか
基本的には送信すべきです。バリエーション単位で送信してこそ、「サイズ42」で絞り込む買い手に見つけてもらえます。また、1つのサイズが売り切れても商品全体が非表示にならないため、在庫切れの扱いも正確になります。
例外は、バリエーションが非常に多く、しかも買い手が絞り込みに使わないほぼ同一の違いしかないカタログです。この場合、すべてを送信してもフィードが重くなりレポートのノイズが増えるだけで、獲得できる検索が増えることはありません。
バリエーションがある場合のレポート
バリエーションを含むカタログの商品別レポートはバリエーション単位になるため、結論を出す前にカテゴリ単位や商品グループ単位で集計することが不可欠です。バリエーション単位では不採算に見える商品も、グループ単位では採算が取れていて、売上が2つのサイズに集中しているというケースはよくあります。