###### tags: `linedevday` `memo`
###### 2019-11-20
# 常に進化を続けるLINEの運用型広告プラットフォーム「LINE Ads Platform」

[資料はコレ](https://speakerdeck.com/line_devday2019/how-line-ads-platform-is-constantly-evolving)

2年前: 速度やレイテンシ問題を抱えた

### 課題
- 広告主にフレンドリーになりたい
- システムのアーキテクチャ

### using MLという方向性
広告主に対してフレンドリーとは？ = 人を理解することが重要
LAPシステム構築の時点で広告業界のプロを集めてはじめた
LAPの考え方を業界標準にしたい
プラットフォーマーとしてロジックの美しさは重要視しなかった
数字を確認したり and splacementの2点
3ヶ月で開発し、初めはタイでopenした(日本は遅れた
online accoutの登場で個人がLAPにアクセスできるようになった
CTR予測手法(実装)は既出だが、conversion bidding も予測しようとした話
(そもそもCVRとはの用語説明)
ex.)
app install ごとに入札500円にできれば入札金額が20回の app install が買える(イベントを増やす
- coversion auto bidding
- conversion events added
進化を遂げた話
- system architecture
業界基準に準拠すべき->プロトコル、スケーラビリティ
- recruting
専門家を集めよ

SSP,DSP + DMP, Pipline(ログの格納 支払状況など)

- **プロトコル**
openRTB DSPとしてサポートしている
拡張の観点から説明
FIVE(LINEが買収した) SSP

- **ロジック**
なぜロジックがかかせないか？
広告主はお金を支払い多くの収益を獲得しようとする
マーケのゴールに対して戦略で様々なフィーチャーを用意

- **marketing funnel**
フィーチャーを組み合わせて各ファネルを達成しようとする
ここで必要なものがRTB,CVR,BA
MLerが注意を払っていないと考えるポイント

- real time monitoring
バグの発見が損失に直結する
prometheusとgrafanaを使っている
Druid/Imprid

- 実験的環境
開発研究側へのルールを用意した-> offlineテストの合格
date pipline を作る
multi ABtest をする
たくさんの環境を同時に作った

- real time serving
バッヂではなくリアルタイムにサーブする(view, clickなど
レーテンシを抑えることが重要

### R&Dしたロジックの紹介
いくつかpaper出したぞ([これとか](http://wnzhang.net/share/rtb-papers/budget-smooth.pdf))
６つのロジックを紹介
- CTR predicton
realtime, latency, model performance
logistic回帰, FTR(google使ってる), GBT, clusteringなどから実験して選んだ

- CV predicton
clickのイベントより、CVイベントは長期間のため難しい
データなしで予測しなけれな行けなくなる
CV dataはdirtyでクレンジングが大変
data clearing, rerity, delay, multi-label
このような観点から実験
L-BFGS, 分散があるためpoissonなど

- auto bidding

- look-Alike
だれか、なにかが他のものに似ているはずなのでその仮定のもとユーザ選択
-> メインカスタマーに入れて、ユーザを探す
embedding, speed, monitoring

- simulator
トレースしたい数字,CV予測
Reach&Frequency simulatorを採用

- optimazation status
モデルが安定するまでどれくらい時間がかかるのか、などを広告主が理解しなくてはいけない
待つ時間は赤いエリア(グラフ参照)

- Auto Series
自動化シリーズ
auto delivery とは
正しいユーザを見つける(ターゲティングに近い)
onlineで実験も自動でたくさん実施している