• AdWordsのDynamic Remarketingは広告を作る前にbusiness data feedの更新責任を決める

AdWordsのDynamic Remarketingは広告を作る前にbusiness data feedの更新責任を決める

公開日: 執筆:佐藤

AdWordsのDynamic Remarketingでは、広告の画像や文言を先に作り込みません。最初にbusiness data feedの情報が、現在提供している商品やserviceと合っているかを確認します。feedが古ければ、広告の表示が整っていても、link先で利用者が確認する内容とずれます。広告を組み立てる仕組みと、事業情報を更新する仕事は別です。

dynamic remarketingは、広告を自動的に作る部分が目立ちます。しかし、自動で使われる元dataが正しくなければ、同じ誤りを複数の広告へ広げます。広告を見た人がlink先で確認できる商品、service、価格、受付状況を、feedから追えるようにします。広告を整える前に、元dataを直せる状態を作ります。

GoogleのDynamic Remarketingに関する案内は、dynamic remarketing campaignでbusiness data feedが重要であると説明しています。案内では、高品質なfeedの設定、完全なproduct data、feedを新しい状態に保つこと、dynamic remarketing adを有効にすることを扱っています。

feedの情報と広告の見た目を分ける

dynamic remarketingでは、feedを基に広告へ表示する内容が決まります。広告の画像を替えるだけでは、price、受付状況、link先などの情報が正しくなるとは限りません。画像、広告文、feed、link先pageは、別の場所で更新されることがあります。それぞれが同じ内容を示すかを確認します。

確認するもの 決めること 混同しないこと
business data feed 広告で使う商品またはserviceの情報 広告画像だけの差し替え
link先page 利用者が詳細を確認するURL feedにある名称だけで内容を説明すること
広告素材 feedの情報を補う画像や文言 現在提供しない内容を約束すること
更新担当 元dataを直す人、feedを反映する人、広告を確認する人 更新作業を一人が自動で完結するという前提

たとえば、提供を終えたserviceがfeedに残り、link先では別のserviceを案内しているとします。広告から来た利用者は、何を頼めるのか判断できません。古い行を止めるのか、link先を直すのか、serviceを再開するのかを先に決めます。広告のclick数だけを見て、feedのずれを見過ごさないでください。

古いURLがfeedに残る場合も同じです。広告から開いたpageが404になったり、別の商品へ移ったりすれば、利用者は広告の内容を確かめられません。URLを変えるなら、feedのURL、site内の案内、広告の確認画面を一緒に見ます。link先だけを直して、元dataに古いURLを残さないようにします。

一つの行に複数の条件がある場合は、どれが変わりやすいかを分けます。価格、在庫、提供地域、受付時間、画像、説明文は、同じ頻度で変わるとは限りません。毎日変わる情報と、年に一度しか変わらない情報を同じ手順で管理すると、必要な更新が遅れます。事業側で何が変わったときに、誰が元dataを直すかを決めます。

更新の起点を一つに決める

feedがどこから作られるかを確認します。商品管理画面、spreadsheet、社内の基幹data、外部serviceなど、元になる情報が複数あると、更新したつもりで別のdataが残ることがあります。正しい情報を最初に直す場所を一つ決めます。

説明用の仮例として、サービス内容をspreadsheetで管理し、そのfileからfeedを作る場合を考えます。受付を止めたserviceは、siteの案内、spreadsheet、feed、広告の順に確認します。どれか一つだけを修正しても、広告とlink先が同じ内容になるとは限りません。

この場合、spreadsheetを更新する人、feedを反映する人、広告を確認する人が別なら、更新の連絡だけでは不十分です。どのserviceのどの項目を変えたか、反映を確認したか、広告を止める必要があるかを記録します。更新作業を一人へまとめられない場合でも、更新の起点と確認の終点は一つにします。

  1. 広告へ出す商品またはserviceを一覧にする。
  2. feedの元dataと更新担当を確認する。
  3. 一つの項目について、feed、広告、link先pageを並べて確認する。
  4. 提供しない項目、古い価格、古いURLを扱う方針を決める。
  5. 更新後に、対象URLと広告の案内が一致するか確認する。
  6. 更新日、元data、確認者、戻し方を記録する。

feedの変更後は、元のfileだけを見て終わりにしません。対象の一行を選び、名称、価格または条件、画像、link先URLを、公開pageと並べます。次に、広告の案内で同じserviceが出るかを確認します。対象が多くても、代表になる一行を一つずつ確認すれば、更新のどこで食い違いが起きるかを見つけやすくなります。

自動で表示されても内容の承認は残る

dynamic remarketingは、利用者に応じて関連する広告を示す仕組みです。しかし、現在の提供条件、表示してよい商品、利用できる画像、link先の内容を自動で承認する仕組みではありません。出したくない項目までfeedに含めないようにします。

広告に出す対象を止める判断も、広告運用だけの判断ではありません。販売を終えた商品、受付を止めたservice、掲載期限が過ぎたイベントは、事業側が掲載可否を決めます。その結果をfeedの元dataへ反映し、広告側で表示されないことを確認します。広告を一時停止しただけで、次の更新で古い行が再び使われないかも見ます。

画像の利用権も、feedの更新と別に確認します。商品やserviceの写真を広告へ使えることと、siteで表示できることは、同じ条件とは限りません。使用できる範囲が変わった場合は、元画像、feedの参照、広告の表示を一緒に確認します。見た目を差し替える人と、掲載の承認をする人を分けます。

外部の広告運用会社や制作会社へ作業を頼む場合も、広告account、feedの元data、商品またはserviceの掲載可否、画像の利用権、link先pageの管理権限は事業者側で把握します。配信の作業を頼むことと、何を広告へ出すかの判断を渡すことは別です。外部担当が替わっても、元dataと掲載可否を確認できるaccountと記録を残します。

最初の一手は、feedの一行を選び、その名称、広告、link先page、更新担当を一枚に書き出すことです。一行がそろってから、対象を増やします。dynamic remarketingで重要なのは広告の自動化そのものではなく、更新された事業情報を広告とlink先まで同じ内容で届けることです。

戻る