Merchant CenterのFeed Rulesは商品dataの元fileを決めてから使う

Merchant CenterのFeed Rulesを使う前に、商品dataの元fileを決めます。Feed Rulesは、在庫管理や商品管理で使うdataを、Google Shoppingで受け付ける項目へ変換するための機能です。広告のために必要な変換と、商品そのものの情報を同じ場所で直すと、価格や在庫の更新責任が分からなくなります。

Googleの公式案内は、Merchant CenterのFeed Rulesで、元のcolumn名をGoogle Shoppingのattributeへ対応させたり、値を変換したり、条件に応じて不足した値を補ったりできると説明しています。設定したruleは、そのfeedの以後のuploadへ適用されます。custom labelsやshipping labelを使い、価格帯や利益、配送条件ごとにcampaignを整理する方法も案内されています。

Feed Rulesを使う理由は、商品管理の仕組みを広告用に作り直すことではありません。すでに店で使っているcolumn名や表記を、Shoppingのattributeへ対応させるためです。元dataを勝手に広告用の名前へ直すと、在庫担当、受注担当、商品pageを更新する人が同じ情報を読めなくなります。元の事実を保ち、広告に渡すときだけ必要な形へ変換します。

ruleを設定した後も、商品dataを直す入口は元fileまたは元systemに残します。価格が違う、在庫がない、商品名が古いという問題は、Feed Rulesの画面だけで直してはいけません。広告へ出す値だけを一時的に変えると、商品pageや受注の情報とずれます。何が商品の事実で、何が広告のための変換かを、更新する人全員が追えるようにします。

商品の事実と広告用の分類を分ける

商品名、価格、在庫、型番のような情報は、店の運用で使う元dataに持たせます。入札を変えるための価格帯や利益区分は、広告用の分類として分けます。

たとえば、商品管理fileに「主な商品名」というcolumnがある場合、Feed RulesでGoogle Shoppingのtitleへ対応させます。一方、利益区分ごとに入札を変えたい場合は、商品名を利益区分へ書き換えません。広告用のcustom labelsを別に用意します。

価格帯や利益区分を広告用に分ける場合も、元の価格や原価を上書きしません。たとえば「高価格帯」「低価格帯」というcustom labelは入札を分けるための分類であり、商品pageで利用者に見せる価格ではありません。広告担当が分類を変えることと、store側が販売価格を変えることを同じ権限にしないようにします。誰が分類を決め、誰が価格を更新するかを分けます。

shipping labelも、配送の条件を勝手に作るための欄ではありません。実際の配送地域、送料、発送できる商品との関係を確認してから使います。広告側で配送に関する分類を足しても、利用者が商品pageや購入画面で別の条件を見るなら、期待がずれます。Feed Rulesの結果とstore側の案内を比べます。

Feed Rulesへ直書きする前に変換表を作る

Feed Rulesは便利ですが、ruleを増やすほど、誰が何を変えたかを追いにくくなります。最初に変換表を作り、元data、変換後のattribute、変換理由、変更する人を並べます。

1. 商品dataを出している元fileまたはsystemを一つ決める。
2. Google Shoppingへ渡すattributeと、元のcolumnを対応させる。
3. 値を変換する必要がある項目だけを選ぶ。
4. 広告用の分類はcustom labelsまたはshipping labelとして分ける。
5. Feed Rulesへ設定した内容と、変更担当を記録する。
6. 次のfeed upload後に、対象商品が想定した値で受け付けられたか確認する。

空欄へ固定値を入れるruleは、元dataに不足があることを隠す場合があります。価格や在庫のように店の運用へ影響する値は、まず元dataを直すべきか検討します。Feed Rulesで補うなら、補う条件と対象商品を記録します。

変換表には、元のcolumn、変換後のattribute、ruleの内容だけでなく、使う理由とやめる条件も書きます。たとえば元dataのcolumn名が将来変わったら、対応付けを見直す必要があります。特定の商品群だけへ固定値を入れるruleなら、その商品群を追加したり削除したりしたときに確認します。ruleは一度作ると以後のuploadへ適用されるため、設定した日と担当を残さなければ、古い判断が残り続けます。

feedを更新した後は、対象商品を数件選び、元data、Feed Rulesの結果、Merchant Centerで受け取った値、商品pageの表示を順に見ます。全商品を目視する前に、変換の条件が違う代表例を選びます。空欄を補う商品、価格帯が違う商品、配送条件が違う商品を比べると、ruleが意図しない範囲へ広がっていないかを見つけやすくなります。

値が想定と違うときは、ruleをさらに足す前に、元dataがどう出力されたかを確認します。元fileに誤りがあるのか、column名の対応が違うのか、条件の順序が想定と違うのかを分けます。画面上の一件を直すために例外ruleを重ねると、次のfeedで同じ商品や別の商品へ予期しない値が入ることがあります。例外を増やす前に、正本を直せない理由を確認します。

外部の広告運用担当にFeed Rulesを任せる場合も、元dataを渡しただけで終えません。どこが正本か、価格と在庫を誰が更新するか、広告用のcustom labelを誰が決めるか、ruleを変更したら誰へ連絡するかを決めます。広告側の設定を変更できる人が、商品管理のdataを変更する必要はありません。作業範囲を分けておけば、商品情報の責任が失われません。

Feed Rulesを商品管理の代わりにしない

Feed Rulesは、Merchant Centerへ送るdataを変換します。在庫管理、受注管理、商品説明の承認作業までを置き換えるものではありません。ruleの設定を引き継げない状態では、商品dataの更新担当が変わったときに、広告だけ別の情報を出すおそれがあります。

商品数が多いほど、Feed Rulesで全部を整えたくなります。しかし、すべての不備をruleで補うと、元dataの質が見えなくなります。価格や在庫のように毎日変わる情報は、元の管理場所で更新できる状態を優先します。広告用の分類や表記の対応のように、元dataを変えずに処理できるものだけをFeed Rulesへ置くと、修正の責任を保ちやすくなります。

広告に出す範囲を変えるときも、ruleだけを見ません。利益の低い商品を除く、配送に時間がかかる商品を別groupにする、在庫が少ない商品を止めるといった判断は、store側の販売方針と結び付いています。custom labelを増やす前に、どの商品の入札を、どの理由で分けたいかを書きます。分類の数を増やすことより、入札を変える理由が説明できることを優先します。

最初に確認するcolumnは、価格や在庫のように利用者とstoreの両方へ影響するものです。そのcolumnがどこで更新され、どのruleを通り、Merchant Centerでどう受け取られるかを一行にします。元dataから広告へ渡る道筋が分かってから、必要な変換だけを追加します。

最初の一手は、現在のfeedで使うcolumnを一つ選び、その値を誰がどこで直しているか書くことです。元dataが決まってから、Feed Rulesで変換する範囲を絞ります。