広告KPIダッシュボード開発でPDCA回してみた

※ Retty Advent Calendar 2018 10日目の記事です。  
昨日は、[@daiki-futami](https://qiita.com/daiki-futami) くんの [BigQueryとColaboratoryではじめる決定木・ランダムフォレスト入門](https://qiita.com/daiki-futami/items/04bcb1ee467491a9025d)でした。


はじめまして。本日はRetty新卒エンジニアの [@threepipes_s](https://qiita.com/shogo-tsutsumi) がお送りします。
本日は、運用型広告のKPIダッシュボードを作成したときの話となります。

今回のダッシュボード作成では僕自身はメインで手を動かしたわけではなく、どちらかというと(超小規模な)PM[^1]として動いたので、その時の知見や苦労を残す目的で書きました。

[^1]: [プロジェクトマネージャーとは？](https://it-koala.com/project_manager-2643)

---

# その0. 背景

## 運用型広告のこれまでのダッシュボードとその課題点

弊アドテクチームでは、運用型広告[^2]の配信KPIについて一元化されたダッシュボードを持っていませんでした。
これまでは、運用型広告の各配信元が提供するレポートを確認し、それをSpreadSheetに手動でまとめるというアナログチックなレポートを運用していました。
配信元も数十あるために毎日30分〜1時間掛けて集計しており、ちょっとした負荷となっていましたが、チームで追いかけているKPIが優先であったため、工数削減は後回しになっておりました。

[^2]: [運用型広告とは - デジタルマーケティングラボ](https://dmlab.jp/words/e029.html)


## Pubdeskを利用したレポートの一元化

そんなときに、運用型広告レポートの一元化を行うPubdeskというサービスの話を聞き、それを利用することとしました。  
[エンハンス、媒体社向けBIツール「Enhance Pubdesk」の提供を開始](https://www.microad.co.jp/news/detail/974/)

各所に散らばっているレポートを集約してくれるので、今まで手動で行っていたレポートが日々の作業0で手に入るようになりました。
しかし、

- Pubdesk上には求めているグラフがなかったこと
- Pubdesk APIを利用して外部連携しやすかったこと  

という点から、こちらでひと目でKPIがわかるダッシュボードを作成して、SlackにPOSTしようということになりました。

---

# その1. Python + AWS lambda + Tableauによるダッシュボード作成

ダッシュボードの作成は、インターン生として来てくれていたうちはらくん[^3]と協力して行いました。
要件を僕がまとめ、うちはらくんが実装してくれたことにより、以下のような構成でダッシュボードの基礎を作成しました。

<img width="800" alt="スクリーンショット 2018-12-10 18.32.07.png" src="https://qiita-image-store.s3.amazonaws.com/0/33930/22f41479-8681-a872-a1ac-33cade41451f.png">


1. Pubdeskの提供するAPIからデータを受け取ってSpreadSheetに連携
2. TableauのSpreadSheet連携によりTableau上でダッシュボード生成
3. TableauのグラフをSlackにポスト

という流れとなっています。

今回は最初にスケジュールを引いて各機能ごとに作成していく、ウォーターフォールモデルに近い開発方法を取りました。


[^3]: 名前は本人の要望により(なぜか？)ひらがなに

## ダッシュボード作成にあたっての計画

打ち合わせでは、以下のように計画を立てました。

- 期間: 3週間
  * 1週目: SpreadSheetからTableau連携
  * 2週目: ダッシュボード作成 + PubdeskからSpreadSheet連携
  * 3週目: TableauからSlack連携
- 要望(主にダッシュボード)
  * 日次や月次ごとにまとまった収益を確認したい
  * 配信元ごと、広告枠ごとに収益を比較確認できるグラフがあると嬉しい
  * などなど...

以下のようなホワイトボードメモを書きながら相談しました。

![image3.png](https://qiita-image-store.s3.amazonaws.com/0/33930/e6050d12-4018-5ca5-8c2a-6afa88fdfe0a.png)


### 準備不足の反省 

スケジュール感や全体の構成については考えていたものの、

- ダッシュボードの形の案
- ダッシュボードにおける要望

の準備がなく、うちはらくんの着手が1日ずれてしまったことは反省点です。
知見を持っていなかったダッシュボードについては、予め詳しい人と打ち合わせをしておくことが大事ですね。

また、技術選定に関してももう少し練れたのかなとは思います。
今回、

- Python + lambda によるサーバーレスアーキテクチャ
- Tableauによるダッシュボード作成

でしたが、SpreadSheetを用いているならGASという選択肢もありますし、GoogleDataStudioでもダッシュボードを手軽に作ることができます。
プロジェクトスタート前の準備不足も今回の反省点です。

## スケジュールは滞りなく進行

実装に関しては、うちはらくんが割とサクサク進めてくれました。
lambdaやGoogleの認証周りで躓きつつも、自分で調べて自己解決してくれていたので、僕自身はスケジュール管理やその他の仕事に集中することができました。

多少前後しますが、おおよそ以下のように進行しました。

|日程|内容|
|---|:--|
|8/28, 29|打ち合わせ|
|8/29-31|SpreadSheetからTableau連携|
|9/3-5|Tableau上でダッシュボード作成|
|9/5-6|Pubdesk APIからSpreadSheetの連携|
|9/6-7|TableauからSlack連携|
|9/10-13|localからlambdaへの置き換え|

### 成果発表について忘れていた...

以下の2点についてスケジュールから漏れてしまっており、かなりぎりぎりになってしまいました。

- localからlambdaへの置き換え
- インターン成果発表とその準備時間

インターン成果発表周りについては、うちはらくん直属メンターや採用チームと連携が取れていれば防げたと思われるので、そこは反省ポイントです。

## Slackへのダッシュボード共有が完了

最終的には、以下のようにSlackにダッシュボードが共有されるようになりました。(諸事情により数値は黒塗りです)
ダッシュボードの洗練までは時間の都合上行えなかったため、後ほど作り込むことにしました。
<img width="490" alt="スクリーンショット 2018-12-10 18.43.23.png" src="https://qiita-image-store.s3.amazonaws.com/0/33930/47b4cbf6-0fb8-1044-4e1d-1815c5d17872.png">



---

# その2. Tableau上のダッシュボードをPDCAサイクル回して洗練

上で作ったダッシュボードを、実際の運用で使いやすいように @iwanaga-jiro さんと協力して洗練させていくことにしました。  
役割分担としては、

- @shogo-tsutsumi : 広告でのダッシュボードについての要望を伝える
- @iwanaga-jiro : 必要なダッシュボードの作成

として、進め方としては

1. Plan: ざっくり @shogo-tsutsumi から欲しいダッシュボードの要望を伝達
2. Do: @iwanaga-jiro さんがそこに合わせてざっくり作る
3. Check: レビュー
4. Action: 次の要望を練る

を繰り返して洗練させていくという、PDCAっぽい方法を取ることになりました。  
これは @iwanaga-jiro さんのアドバイスだったのですが、それは以下のポイントがあったためとのことでした。

- お互いの領域に詳しくない
  * @shogo-tsutsumi : ダッシュボード作成経験なし
  * @iwanaga-jiro : 広告領域に詳しくない
- お互い工数があまり割けない
- 隣の席なので、意見交換は割といつでもできる
- 作成期限は特になかった
  * 上3点より、かっちりスケジュールは決めずに都度

お互いがお互いのドメイン知識を持たなかったので、その辺りをすり合わせながらのPDCAサイクルを回していきました。

## 1サイクル目

- Plan
  * 様々な要望を出した後、話し合いで以下に絞りました。
    - データの粒度
      * 日次・月次
      * 枠ごと・配信元ごと
    - データ項目
      * 収益
      * 表示単価
      * 表示回数
    - 利用目的
      * 月末収益の予測
      * 異常値検知
      * 施策影響の確認
- Do
  * それに合わせて、@iwanaga-jiro さんが以下のようなグラフを作成してくれました
  * (数値ラベルは諸事情により削除しています)  
<img width="500" alt="スクリーンショット 2018-12-10 19.34.34.png" src="https://qiita-image-store.s3.amazonaws.com/0/33930/eb15d2af-3e51-b29e-29d8-d512ed523963.png">



- Check
  * 広告枠という単語について、お互い認識の違う部分を確認
  * 表示単価が認識とずれた数値だったことを確認
  * Dailyで投下するので、月次軸は保留に

- Action
  * 広告枠について認識すり合わせ後、その箇所についてのダッシュボード作成を依頼
  * レポート記載の表示単価が期待と違ったため、Tableau上で改めて計算をお願いすることに
  * また、合計値が大事な項目については、積み上げ型のグラフで依頼

## 2サイクル目

- Plan
  * データ期間を増加(7日間 => 30日間に)
  * 1サイクル目でActionに上がったものについて追加
  * 積み上げ型グラフで合計をわかりやすく
- Do
  * 積み上げ型グラフの追加等
  * (画像では数値ラベルを削除しております)
<img width="500" alt="スクリーンショット 2018-12-10 19.27.18.png" src="https://qiita-image-store.s3.amazonaws.com/0/33930/0cf4c22a-f7a7-29f1-0ea6-bc5bd9abd21b.png">

- Check
  * 問題なし！
- Action
  * 必要なグラフの絞り込みをして、Slackへ投下
  * あまり大量のグラフを投げても見なくなってしまうとのことで、6つのグラフに絞って投下することにしました

## そして運用へ

最終的には、このようにSlackに日々のダッシュボードが投下されるようになりました。(数値をぼかすために画質を荒くしています)
各配信元が収益にどの比率で影響を与えているのかが一発でわかり、日々の施策効果検証やエラー検知に役立っています。
<img width="300" alt="スクリーンショット 2018-12-10 18.57.21.png" src="https://qiita-image-store.s3.amazonaws.com/0/33930/7bba1e48-fa2d-cb8a-baf4-8f24237e74d6.png">



## PMとしての学び

今回、自分が主に依頼側としてダッシュボード作成に携わりました。
PM側に立つことで、普段の実装者観点とはまた違った体験ができ、新たな知見が得られました。

また、短期PDCAを回すことにより以下の気づきが得られ、解決していくことができました。

- 自分がどういうダッシュボードにしていきたいか把握・考察していなかった
  * ダッシュボードの用途を整理しておき、伝達すること
- 要求する側だと、あの機能もこの機能も欲しいと言いがち
  * フィルタリング機能など
  * できることには限りがあるので、優先度をつけて要望を出すこと
- 今まで使っていたダッシュボードに案を引っ張られがち
  * まずはブレスト