Ric.'s rubbish heap.

~ Ric.の掃き溜めブログ ~

VOYAGEで遅めのAdventureしてきた話

f:id:Ric418:20191225062140j:plain

しれっとTreasure Advent Calendar 2019の13日目に入れちゃいました…笑

今回はVOYAGE GROUPさん(以後VG)のZucksデータチームの西林さんの元(お隣)で9月に行われていたAdventure

voyagegroup.com

の内容をベースにしてAd-networkにおける…

この辺りを三日間で総ざらいしていく形で参加させて頂きました! 講師の西林さんの伝えたかった事のまとめもありますのでこちら

hagino3000.blogspot.com

も合わせて是非!

参加の経緯

もともとアドテク分野において

  • DSPのモデルを組んだことはあったがAd-networkでの経験は無かった

ということもありましたが、何よりも

  • VOYAGE GROUPさんでの実際の執務の動きがどの様な形なのか

これがTREASURE参加以来一番気になってた所なので今回三日という期間ですがお邪魔させて頂きました!

期間中の流れ

1日目

基礎知識の導入

DSPSSPとAd-networkにおける背景と問題設定を確認しました。どちらも広告枠とその広告を出稿する物を取り扱いする物ですが、軽く触れて置くと…

  • DSPSSP 広告主・メディア側、それぞれの利益をDSPSSPのそれぞれが最大化する

  • Ad-network
    広告主の要望を満たしつつパブリッシャーとして自らの報酬を最大化する

ざっくり言ってしまうとDSPSSPが広告主側とメディア側を分担しているのに対して、Ad-networkはどちらも兼任(Two-Sided Platform)といった感じでしょうか。自分としてはDSPから入った人間なのでAd-networkではRTBやオークションが発生しないと言うのが印象的?でした。

リクエストに対しての適した広告配信実装

とりあえず開発環境を整えると言う事でインスタンスを立てて頂く形となったのですが…
アクセスの際に安全な接続ではないと言う事でChromeの例のやつが出てそいつの突破に少々手間取りましたが ブラウザ上でthisisunsafeと打つと行けると言うなんかゼビウスみたいなコマンドで解決しました笑 (伝わる人には伝わる)

f:id:Ric418:20191224033149j:plain
A→→→→→→→→→↑↑←←↓↓↓↓↓↓↓↓↓

ともかくインスタンスを立てて頂き基本的な条件を満たす様に配信できる様にする事から始めました。 具体的には以下の様な条件を満たす様な物です。

  • 配信するキャンペーンをAndroidiOS・指定なしに分けてそれぞれ配信する
  • 広告用の端末識別子(IDFA)が得られる時のみ配信可
  • ホワイトリスト配信

これらの様な物が挙げられます。 これはリクエストから流れてくる広告枠の情報から照らし合わせて配信可能なキャンペーンをフィルタリングする様な感じでした。

多腕バンディット問題と累積報酬最大化

「クリック数最大化」を狙う方策として多腕バンディット問題を扱っていく形です。
自分は
「MLでCTR(Click Through Rate)予測!」
みたいな人間だったのでここで観測数がある程度あり早い段階での収束が見込めるのであればそれを使って制御するというのは、
「まあそれはそうか…確かにぃ!」
と言った感じで統計的手法の出しどころさんを実感した次第で御座いました。
(もちろんスタート時点ではMLの事前訓練使ってマシにするとかはあるだろうけども)

具体的な手法としては

  • Epsilon Greedy Algorithm
  • UCB1 : 信頼上限に基づく方法、配信のフィードバックを用いて次行動を決定する
  • ThompsonSampling : パラメータの事後分布に基づく方策、実運用のフィードバック遅れにもロバスト

ここで興味深かったのはUCB1は途中で収束した当たりで探索を少なくしてそれぞれのキャンペーンの実績のクリック率(CTR)をそのまま用いた方が最終累積クリック数が多いという事でした。まあこれは全てのキャンペーンのCTRが収束しているのであれば当たり前っちゃ当たり前ですが。。

f:id:Ric418:20191224191317p:plainf:id:Ric418:20191224191321p:plain
探索し続ける場合(上)と配信ラウンドの3割で探索を減らす場合(下)

割とここで統計のお話が出てくるのでその辺りがあやふやだとつまづくかも?
自分は西林さんに質問させて頂きながら理解を進めました。(実際のところThompson Samplingのところはまだ少し怪しいのでQiitaでまとめ記事書こうかなと…)

チームランチ!

西林さんのチームの方々とオフィス近くの九州料理のお店で普段の業務のお話をさせて頂きました。

  • 動画広告に対する評価を検討
  • データ分析から入ってインフラ基盤を触ってる
  • 各部署で使っているログを溜める部分の改修

などなどデータの部署と言っても分析のみならず…っていう感じでした、基盤から見ていきたい人間としては魅力的に映りましたね…

2日目

Two-sided Platformとしての配信ロジック実装

  • メディア側:利益(CPM)を最大化したい
  • 広告主側:コンバージョン数を最大化したい

これらの側面を達成するために

  • CPM最大化
    今回はclickでコストが発生するためCTR*CPCこれを最大化する物を配信
  • CVR(コンバージョンレート)の予測と最大化
    過去のクリックログを分析してコンバージョン予測、CVRの高い物を配信

これらをやっていく形になります。
ここで初めてCVRを予測するモデルを組むためにクリックログを分析するという段階になったのですが、なぜCTRの時点で出てこなかったかと言うと、

  • ClickとConversionでは運用開始からの観測数として雲泥の差がある

事前に過去のログから訓練して予測するモデルがあった方が良いと言う事だそうです。

西林さんとランチ!

西林さんのファーストキャリアやSIとして働いていた際の事、普段コードを書いている時に気をつけている事などのお話を聴きながら渋谷に最近できたビリヤニが食べられるカレーや初恋で辛めのカレーをご馳走いただきました。(割と辛いので気をつけませう)

retty.me

人事のなみさんとコーヒーブレイク

インターン中盤と言う事で人事のなみさんとインターンの所感も含めて色々なお話をさせていただき(この時gardenの特製コーラをご馳走いただきました…!)、お話を聴きたいと言う要望を聞いていただき、3日目のランチに若手のエンジニアの方のお話を聞かせて頂ける事に!

3日目

予測CVRと目標CPAでCPCを調節する

広告主・メディア側、どちらかの利益だけを最大化するわけにもいかないので

CPC = 目標CPA * 予測CVR

としてCPCを調節していきます。ここで実績CVRを用いてもいいのですが先述の様にコンバージョンは数が極端に少ないので予測CVRを用いる事になります。

日予算消化とペーシング

CPCを調整しておけば良いと言うわけでもなく、広告主の要望として

  • 日毎の予算は超過しない様に消化して欲しい
    これは配信ラウンド毎に消化予算を記録それを元に制御
  • 一日の予算消化のペーシングは理想的な形で
    これはフィードバック制御を用いて行う

と言うものがあります。この機能を実装していきました。 フィードバック制御、制御工学と言った物は他業界の物だと思っており、これまで触れた事がなかったのですがこう言う分野でも使われる事があるのか…と自分の至らなさを実感し只今絶賛勉強中で御座います…

f:id:Ric418:20191225053949p:plainf:id:Ric418:20191225053952p:plain
フィードバック制御を行わない場合(上)行う場合(下)

上図は20時前には使い切ってしまっているのに対して制御をしている物は理想的な消化ペースである事がわかるかと思います。

その他の制御対象

今回自分の進捗が少し遅れていたこともありここまではできなかったのですが、CPA(Cost Per Action)を配信しながら目標CPAから大きく乖離しない様に制御する事にも使えるそうです…

若手の方々と同期インターン生とランチ!

若手エンジニアの方々と

  • VGのエンジニアとして期待されていそうな事
  • サービスの何を意識して普段開発しているか
  • プロダクトのフェーズとエンジニアの動き方
  • "エンジニア"としての裁量はどれくらいか

などなどを同期(同年度卒)のエンジニアインターン生と一緒にランチを頂きながらお話しました! 特に、「VGのエンジニアとして期待されていそうな事」これがとても参考になりました!

最後に

最後に西林さんに情報系の学生のうちではあまり触れないが実務ではよく使う物は、結構色々あって…と言うお話を頂きつつ、なんと西林さんも著者に名を連ねるオラ本をサイン入りでプレゼント頂きました…! 勉強します…!

f:id:Ric418:20191225060727j:plain
隣でマンツーマンだったの改めてスゴい贅沢な状況だったのでは…

また自分が何かしらで少し詰まりかけるとサポートして下さったチームを始めとした社員の方々、有難う御座いました、お世話になりました!

まとめ

1番の学び

ここまで色々と書いたのですが、お気づきでしょうかML以外の技術要素が大半を占めていた事を…

今回のこのインターンは西林さんもブログ内で言及している様に

データ分析系3daysインターンシッププログラム… いわゆる「機械学習エンジニア」向けのインターン

なわけですが、

割と機械学習は大枠の一部の補助機能として動いている

みたいな印象を受けまして…
つまり、これも色んな所で言われがちな話ですが

どう言う状況だとデータ分析・MLは必要なのか

みたいな所を精査するのも分析系のエンジニアとしては大事なお仕事だなとCVRの観測数あたりの話で実感しました。

所感

ここは色々あるので箇条書きで、あくまで個人的に感じた事なのであしからず…

  • 部署・チームについて

    • データサイドとアプリケーションサイドは分業っぽい
    • とはいえデータチームの中でもインフラとか基盤側やってる方もいる
    • データもアプリケーションも議論が活発
    • アプリケーションサイドに結構ビジの問合せが多い?
  • 参加前にこんな素養があると良かった・あって良かった物(重要度順)

    • 統計・確率の基礎
    • クラスによる継承とか構造体の扱い
    • numpy・pandas・matplotlibの素養

こんな感じでしょうか、他にも思い出したら追記します。

それでは長々と失礼いたしました!またどこかで!