はじめに
この記事のターゲットに関して
どうもpixivで運用型広告でのマネタイズ周りを担当しているyattyoです。
この記事はメディアのマネタイズ手法として運用型広告を活用されている方々に向けた記事です。レポーティングで悩みを持っている方に参考にしていただける内容になっていると思います。
とりあえず結論だけまとめる
レポーティングを自動化すると確実に負担は減ります。
30時間/月かかっていた作業が1時間/月になりました。
ただし、メンテナンスコストなどの追加コストは発生します。
とくにマッピングコストなどは結構大きいです。
最初にしっかりと設計すると多くの追加コストを削減できます。
レポーティングの自動化に限れば、事前に知っておくべき項目は後述します。
なぜレポーティングを自動化するのか
経緯
前提として、アドネットワークやSSP等を使用して広告によるマネタイズを行っているメディアにおいては、複数の第三者配信サービスを使用して収益性の比較・検討を行っていることは珍しくありません。それに加えて、Prebid.jsやTAMなどのソリューションの登場により直接の取引をする事業社が増え、それに伴いレポーティングが煩雑になる問題が囁かれておりました。 弊社も例に漏れず、この問題に直面しました。
もともと私のチームでは、毎朝、手作業で、全ての広告枠の数値を事業社ごとに取得していたため、「膨大な作業コスト」「手作業によるミス」や「作業の属人性」などのデメリットが存在しました。毎朝、数値を人間が見ることで数値変動に対して機敏に反応することはできましたが、Prebid.js導入後はコストのほうが大きくなり、チームメンバーがより本質的な作業に集中できるようにレポーティングの自動化を決断しました。
結果的にすべての作業を自動化することはできませんでしたが、上記のような問題点の多くは解消されました。（新たに生まれた問題もありますが）
どのように自動化したのか？
方法の選定
レポートを取得する方法に関して、知り合いのメディアにヒアリングを行い、大体4パターンに分けられることがわかりました。
- 自社でAPIやスクレイピングなどを用いて自動化
- 他社に委託
- アルバイトや業務委託を雇って手動取得
- 現状のメンバーで手動取得
弊社では「自社でAPIやスクレイピングなどを用いて自動化」を採用しています。この決断は個人的には良い決断だったと思います。 次点で「他社に委託」という選択肢が有力だったのですが、「固定費の削減」「データの漏洩リスク」や「動きの身軽さ」という理由で自社での自動化を採択しました。
自社での自動化方法
全体の大まかな流れは下記になります。
- レポート取得
- 数値集計と広告枠マッピング
- ビジュアライズ
1.レポートを取得する
まずは、すべての事業社を3パターンに分けて、それぞれに応じて対応していきました。
- APIを提供している事業社
- CSVを提供している事業社（スクレイピングやオブジェクトストレージを利用）
- その他事業社（例外 or 使用頻度が低い）
結果的には、下記のような方法で取得したCSVから数値を取得します。
完全自動系
- API経由でCSVやJSONをダウンロード
- オブジェクトストレージ経由でCSVをダウンロード
- スクレイピングを行いCSVをダウンロード
半自動系
- 管理画面から手動でCSVをダウンロードし、GoogleCloudStrageに保存
手動系（例外 or 使用頻度が低い事業社）
- 管理画面数値を手動でGoogleスプレッドシートにコピペ
実際の作業
下記のような順番で事業社を選別するのが良いと思います。
1.APIを提供しているか確認する。
管理画面上などに記載がなくても事業社の人に直接質問するのが吉です。隠し持っている場合があります。
2.オブジェクトストレージの提供を確認する。
オブジェクトストレージ上に決まったタイミングでCSVを置いてくれるシステムを持っているかどうか事業社の人に直接確認します。隠し持っています。
3.スクレイピングが可能かどうかを確認する。
スクレイピングに関しては安定性を確認するべきです。弊社では動作が安定しない事業社や、そもそもGoogle経由でのスクレイピングをIP単位でブロックしている事業社がありました。
結果的にそういった事業社は「特定のドライブに手動で取得したCSVを保存し、そのファイルをDBに反映させる」という処理にしました。
上記以外に、あまりにも使用頻度が低すぎる事業社や特殊な操作が必要な事業社に関しては各社の管理画面上から直接スプレッドシートに手動で数値を打ち込む従来の作業を残してあります。
結果的には、これにより新しくテストしたい事業社なども大きな工数なくテストすることが可能になっています。
2.数値集計と広告枠マッピングをする
前の工程で取得したレポートをBigQuery上に集約・加工します。 しかしレポートを取得しただけでは、自社内で認識している広告枠と事業社の管理画面上で認識している広告枠に関連性がないため、マッピングする必要があります。
弊社ではスプレッドシートを使用し、事業社の管理画面上の広告枠IDと自社内で認識している広告枠・デバイス・OS・サービスを記載することで自社内と事業社の広告枠の認識を紐付けています。これにより最終的なビジュアライズを直感的に行えるようになりました。
3.ビジュアライズする
弊社では「Looker」というBIツールを使用しています。 これにより誰でもSQLなしでDB上のデータをビジュアライズすることができます。 また、ダッシュボードを作成することで常に見ておきたい数値を表示させることも可能です。私のチームではRaspberry Piを利用して常にモニタ上に直近の収益推移などを表示しています。
気をつけるべきところ
APIやそのマニュアルを隠し持っている事業社があります。
自力で見つけられなくても問い合わせてみましょう。
CSVの取得が安定しない事業社があります。
弊社では取得に失敗した事業社に関してslack上にエラー通知を飛ばす仕組みにしています。
一部のツールからのアクセスを遮断している事業社があります。
GoolgeCloudからのアクセスがIP制限され行えないケースが有りました。
お目当ての数値を含んだCSVを取得するのに、特定のページまでアクセスする必要のある事業社があります。
広告枠別にCSVを取得するために管理画面に登録してる各メディアごとにCSVを取得する必要がある事業社で、
メディア別のページから合計3回CSVを取得しています。
例外的な取り組みをすると、管理画面上にレポートが反映されなくなる事業社があります。
例えば、eCPMを固定した取り組みなどを行う際に収益がレポートに反映されなくなる事業社があります。
人間が行う作業は限りなく少なくするべきです。
人間はミスしますし、作業を後回しにします。
新たに発生した問題
マッピングコストが非常に高くなりました。
事前のマッピングや広告枠の命名規則をちゃんとしておけばよかったと反省しました。現状だと広告枠名から広告枠の情報を取得するのが難しい場合が多いです。
例外事業社に対応するために迷宮のようなスプレッドシートを作成してしまいました。
教育コストを余計にかけてしまいました。ここに属人性が残っています。
総括
よかったこと
1.ともかく作業コストが激減しました。
30時間/月→1時間/月になりました。チームのみんなからもストレスから開放されたというフィードバックをもらいました。加えて、長期連休など収益を入力する作業がなくなり非常に良い正月休みを過ごせました。
2.数値の正確性が格段に上昇しました。
人間の手動管理がなくなったため、把握・入力が漏れている広告枠や入力ミスが無くなりました。ドル円相場以外の差は殆どありません。
3.ビジュアライズ・分析が超絶簡単になりました。
ちょうどいいタイミングで弊社がBIツール「Looker」を導入し、すべての数値をGoogle BigQueryに集約し一元管理したことで以前よりも格段に早く数値をグラフ化することができるようになりました。
Lookerに関しては@jaggyの記事を御覧ください。
4.他のチームが簡単に広告収益を見れるようになりました。
配信環境の変動が激しく他チームが広告収益を把握するのはかなり難しかったのが、Looker上でかんたんに数値を確認することができるようになりました。
広告収益の上がり下がりの意思疎通が簡単になり、広告実装のやる気アップにもつながったと感じています。
わるかったこと
導入初期段階に複雑な手動作業が多く残った。
エンジニア工数を気にしすぎるがあまりビジネスサイドで巻き取れるタスクを無理して巻き取った結果、導入初期段階では手動作業が多く残りました。（現在は解決しています。）
この実装を通して学んだこと
すべてのタスクは終わりを意識する。
アウトプットを決めて動き出す。
知ってはいましたが改めて実行するのは難易度が違うと再認識しました。
自動化するなら極力人間の手は入れないような設計にする。
エンジニアの工数が多少大きくかかっても遠慮しない。
人間の手が介在すればするほど不安定なシステムになります。
事前にマッピングが行いやすい状態を整えておく。
データを扱うのであれば、あとからデータにラベリングしやすい形を前もって整える。
例えばすべての事業社の広告枠名に命名規則をつけておけば、広告枠名から自動的にマッピング作業を終わらせることができたはずです。
