こんにちは。バンダイナムコネクサス データエンジニアの上田です。

※ この記事は、記事執筆者の代理として藤井によってアップロードされています。内容に関する質問やコメントは藤井経由にてご連絡ください。

今回は題目のとおり、広告出稿のKPI最大化のためのデータ基盤開発について紹介します。

今回はプロジェクト発足に至った背景やプロジェクト運営上の工夫を紹介していき、次回以降詳細な技術的な内容などをご紹介していきたいと思います。

対象読者はデータ基盤新規開発プロジェクト立ち上げに将来携わるエンジニア、PM、ビジネスサイドのメンバー全員を想定し、これから広告関連のデータを触る予定のエンジニアやPMはもちろん、広告関連のデータに関わりのない方、非エンジニアの方にとっても有益な情報となることを願います。

記事に書いてあること

今回の記事

• プロジェクト開始当初の課題
• 課題解決の取り組み
• システム概要
• プロジェクトを円滑に行うために発足時に決めたルール

次回以降の記事

• 解決策を詳しくご紹介予定です

プロジェクト開始当初の課題

広告出稿のKPI最大化のために、広告運用者は

・どこにどんな広告を打つべきか検討する
・予算の配分を決める
・各広告施策がよかったか振り返る

をスピーディーに行う必要がありますが、次のような課題があります。

課題①: 単調な作業をできる限り効率化したい

バンダイナムコグループでは多様なIP（知的財産）を取り扱っているため、さまざまな種類の広告をいろんな場所に出稿しています。
　→ 各広告を管理する時間的人員的コストがかかる。データのダウンロードやフォーマットの決まっているレポート作成など単調な作業も多い

また弊社の広告出稿実績の指標は、IPごとに特性があったり、ゲームのイベント時や大型連休に広告出稿に力を入れるなどの背景から、指標が継続して安定した値を取る形にはなっていません。
　→ データの解釈が難しく、予算配分の戦略を練るのが一筋縄ではいかない

そのためデータ収集など単調な作業はできる限り効率化し、ユーザーコミュニケーションや予算配分の戦略を練ることに時間を使いたいと考えていました。

課題②: 各媒体が提供している管理画面をそれぞれ見に行くのに時間がかかる

次に示すようなものを始めとした多くの媒体に広告出稿しています。

• Facebook
• Google
• Twitter
• Apple
• TikTok
• LINE
• など...

そのため各媒体の管理画面にそれぞれアクセスし、実績確認するのに時間がかかってしまっていました。

課題③: 管理画面で見られる以上の視点での振り返りに課題がある

各広告媒体の管理画面で見られる以上の視点での振り返りを効率的に行いたいというニーズが弊社運用担当者から上がっていました。

例えば、 どの広告媒体での出稿がうまくいったかを媒体ごとに比較したいといった場合には、運用担当者が各媒体の管理画面からアプリごとにデータを手動でダウンロード、エクセルで各媒体のデータを突合し、レポートを作成する必要があります。

手作業でのレポート作成には以下のような課題があります。

• 工数がかかる
• 休日にはレポートを作成できないので、実績確認できない。
• • ゲームアプリは特に連休にデータを確認できることが望ましい
• 人間がレポート作成するため、想定外の作業ミスを0にできない

課題解決の取り組み

これらを解消するため2点実施しました。

1. 出稿している広告のデータを毎日収集し、利用しやすく整える
2. 出稿している広告の実績レポートを自動で作成し、広告運用者がいつでも参照できる状態にする（データの民主化推進）

具体的な取り組み詳細に関しては、この後連載していこうと思います。

システム概要

現在（課題解決の取り組み案に記載した1~3が実施済み）のシステム概要は下図のような感じです。

図に示したようなデータの流れで、収集したデータをそのままCloud Storageに保存し、AirflowでBigQueryに格納しています。

発足時に決めたルール

先日プロジェクトの振り返りを行なった際に洗い出すことができたのですが、発足時の段階で決めたことで良い効果があったルールをご紹介しますので、皆様の参考になればと思います。

利用者（広告運用担当者）との期待値

最初に期待値を擦り合わせたことで、開発の優先順位設定などの判断がしやすかったです。

期待値

• 午前中のうちに前日のデータを見る
• 直近1ヶ月のデータは洗い替える
• 週末や年末年始などの連休時もデータが見れるように安定稼働できる設計をする
• データやシステムに問題が発生した場合にはもれなく検知、通知する
• 非営業日にエラーが発生した場合、翌営業日に対応開始
• テスト項目を作成し共有。テストを通過したデータを提供する

コミュニケーションの頻度

リモートで作業していたのでコミュニケーションのしにくさが発生しないように以下のようにすることで 柔軟なタスク調整、軌道修正を行うことができました。

• 最低でも週に1~2回定例を行うことを決めました。
• • 特に議題がなければスキップ
• 定例以外のタイミングでも必要があればslackで声をかけたり、会話する

slackのメンション

リモートで作業していたのでslackがメインのコミュニケーションツールとなります。 情報の取りこぼしを防ぐため、心理的安全性のため以下のようにしました。

• 情報の取りこぼしを防ぐため相手が業務時間外の場合でも必ずメンションをつける
• • 情報の取りこぼし防止のため　
    ・「メンション&リアクション」から辿れる

• • スレッドでやりとりしていても埋もれにくくするため
• メンションされても都合の良い時に確認する
• • 上記ルールにしているので業務時間外でもメンションされる場合があるが、受け取り側が好きなタイミングで確認する。

異常検知

システムを安定稼働させることはもちろん利用者との期待値「データやシステムに問題が発生した場合にはもれなく検知、通知する」を実現するためにも異常検知をケースに分けて必要な担当者に通知するようにしました。

• システム自体に問題が発生した場合のアラート
• • データ基盤設計を担当しているエンジニアが多く参加するslackチャンネルに通知
• 加工するデータの未着やデータ自体の異常の場合のアラート
• • 広告データに関わるプロジェクトメンバー（エンジニア、PMなど全員）に通知
• Lookerのsync遅延検知
• • Looker dashboard上で表示し、ダッシュボード利用者全員が異常が確認できる状態

担当者別に通知をすることで、各担当者への最低限のアラートでスムーズな対応ができています。

おわりに

具体的な取り組み詳細に関しては、この後連載していこうと思います。

最後まで読んでいただきありがとうございました！

もっとバンダイナムコネクサスについて詳しく知りたい方はこちら

バンダイナムコグループのデータ基盤をリードするリードデータエンジニアを募集

バンダイナムコグループのデータ基盤を支えるデータエンジニアを募集！