Google Shoppingの商品データはfeedを直す前に価格と在庫の正本を決める

Google Shoppingで商品が不承認になったとき、Merchant Centerのfeedだけを直して終わりにすると、同じ不一致を繰り返します。広告へ送る価格と在庫、商品ページで購入者が見る価格と在庫、ページ内のmicrodataが別々の場所で管理されているからです。修正の出発点はfeedではなく、どの値を正本にするかです。

Googleは、商品データを更新するとき、対応する商品ページのmicrodataも更新するよう案内しています。広告とサイトの情報を強く一致させ、価格と在庫を正確に扱うためです。広告の管理画面で不承認が消えることと、購入者が正しい条件で買えることは、同じ確認ではありません。

一つの商品には少なくとも三つの見え方がある

商品情報は、同じ内容に見えても役割が違います。商品ページは購入者に条件を伝えます。feedはGoogle Shoppingへ商品を伝えます。microdataはページ内の商品情報を機械が読み取れる形で示します。三つがずれると、広告を見た人、商品ページを読んだ人、商品情報を読み取る仕組みが、別の条件を受け取ります。

さらに、社内の受注システム、在庫管理、通販カートのどこかに、これらの値の元になる情報があります。ここを決めずに、表示、feed、microdataを個別に直すと、更新した人によって値が戻ったり、反映の時間がずれたりします。

たとえば、青色の商品の価格を下げるとします。商品ページの表示だけを新しい価格にし、feedには旧価格が残れば、広告とリンク先の条件が割れます。feedだけを新しい価格にして、商品ページが旧価格のままでも同じです。色違い、サイズ違いがある商品では、商品名が同じでも対象のバリエーションを取り違えやすくなります。問題を調べるときは「この商品」ではなく、商品IDと選択肢まで固定します。

在庫も価格と同じ順序で見ます。商品全体としては在庫があっても、広告から選ばれた色やサイズだけが売り切れている場合があります。商品ページで選択肢を変えたときに表示が変わるなら、feedとmicrodataがどの選択肢を示すかを確認します。「在庫あり」という一語を合わせる前に、購入者が実際に選べる商品と対応しているかを見ます。

商品名や画像も、値を照合する手掛かりになります。同じ名称の商品が複数あるとき、価格だけが一致していても別の商品へリンクしていることがあります。商品ID、商品pageのURL、選択肢、画像を一緒に記録すると、修正した対象を取り違えにくくなります。広告のためのdataと、販売する実物の対応を先に確かめます。

修正前に、値の正本と更新の順番を決める

正本とは、価格や在庫が変わったとき、最初に直す場所です。通販カートの商品情報を正本にして、商品ページ、microdata、feedがそこから作られるサイトもあります。別の販売管理システムで在庫を管理し、そこからカートとfeedへ渡すサイトもあります。仕組みは違っても、同じ商品について最終的にどの値を採用するかが一つでなければなりません。

不承認を直すときは、次の順序にします。

1. 問題になった商品IDと、色やサイズなどの選択肢を一件に固定する。
2. 商品ページ、feed、microdataへ出ている価格と在庫を同時に記録する。
3. それぞれの値が、どの管理画面やデータから来ているか調べる。
4. 正本の値を直し、商品ページ、microdata、feedへ同じ内容が反映されるようにする。
5. 公開ページを実際に開き、購入者が見る値と、送信後のfeedの値を確認する。

この順番なら、feedの編集画面で一時的に値を合わせる前に、古い値がどこから来たかを見つけられます。反映を待つ時間がある仕組みでも、正本と反映先を分けて記録しておけば、遅れているのか、別の値が戻したのかを判断できます。

価格を変更する日には、更新の順番と確認する時刻を決めます。先に通販カートの正本を直し、商品pageの表示とmicrodataが変わったことを確認し、feedへ渡った値を確認します。反映に時間がかかる場合は、その間に広告でどの価格が見える可能性があるかを把握します。販売を始める時刻より後にfeedが直るなら、広告の表示をどう扱うかも決めます。

automatic item updatesを修正作業の代わりにしない

Googleは、商品ページのmicrodataを更新すると、automatic item updatesのような機能も利用でき、広告の価格と在庫をより正確に保つ助けになると案内しています。これは、商品ページと広告の情報をそろえるための補助です。

ただし、補助があるから、feed、商品ページ、在庫管理の更新手順を決めなくてよいわけではありません。値が何度も食い違うなら、問題はMerchant Centerの警告ではなく、販売情報がどこで確定しているかが曖昧なことです。まず正本を決め、その値をどこへ渡すかを整理します。

商品データの仕様では、色、サイズ、画像など、商品に応じて必要な情報もあります。2016年9月からは、一部の要件を満たさない商品データが不承認になる運用が始まっています。属性を埋める作業も、商品ページで販売している実物と対応していなければ意味がありません。正しい商品を、正しい選択肢のまま送ることが先です。

automatic item updatesで値が補われた場合も、なぜ不一致が起きたかを残します。商品pageの更新が先でfeedの更新が遅れたのか、別の担当者がfeedを手で直したのか、正本そのものが古かったのかで、次に直す場所が変わります。不承認が消えたことだけを記録すると、同じ商品を次に更新したときに同じずれを繰り返します。

広告の担当と販売情報の担当を分ける

広告代理店や制作会社は、feedの送信状態、不承認の表示、microdataの実装を確認できます。しかし、いつ価格を変えるか、在庫切れをどう扱うか、どの商品を販売するかは販売側が決めることです。広告の担当だけへ「不承認を消してほしい」と頼むと、画面上の値だけを直して、販売情報とのずれを残すおそれがあります。

販売側は正本の値と更新時刻を決め、制作側は商品ページとmicrodataへの反映を確認し、広告側はfeedとMerchant Centerの状態を確認します。役割を分ければ、誰かが作業を止めたときにも、どこまで確認したかを追えます。

最初の一手は、不承認の商品を一件だけ選び、商品ID、商品ページ、feed、microdata、正本の値を一枚へ並べることです。値がそろわない理由を説明できてから、まとめて直します。