こんにちは。ECプラットフォーム部 推薦基盤チームで、DWH・DMP・広告まわりのデータエンジニアリングを担当している大谷です。
本記事では、マーケティング部門の広告運用のインハウス化に伴ってこれまで取り組んできた広告データの収集と活用、その仕組みにフォーカスして事例をご紹介します。
背景
ZOZOでは事業・開発部門を問わず、様々な部門のスタッフが各自の業務に必要となるデータを取り扱い、レポーティングなどに活用する文化が根付いています。社内では人づてにデータを扱うノウハウが伝わり、Google BigQueryの発行済アカウント数は現在200を超え、様々なビジネスシーンにデータが活用されております。
マーケティング部門はここ1年ほどで広告運用がインハウス体制に切り替わりました。インハウス化以前から様々なセグメント配信を試行したり、日々レポートと向き合って効果の良し悪しを見極める運用体制ができていたので、現場の進め方が大きく様変わりすることはなかったように思います。
自社でアカウントを持つことによって、各種広告プラットフォームへ直接接続してデータの授受が可能になりましたので、キャンペーンの都度出稿先が変わるたびに接続先のパターンを増やしてきました。
データの収集と活用
弊社では現在、下図のような構成でデータの収集・活用を行っております。
Google BigQueryがデータ利活用の中心となる役割を担い、業務データ・Webログデータ・広告データ・データマート等、種々のデータがここに集約されております。
ZOZOTOWNの基幹データベースからBigQueryへの業務データ転送、データマートの更新処理については、DigdagとEmbulkを導入し運用しています。冪等性の保証やデータマートの依存関係を自動的に組み立てて実行される集計処理など、よく考え抜かれた仕組みとなっています。こちらについては、以前に弊社の塩崎・田島・平田の3名が記事を掲載しておりますのでご参照頂ければと思います。
techblog.zozo.com techblog.zozo.com techblog.zozo.com
広告データについては、オーディエンスリスト生成に必要な属性データはBigQueryから収集し広告プラットフォームへ転送。レポートデータは広告プラットフォームから収集しBigQueryへ蓄積し、レポーティングに活用されています。
現時点 1 で接続している広告プラットフォーム（代表3つを順不同で記載）
- Google Ads
- Facebook Ads
- Yahoo!広告
広告データ連携については、Google Compute Engineのインスタンス上もしくはCloud Functionsに、JavaもしくはPythonのプログラムを置いて動作させています。各種プラットフォームからクライアントライブラリが提供されているケースも多く、データをBigQueryと橋渡しする比較的シンプルな処理構造になっています。
内製処理と併せて、既成のプロダクトの力を借りることで、少人数でデータ運用が実現できています。ここでは、2つのプロダクトをご紹介します。
- Arm Treasure Data ... 主に外部プラットフォームとのデータ連携ハブとしての役割を担う
- フィードローダー（Google） ... Google Adsのショッピング広告出稿に必要な商品フィードデータ連携を自動化する役割を担う
それぞれの活用事例を見ていきましょう。
Arm Treasure Data
Arm Treasure Data（以降TD）は、ログ収集・Workflow・分析・機械学習・外部データ連携などの機能を1つのプロダクトで実現する、フルマネージドなデータプラットフォームサービスです。弊社における活用事例をご紹介します。
Integrations Hub
広告プラットフォームへのデータコネクターが豊富に組み込まれており、それらを活用することで内製にかかる工数を削減し、データをビジネスに活用するまでのリードタイムを短縮できています。プラットフォームAPIの仕様変更がデータコネクターで吸収されたり、パラメータ変更方法などの事前アナウンスやサポートが受けられることも障害抑止に役立っています。
ログ収集
サイトから収集したログをニアリアルタイムで利用できるログ収集機能の強みを活用して、2種類のログを収集し活用しています。
アクセスログ
ZOZOTOWNのアクセスログを収集しています。TDのSDKを使わず、IMGビーコンとしてサイトにタグを設置しています。このログをBigQuery ExportされたGoogle Analyticsのアクセスログと組み合わせることで、BigQuery上でセグメントしたオーディエンスデータを広告配信に活用しています。
タグの拡張パラメータに、Google AnalyticsのCookieの1つであるClientID（以降GoogleClientID）を渡してトラッキングします。これにより、ログ活用時にtd_global_id・各種CookieID・会員ID・GoogleClientIDの相互変換が可能になります。
TDのデータベースに記録されたアクセスログのうち、商品ページの閲覧ログを30分サイクルで名寄せして、ユーザーの閲覧データを生成後BigQueryのテーブルとして扱えるようにしています。このデータは、閲覧ベースの商品ランキングや、マーケティングオートメーションシステムのメール・プッシュ配信のレコメンド枠のデータソースとして活用されています。
検索インプレッションログ
ZOZOTOWNの検索結果ページにおいて、インプレッションされた商品データの収集を行っています。Web/アプリの検索結果ページが表示され、ユーザーがインビューした検索結果の商品情報を1行単位でIMGビーコンタグにまとめてログ収集し、BigQueryのテーブルとして扱えるようにしています。このデータは、検索結果の分析やロジック改善のために活用されています。
これらの膨大なログ収集を、現在までダウンタイムやデータロスト等が1度も発生することなく運用できております。
Workflow
日々のCookie名寄せ処理、広告データの収集とオーディエンスデータの更新を自動化するため、Workflowで手続きを組んでいます。
- Integrations Hubの豊富なコネクターをWorkflowで扱い、データ収集〜オーディエンスデータ更新のサイクルを自動実行するようにしています
- エラー通知をSlackへ集約しており、トラブルがあった際、すぐ対応できるようにしています
もしこれらの用途を自社基盤で賄うとしたら、インフラ・システム開発/運用体制を用意する必要があり、ビジネス活用の段階までには相応のコストとリードタイムが発生します。実質1名のオペレーターが構築〜運用までを実現できている機能性が、TDを導入する最大のメリットだと考えております。
フィードローダー (Google)
ECサービス企業が取り扱う広告の中でも効果的なものの1つが商品フィード広告です。サイト外の広告面に自社の商品名、画像、価格等の情報を掲載し、直接ユーザーが求める商品ベースでサイト流入〜購入に導くことができるため、一般的によいパフォーマンスが得られやすくなります。
商品フィード広告を出稿するためには、予め広告プラットフォーム各社へ自社の商品データを転送する仕組みを用意する必要があります。一般的に、各種プラットフォームのデータ仕様に応じた商品データの変換部分と、APIもしくはSFTPサーバ経由でデータを転送する部分の両方の準備が必要です。
フィードローダーは、Google Adsのショッピング広告出稿に必要となる商品データ転送を自動化するために開発され、Googleから提供を受けているツールです。
フィードローダーを利用するメリットは以下の通りです。
- APIの繋ぎ込み不要 ... 広告主側で実装する必要があるGoogle Merchant CenterのContent API連携処理がツールに内包されています。
- 商品データの更新が高速 ... 最短1時間間隔の更新サイクルが組めることで、商品データ更新の遅れに伴って発生しがちなトラブルである在庫欠品や、プロパー価格とセール価格の切替不備などを低減できます。
フィードローダーのアーキテクチャはすべてGoogle Cloud Platform上で構成されます。予め作成したGoogle Cloudプロジェクト内でフィードローダーのインストーラを実行すると、必要なアーキテクチャがデプロイされ、実行環境が整います。
Google Cloud Storageのバケットに商品ファイルと転送完了ファイルを置くと、Google Merchant Centerのフィードデータ更新まで一連の処理が実行されます。
フィードローダーは、前回反映から変更・削除のある商品を検知して更新処理を行うため、短時間で処理が完了するように設計されております。このような仕組みを自社で用意するのは開発リソースがかかるので、止むを得ず少ない更新頻度で運用しているケースが多いのではないでしょうか。
弊社では、広告掲載・非掲載時を問わず、常時400万件ほどの商品データを数時間間隔で更新しています。現状かなり時間的な余裕を持たせていますので、さらに更新サイクルを早めることは可能です。
現在のところフィードローダーの不具合による更新不備などは発生しておらず、高い安定性も運用担当者にとって魅力のひとつとなっています。
レポーティング
レポーティングにおいては、広告の出稿情報とその効果をデータとして一元管理することによって、以下の3点の課題の解決を目指しています。
- マーケターやアナリストが、サイト流入の増減理由を正確に把握し、より精度の良い分析ができるようにする
- 広告プラットフォームによって仕様の異なる指標群を束ねてレポーティングするために指標を標準化する
- 広告によるアップリフト効果を定量的に把握できるようにする
1,2に関しては、広告プラットフォームのデータと、外部から収集できない独自のマスタ情報がセットで必要となるため、運用担当者がデータの参照とメンテナンスをしやすい方式にする必要がありました。
Googleスプレッドシート × BigQuery
慣れ親しんだツールであるスプレッドシートとBigQueryを組み合わせることで、データの参照と、マスタテーブルの管理が可能になります。スプレッドシートはBigQueryのデータコネクターを標準でサポートしており、日々BigQueryに蓄えられたデータをスプレッドシート上で扱うことができます。
広告レポートデータ、Google Analyticsのアクセスログ、業務データなどを、クエリベースで結合・集計したデータをシート上に展開できます。2020年6月30日時点でデータコネクターは Connected Sheets としてアップデートされ、クエリを記述しなくてもテーブルのデータを展開できるなど、さらに利便性が向上しました。
また逆に、スプレッドシートをBigQueryのテーブル（フェデレーションテーブル）として扱うこともできます。レポーティングに必要な自社のマスタデータをスプレッドシート上で更新し、テーブルとしてデータを扱うことが可能になります。
弊社では、シートをマスタにしたキャンペーン付加情報テーブルを用意しました。各種広告プラットフォームで運用しているキャンペーンIDに、広告の種類・常時掲載またはイベント掲載・成果地点はどこかといった付加情報を定義します。これにより、各種広告プラットフォームを横断して、種類別・目的別の収益・コストなどをクエリベースで集計可能にしました。
同様のことをBIや内製ツールなどで実現する場合、高機能なツールの使い方を学ぶ必要があったり、データ更新用のインタフェースを用意する必要があったりします。またツールが分散することでマスタデータの更新作業が疎かになりがちです。
レポーティングの初期段階では、スプレッドシート活用がおすすめです。
CausalImpact (Google)
3.広告によるアップリフト効果を定量的に把握できるようにする
この課題を解決するために、GoogleがOSS提供している CausalImpact を活用しています。CausalImpactは、イベントやキャンペーンによってどのくらいの介入効果があったと推定されるかを定量的に評価してくれるライブラリです。
以下のようなパラメータを与えて実行することにより、評価結果を表組の数値もしくはプロットで描画可能です。
- キャンペーンの影響を受けていないコントロール群の時系列データ
- キャンペーンの影響を受けているトリートメント群の時系列データ
- キャンペーン実施前の期間
- キャンペーン実施期間
- 時系列の周期やサンプリング回数等のオプションパラメータ
弊社では、予めオーディエンスリストを居住地や会員IDのルール等の条件でコントロール群とトリートメント群に分けておき、トリートメントリストを配信対象に設定して配信します。そして配信後、コントロール群・トリートメント群それぞれに紐づく実績値を時系列データで与え、日別の初回購入数・新規登録数・新規訪問数などのアップリフト値を算出する運用を試行しています。
まとめ
本記事でご紹介した事例について、長く広告運用に携わられている方々の中には、こうすればもっと上手にできるのに…とご感想を持たれる方もいらっしゃるかと思います。ぜひ忌憚のないご意見・ご感想をお聞かせ頂ければ幸いです。
私たちのようにインハウス化に舵を切り、日々やり方を模索されている方々に少しでも参考になる事例が含まれていればと思い、記事を書かせていただきました。
ECプラットフォーム部 推薦基盤チームではメンバーそれぞれの強みを活かしながら、検索・レコメンド・広告など、打ち手となるさまざまなプロダクトの開発に取り組んでいます。
一緒にプロダクトを成長させていくメンバーを募集しておりますので、ご興味のある方は以下のリンクからご応募ください！
-
本記事が公開された2020年7月時点↩
