Treasure Data CDPを使った広告配信レポート管理システムの構築 – 事前設計 –

今回の目的とポイントのおさらい

大まかには上記のようなイメージで異なるサービス間の連携を行い、システム構築をしていきます。前回に引き続き、広告配信レポート管理システムの主な構築目的は以下です。

• 配信報告用レポート出力の自動化
• 社内KPI数値管理シートの内容更新の自動化
• 複数の広告サービスを横断した数値集計・分析

これらを実現していくにあたって、今回紹介する事前に把握・定義しておくべきポイントが以下の4点です。

1. 管理対象の広告サービスの策定
2. 案件DBの作成と定義
3. 共通カラム表の作成と定義
4. 出力するレポート内容の定義

※図1の赤文字の部分にそれぞれ関連しています。

これらは、Treasure Data CDPで自動処理を行う前の段階における手動運用の部分であり、その運用に際しての事前設計のポイントとなります。以降、各ポイントについて解説をしていきます。

管理対象の広告サービスの策定

実際にレポート出力する対象の広告サービスを決めます。基本的には予算割合が大きく取り扱う金額の大きい広告サービスを優先し、リストアップしていきます。それらをメインの広告サービスとし、以降必要に応じて対象の広告サービスを増やしていき、随時対応、運用していく形になります。
※私が実際に関わったプロジェクトでは最終的には約50の広告サービスを対象していました。

ただ、各々の広告サービスでは当然仕様は異なり、レポートデータ取得の方法も一様ではありません。まず、その広告サービスのシステム仕様が、Treasure Data CDPを介してレポートデータが取得可能な仕様である、という点がレポート管理システムに組み込む最低条件になります。Treasure Data CDPにてデータ収集する事を前提に、基本的には以下条件が満たせれば組み込み可能と考えます。

• 既にTreasureDataと連携済で、DataConnector等を用いて直接データ収集ができる
• 広告レポートAPIが公開されている
• Amazon S3等の外部ファイルストレージにデータを定期的に格納できる

案件DBの作成と定義

案件DBを作成し利用する事によって、今回の目的である「複数の広告サービスを横断した数値集計・分析」が可能です。同じ広告主・案件であっても、広告サービス毎でアカウント管理されている都合上、異なる形式で管理されているため、同一の広告主・案件として同一視する事ができません。案件 DBは、自社で案件管理・独自ID発番と付与によって上記問題を解消し、異なる広告サービス間であっても広告主・案件を同一視できるようになり、自由度の高い数値集計・分析を実現します。

案件DBの仕様と使い方

• 広告案件単位で一意性をもったユニークIDを主キーとする
• ID毎に広告主・案件・広告サービス・プラットフォームの要素で案件識別が可能
• 新規広告主・案件の場合は、運用上各種IDの新規発番が必要
• 収集データの加工時に上記IDを抽出し、案件DBと連携
• 上記IDを広告キャンペーン名に登録し、配信データに含めて収集できるようにする
• 例. 広告サービスの編集画面等で「7tMRWv0i_plazma.red」のような形式であらかじめキャンペーン名登録をしておく

案件DB例

共通カラム表の作成と定義

広告サービスによってレポートの仕様は異なりますが、あらかじめ共通カラム表を準備しておけば、同じ意味合いの項目・数値を統一した指標で見る事が可能です。前項で紹介した案件DBと組み合わせる事で、広告サービス毎の個別のレポート仕様に左右される事なく、様々な出力条件で柔軟性高い数値集計・分析を行えます。

共通カラム表の例

新たな広告サービスのレポートを実装する際には、上記共通カラム表に各カラムを当てはめて、対照できる状態に整理・更新をします。それに加え前項の案件DB・ユニークIDの準備が整った段階ではじめて、SQL・Workflowの実装準備が整います。

出力するレポート内容の定義

今回出力を想定しているレポートは、「配信報告用レポート」「社内KPI数値管理」の2つです。ここでは配信報告用レポートの内容について紹介します。配信報告用レポートでは、主にGoogleスプレッドシート等に出力し、Excel・CSVファイルで扱う事を想定しています。私が広告主へ報告する際には、以下のような日別・クリエイティブ別で集計したレポートをそれぞれ提出していました。

日別レポートサンプル

上記の様に、日別・クリエイティブ別で集計を行う場合は、日単位・クリエイティブ単位で集計を行える必要があるため、元データも、日別・クリエイティブ別のそれぞれの粒度で収集できている必要があります。多くの広告サービスでは、日別・クリエイティブ別レポートは別々で出力されるケースが多いですが、分析の観点で日別 x クリエイティブ別単位でデータ収集できるのがベストです。以下、日別 x クリエイティブ別単位の元データ例。

日別 x クリエイティブ別単位の元データ例
社内KPI数値管理に関しては、次回記事にて元データ例も交えて紹介します。

まとめ

• 管理対象の広告サービスは、現実的にレポートデータが取得可能な仕様かどうかを見極めて組み込みの判断を行う
• 横断的な数値集計・分析をするために、案件DB・共通カラム表の作成と運用が必要
• 案件DBの主キーであるユニークIDは、キャンペーン名等に付与し配信データに含めて収集・抽出できるようにしておく
• クリエイティブ別レポート等、出力するレポートの内容によって必要な元データの粒度が異なるため、出力内容を事前に把握した上で元データは準備しておく

今回は、広告配信レポートを管理していくにあたって、事前設計のポイントについて紹介させて頂きました。次回は、実際にTreasureDataを使ったデータ収集・レポート出力について解説したいと思います。