マーケティングデータ
複数媒体の広告データを、毎日自動更新するパイプラインへ
Google Ads、Meta Ads、広告素材、見込み客データをBigQueryへ集約。分析のたびに手動で書き出す必要をなくしました。
課題
広告実績が複数の媒体に分散し、アカウント、項目、更新方法、成果の定義も異なっていました。手動出力で一時的なレポートは作れても、安定した再実行は困難でした。日次データが欠けても、API、権限、スケジュール、スキーマのどこが原因か分かりませんでした。
制約
- Google AdsとMeta Adsでは認証方式、利用上限、データ構造、更新時期が異なります。
- トークンの失効や変更があり、媒体側の項目も共通のリリース周期とは別に変化します。
- 実際の広告費、顧客名、キャンペーン、広告素材は公開できません。
取り組んだこと
分析用に整える前に、元データを残す
媒体のデータをまずBigQueryの追跡可能な元データ構造に保存し、変換層で共通の軸と指標をそろえます。
見送った選択肢 抽出時に一つの汎用レポートへ集約すると、媒体固有の意味や再計算の根拠が失われるため、この方法は採りませんでした。
処理の流れを、監視できるシステムにする
Cloud Workflowsで日次処理を制御し、媒体別の抽出、素材処理、見込み客情報の取得を識別できる手順に分けました。
見送った選択肢 全作業を一つの長時間プロセスに詰め込むと、障害箇所の特定と再実行のコストが大きくなるため避けました。
再実行しても結果がそろう書き込みにする
取得元と日付範囲で更新対象を限定し、同じバッチを再実行しても一貫した結果になるようにしました。
見送った選択肢 成功を前提に追記し続ける方式では、APIの一時障害から復旧した際に重複や欠損が生まれるため採用しませんでした。
アクセス障害とデータ障害を分ける
認証、利用上限、スキーマの問題を別々の情報として残し、原因を特定しやすくしました。
見送った選択肢 失効した権限は時間を置いても直らないため、すべてのAPIエラーを同じ再試行対象にはしませんでした。
成果
- Google AdsとMeta Adsのデータを毎日BigQueryに取り込みます。
- 複数媒体の分析を、手動ファイルの寄せ集めではなく一つのクエリ層から始められます。
- 素材処理と見込み客情報の取得が、追跡可能なクラウド処理の中で動きます。
技術
- Google Ads API
- Meta Marketing API
- BigQuery
- Cloud Workflows
振り返り
やり直すなら、データ鮮度の基準とスキーマの契約をもっと早く定めます。届いたデータが、そのまま使えるとは限りません。遅延、補完、媒体の項目変更を、レポートに届く前に把握できるようにすべきでした。