SRE Groupの本田（@mov_vc）です。
今回はKaizen Adで運用している広告データ収集基盤について、Google広告の例をもとに開発事例を共有できればと思います。
背景
Kaizen Adでは、広告配信データを収集、活用しています。広告配信データとは、例えば以下のようなものです。
| メトリクス名 | 意味 |
|---|---|
| Cost | 広告費用 |
| Impressions | 広告を閲覧した人数 |
| Conversions | 広告を閲覧して購入に至った顧客数 |
| Sales | 広告商品の売上 |
| CVR (Conversion Rate) | Conversion÷Impressions |
| CPA (Cost Per Action) | Cost÷Conversion |
| ROAS (Return On Advertising Spend) | Sales÷Cost |
こうしたデータは広告の効果測定の定量的な指標となり、より良い動画広告を作るのに役立てられます。
これらのデータはどのように取得できるかというと、それぞれの広告配信プラットフォームで広告配信データを取得するAPIが提供されており、例えばYouTube上で広告を一定期間配信したときはGoogle Ads APIで上記のメトリクスを取得することができますし、Facebook上で広告を配信した場合は、Facebook Marketing APIで取得できます。
データを活用するためには、まず広告配信プラットフォーム毎にデータを構造化して収集する基盤、いわゆるデータウェアハウスが必要になります。
本記事では、Google Adsの例をもとに、広告配信データを活用するためのデータウェアハウスの構築事例を紹介できればと思います。
設計
設計の際の前提として、
- データを加工する役割は後工程のマイクロサービスが担っているので、できる限り生の状態でデータを保存する
ということを意識しました。
今回新しく作るGoogle Adsデータ取得基盤は、大きく2つの役割を持っています:
- Googleアカウント情報（Google Adsアカウント、YouTubeチャンネルも含む）の管理を行う
- 連携中のGoogle Adsアカウントのデータを取得し、BigQueryに保存
データの取得から実際の利用までの流れは下図のようになります。
今回はデータ集計基盤は既存のシステムを利用するため、データ取得基盤のみが新規に開発する部分となります。
アカウント連携はAPIで実施し、広告配信データの取得は日時バッチ処理で実施します。
開発
Googleアカウント、Google Adsアカウント、YouTubeアカウントの関係性
今回のデータ取得基盤では、Google Ads APIを利用してデータを取得しますが、そのためにはGoogleアカウント、Google Adsアカウント、YouTubeアカウントの3種類をアプリケーションで管理する必要があります。なぜYouTubeアカウントの管理が必要かというと、動画をGoogle広告として出稿する際、その動画をYouTubeへアップロードしておく必要があるためです。 これらGoogle系のアカウントをアプリケーションで管理する際、ポイントとなるのは以下の2点です。
- GoogleアカウントとGoogle Adsアカウント / YouTubeアカウント は n : n（ActiveRecordでいうhas_many through）の関係であること
- oauth2のtokenはGoogleアカウントに紐づいていること（Google Ads APIやYouTube Data APIではそのoauth2 tokenを利用する）
1.の特性上、GoogleアカウントとGoogle Adsアカウント、GoogleアカウントとYouTubeアカウントの紐付けはそれぞれ中間テーブルで管理する必要があります。
GoogleアカウントとYouTubeアカウントって 1:多 じゃないの？って思うかもしれませんが、 ブランドアカウント という種別のアカウントがあり、複数のGoogleアカウントで1つのYouTubeアカウントを管理する仕組みがあります。
sensitive scope申請
APIをproduction利用するためには、Googleに申請が必要となります。
Google Ads API、YouTube Data APIを叩くのに必要なOAuth 2.0 Scopeはhttps://www.googleapis.com/auth/adwordsやhttps://www.googleapis.com/auth/youtubeだったりするのですが、これらはGoogleが指定しているsensitive scopeであり、利用の際に申請が必要となります。
申請せずに使うと、以下のような画面がユーザーに見えてしまいます。
さて、この申請はかなり面倒で、以下のような情報・ファイルをフォームで送信し、審査を待つ必要があります。
- oauth scopeを使用するアプリケーションの概要説明
- アプリケーションがどのようにscopeを使用するか
- アプリケーション中で実際にsensitive scopeを利用している動画ファイル（YouTubeにアップロードしてそのリンクを教えてあげる必要があります😇）
特にめんどくさいのが動画ファイルの提出で、アプリの開発がある程度進んでないと、動画を撮ることができないので申請もできません。申請してから数日でGoogle OAuth Trust & Safetyチームから反応が来ますが、不備を指摘されて動画の再提出を求められることもあるので、最初の申請から2〜3週間ぐらいを見ておいた方がいいかもしれません。
YouTube Data APIのquota申請
oauth申請が通ったら問題ないかというと、そうではありません。APIごとのquotaにも注意する必要があります。例えばYouTube Data APIのQuotaは Queries per day が 10000 に設定されていて、これは1日に動画が6本しかアップロードできないという極めてシビアな制限になっています。
このquota緩和にも申請が必要で、以下の専用フォームから申請を行う必要があります。こちらでもやはりアプリケーションの説明や動画ファイルの提出を求められます🥺
YouTube API Services - Audit and Quota Extension Form - YouTube Help
oauth scope申請とquota申請が終わったらやっとproduction利用可能になります。
テスト
実は今回最も難航したのはテストです。データ経路全体の最初と最後の値を照合をしたとき、Google Adsコンソールで表示される値と、実際にサービスで表示される値がずれているといった事がしばしば起きました。データ経路は先の図のようになっているのですが、問題箇所がどこなのか、BigQueryでクエリを叩いて中間データの値を確認するなど、地道なデバッグを強いられました。
こうしたパイプラインのテストで苦しまないためには、次の2点に注意する必要があります。
- 各工程での入出力をテストする
- 加工より後の工程ではデータを加工しない
1つ目は、各工程でのテストを充実させることです。目的は、各工程でデータの整合性を取れていることを保証するためです。各工程での入出力テストをしないままデータ経路全体のテストをすると、出力されたデータが元のデータと合わなかったとき、どの工程で合わなくなったのかの特定が困難になります。パイプラインが長くなればなるほど各工程での入出力テストは重要です。
これは当たり前のことのようですが、実際には細かい問題があってうまくテストできない箇所が出てきたりします。今回の場合は、データ取得をテストするためにGoogleアカウント、Google Adsアカウント、YouTubeアカウントの3つが必要だったため、まずデータ取得部分のテストが充実していませんでした。
また、データ加工部分（既存システム）の理解も甘かったため、データ加工部分も十分にテストできず、2箇所でテストが不十分な工程ができてしまいました。そのため、表示された値が違うときに、どちらの問題なのかを手作業で突き合わせて調べる必要があり、テストが難航しました。
より正しくテストするには、経路全体のテストに先立って、データ経路上の各点でダミーデータなどを用意し、入出力テストを回すべきです。
2つ目は、加工より後の工程ではデータを（可能な限り）加工しないことです。これもデータ経路全体での問題箇所を絞って特定するためで、あちこちで加工してしまうと、経路上のどの点でずれてしまったのかがわからなくなるためです。今回は、データ加工部分（既存システム）にできるだけ手を加えたくなかったため、その後工程でもデータを加工してしまい、経路上でデータを加工する点が複数できてしまいました。
この結果、問題箇所の特定がより難しくなってしまいました。 より正しい構成を取るなら、データ加工部分に全てのデータ加工を押し付け、それ以降の工程では、ただデータを次の工程に流すだけという構成にすべきでした。
Google以外への拡張（Amazon, Facebookなど）
今回はGoogle広告に関しての記事でしたが、広告APIの利用に関してはAmazon, Facebookなどでもハマりどころは似たようなものです。基本的に親アカウント : 広告アカウント = n : nで、あとはoauth2の仕組み通りです。
データ経路テストについて上記のような反省もあって、他媒体の広告データ取得基盤も順調に増えていき、Kaizen Adでは2021/12/02現在、Facebook, Google, Amazon, Yahoo, TikTokの5つの広告配信プラットフォームとデータ連携可能となっています。
まとめ
今回はGoogleの例をもとに広告配信データを活用するためのデータウェアハウスの開発事例を紹介しました。以下まとめです。
- GoogleアカウントとGoogle Adsアカウント、GoogleアカウントとYouTubeアカウントはn:nであること
- Google APIのsensitive scopeをproduction利用する際は、sensitive scope利用申請（必要に応じてquota申請）が必要
- テストで苦しまないためには、まずはデータ経路の各所で入出力テストを実施する。また、データを加工する箇所を絞り、問題箇所を特定しやすくすることも重要
今回はGoogleを例に説明しましたが、他媒体でも同じような構成になっています。広告配信データ取得では、その特性上、サードパーティのアカウント情報を用いてサードパーティの提供するAPIを叩く必要があります。こうした構成を真面目にテストするのは難しいのですが、実データとダミーデータを組み合わせながら、テストしたい機能に応じて使い分けていくというのが、今のところの結論です。
