Google Merchant CenterのDiagnosticsタブはaccount、feed、itemの順に不承認原因を絞る

Product Listing Adsの商品が不承認になったら、商品データを一括で作り直す前に、Google Merchant CenterのDiagnosticsタブで問題の範囲を絞ります。最初にaccount全体、次にfeed、最後にitemを確認すれば、共通設定の問題と個別商品の問題を分けられます。

Diagnosticsタブは、account、feed、itemの問題を一か所へまとめます。Data Qualityタブを置き換え、不承認になったitemと理由をreportとして取得できるようになりました。

account、feed、itemは影響する範囲が違う

三つの範囲を同時に直し始めると、どの変更で問題が解消したか分かりません。Diagnosticsタブを開いたら、表示された問題を次の順で読みます。

たとえば、一つのfeedに含まれるitemが広く不承認なら、個別商品を順番に直す前に、feedの生成規則を調べます。少数のitemだけなら、downloadしたreportで商品IDと不承認理由を対応させます。これは問題の範囲を絞るための判断であり、表示件数だけでは原因を確定できません。

eligibilityの履歴から変化した時点を探す

Diagnosticsタブの発表では、item eligibility statusの履歴を確認できます。最近の不承認を調べる場合は、不承認になった日付の前後で、商品master、feed生成処理、送信設定のどれを変更したか照合します。

変更記録は、次の四点を一組にします。

• 変更日時
• 変更した属性または設定
• 対象feedと商品ID
• 変更した担当者

履歴に変化があっても、変更内容との対応が分からなければ修正箇所は決まりません。Merchant Centerの表示と、商品データを作る側の記録を同じ商品IDで結びます。

不承認reportは理由ごとにまとめて直す

Diagnosticsタブから、影響を受けるitemと不承認理由を含むreportをdownloadできます。reportを商品IDの順に眺めるだけでなく、不承認理由ごとにまとめます。同じ理由が多数の商品へ出ていれば、一件ずつ入力するより、商品masterまたはfeed生成処理の共通規則を直す方が先です。

修正の優先順位には、問題ごとの影響item数とtraffic、impactの指標を使います。ただし、影響item数が多い問題を機械的に最優先にはしません。販売したい商品が含まれるか、修正に必要な時間、再送信を担当できる人を合わせて判断します。

修正する場所と確認する場所を分ける

Merchant Centerは問題を見つける場所です。Merchant Centerへ送る値の元データを別のsystemで管理しているなら、修正はその商品masterへ戻します。送信fileだけを書き換えると、次の生成時に古い値へ戻るおそれがあります。

制作会社や運用会社へfeedの修正を委託しても、Merchant Center account、商品master、送信手順の所有者は決めてください。誰が不承認reportを取得し、誰が元データを直し、誰が再送信後のeligibilityを確認するかを分けます。

最初の一手は、Diagnosticsタブから不承認reportをdownloadし、理由別にitem数を数えることです。最も多い理由について、account、feed、itemのどこへ共通点があるか調べてください。