カスタマーレプリゼンタティブチームの大屋戸 真章です。
広告代理店、MarTechSaaS企業での経験を経て、現在はデジタル広告のサービスを展開されている広告事業者様、複数の広告サービスを取り扱い、多くの広告主と取引されている広告代理店様の活用サポートを主に担当させていただいております。
前回は、私の代理店時代に取り組んだプロジェクトでの経験を基にした、広告配信レポート管理の事前設計のポイントを紹介いたしました。今回は、前回に続いて広告配信レポート管理システムの構築に向けてのデータ収集・レポート出力等のTreasure Data CDPの実運用のポイントについて、紹介していきます。
今回の目的とポイントのおさらい
上記イメージは、前回紹介した案件DB・共通カラム表の役割も含めたアーキテクチャです。データ収集・レポート出力の部分は処理内容の定義さえできていれば自動化する事が可能ですが、事業が進んでいくにつれて新しい案件・取り扱い広告サービスの追加が都度発生するため、都度定義のための手動作業が必要になります。
このように、広告配信レポート管理システムの運用には、自動処理・手動作業の領域が存在するため、それぞれの領域を組み合わせて円滑な運用ができるよう、特に手動作業の領域に関しては事前に運用手順を決めておく必要があります。手動作業が必要な箇所は、以下の通りです。
- 案件DBの更新と運用
- 共通カラム表の管理と参照
- 統一カラムへの名寄せクエリの作成
※図1の赤文字の部分にそれぞれ関連しています。
前回の各箇所への紹介に加えて、今回はこれらに関する運用手順についての解説を交えつつ、レポート出力までの運用管理の全体観についても紹介していきます。
案件DBの更新と運用
案件DBは「複数の広告サービスを横断した数値集計・分析」を実現するために、案件を管理するためのDBですが、システムに組み込むにあたって手動作業で運用する領域があり、運用手順を定める必要があります。以下、案件DBの運用手順についてのポイントです。
- 案件DB自体をデータ連携しやすいクラウドサービス上に構築
- 新たな広告サービスへの配信を行う際に任意のタイミング(案件受注時等)で案件データを手動で追加登録
- 追加した案件データに紐づくUNIQUE_IDの新規発行
- Treasure Data CDP上にConnectorを通じてバッチ連携しデータを更新
案件DBを構築するサービスとしては、Googleスプレッドシートやkintoneといったクラウド上で複数メンバーが共有して活用できるサービスを採用するのが最適です。案件データは、新たな広告案件が始まる際に追加登録します。広告代理店であれば、新たな広告主との取引を受注したタイミングであったり、自社で広告運用している場合であれば、新たな広告サービスへの配信を開始するタイミングで登録作業を行います。
案件DBを構成する要素は「ADVERTISER(広告主)」「PROMOTION(広告案件)」「MEDIA(広告サービス)」がメインであり、更新頻度も多いため、案件DBの子テーブルとして分けて管理する方法も有効と考えます。以下、DB/テーブルのイメージ例です。
また、UNIQUE_IDの形式は案件単位で重複しない値であればどんな仕様でも問題ありませんが、配信データとの紐付けのために「7tMRWv0i_plazma.red」のようにキャンペーン名にも使用されるため、固定長の文字列として扱えるようにしておくと便利です。UNIQUE_ID採番の仕組みは、一般的なDBのノウハウであり、Excelでも簡単に実装できるので、以下リンクも参考に仕様検討してみてください。
https://qiita.com/wakasamasao/items/77dea3eabb8e57c574c0
https://shikumika.com/%E5%9C%A8%E5%BA%AB%E7%AE%A1%E7%90%86%E3%81%AE%E3%82%B3%E3%83%BC%E3%83%89%E4%BD%93%E7%B3%BB/
共通カラム表の管理と参照
共通カラム表は、前述の案件DBと同様に「複数の広告サービスを横断した数値集計・分析」を実現するためのものですが、広告配信データそのものを統一管理する役割を担っています。共通カラム表自体は直接Treasure Data CDPに取り込みDBとして機能するものではなく、データを統一する仕様策定・クエリ作成の作業を進めるための対照表です。以下、広告配信データを取り込む際の、共通カラム表の運用手順のポイントです。
- 新たに取り込む広告配信データの仕様を確認
- 共通カラム表に当てはめて、統一仕様を策定
- 統一仕様に合わせて出力できるようクエリを作成
※共通カラム表に未定義のデータを取り込む場合は、カラムを新規追加する等の適宜仕様変更を行う。
管理システムへ新たな広告サービスの配信データを組み込んでいく際には、当然その広告サービスのレポートAPIの仕様を確認する必要があります。以下、仕様確認が必要なポイントです。
- 出力可能なデータ内容
- データ項目のカラム名
- データ項目のデータ型
以下、主要な広告サービスの仕様が掲載されているリンクになりますので、参考までに確認してください。
Facebook:https://developers.facebook.com/docs/marketing-api/reporting
Google:https://developers.google.com/google-ads/api/fields/v6/overview
仕様が確認できたら、データ統一をするために共通カラム表の当てはめていく作業に移ります。以下、当てはめ作業の例です。
新たな広告サービスを管理システムへ追加する際には、上記作業を行い対照表として管理しておく事で、クエリ作成もスムーズに進める事ができます。次に、こちらの対照表を参考にした統一カラムへの名寄せクエリの作成について説明します。
統一カラムへの名寄せクエリの作成
以下、広告配信データと案件DBデータをUNIQUE_IDをキーにして紐付けを行い、「配信報告レポート用」「社内KPI数値管理シート用」それぞれのDB・データマートに出力するための名寄せクエリによるデータ連携イメージです。
また、名寄せクエリ作成にあたって必要な要素は以下です。
- 広告配信データ内のUNIQUE_IDを文字列として抜き出し
- UNIQUE_IDをキーに広告配信データと案件DBデータを紐付け
- 共通カラム表を参考に、統一したカラム名で出力
- 紐付け後データのディメンションの最小単位にてIMPS等の数値項目について集計
※本事例ではAD_IDが最小単位
上記内容でクエリ作成・実行を行い、まずは広告サービス単位でデータ出力していきます。実際のアウトプットに関しては、それぞれの出力条件に合わせてクエリ作成・実行を行います。複数のDB/テーブルを跨いだクエリ実行になるため、参照するデータ量・処理量が非常に多くなる事が想定されるため、基本的には夜間の日次バッチで定期実行するのが一般的です。
まとめ
- 広告配信レポート管理システムの運用には、自動処理・手動作業の領域がそれぞれ存在する
- 案件DBは複数メンバーが共有して活用できるクラウドサービス上に構築
- UNIQUE_IDは重複しない固定長の文字列を仕様とするのが最適
- 共通カラム表はデータを統一する仕様策定・クエリ作成の作業を進めるための対照表
- レポート出力クエリは、複数のDB/テーブルを跨ぎデータ量・処理量が多いため、夜間日次バッチで対応
前回、前々回と合わせて、3回に渡って広告配信レポートの管理手法について紹介させて頂きました。今回はデジタル広告にフォーカスして解説しましたが、今回の手法はデジタル広告以外のCRM領域の施策結果レポートにも応用できます。それができれば、デジタル上のあらゆるユーザー接点を網羅した上で、デジタルマーケティング活動の成果を定量的に可視化する事ができます。そうする事で、施策毎の良し悪しが如実に分かり、次のアクションを明確にし、マーケティング活動そのものを確実に改善に繋げていくことができます。
ある程度の事前設計が必要ではあるものの、それさえ整えばTreasure Data CDPの機能を駆使し簡単なステップで実装が可能なので、是非本記事を参考に実践いただけますと幸いです。