ID:10490さん

## 概要 インターネット広告配信システム(Zucks Ad Network)のデータ分析チーム立ちあげ要員として、以下を行なった。(公開可能な経験のみ記載) (1) データ分析基盤の構築と維持 (2) 機械学習を使った予測機能の開発 (3) 配信ロジックの改善による収益の最大化 ## データ分析基盤の構築と維持 ### 目的 日々発生する配信ログをデータウェアハウスに流しこみ、常に最新のデータを好きな形で引き出して利用可能にする事 ### 実装 **ETL** S3 -> SNS -> SQS -> EC2 (Pythonで実装したワーカープロセス) -> GCS -> BigQuery EC2インスタンスを横に並べればスケールする設計にした BigQueryのロードJobは1時間毎に叩いている、すぐに必要になるログはStream Insert **バッチ実行環境** ジョブの依存解決・並列実行制御・リトライ制御はLuigiにまかせた。 バッチ処理は全てPythonで書いていたため。 ### 結果 - S3に配置されるログをBigQueryに流しこむ仕組みを実装し運用した。 - 2017年現在で圧縮状態のサイズにして数TByte/day のログが流れている。 - 分析チームはJupyterからデータを使っている。 - クリック単価調整ロジック等、様々な処理がデータソースとして利用している。 - BIツールとしてre:dashを開放したら普及し、エンジニアに限らずBigQueryを利用するようになった。 その後インフラ担当者がチームにJoinしたため、開発は引き継いだ。 ## 機械学習を使った予測機能の開発 1例としてクリック単価調整のためのコンバージョン率予測を挙げる ### 課題 クリック単価を決定するのに広告のコンバージョン率(以降CVRと表記)が知りたいが、広告キャンペーンが始まった時点ではクリック数のサンプルが小さく統計的にはなんとも言えない。しかしなるべく早く妥当なCVRを推定したい。広告案件は予測モデル(e.g. 線形回帰)が作れるような素性データがない。 ### 実装 広告案件は短命なため、案件よりも長く生きる広告枠の情報を使った事前確率を導入した。事前分布を導入し、ベイズの定理によりクリック・コンバージョンを観測した時点の事後CVRを考える。CVR事前分布として、クラスタリングで求めたコンバージョン傾向の似た枠集合のクリック・コンバージョンを使う。 Pythonで実装 (NumPy, SciPy, Pandas) ### 結果 実績CPAが目標CPA (コンバージョンあたりの獲得コスト) に近くなり、ブレの分散も小さくなった。 ## 収益を最大化するための配信ロジック開発 ### 課題 媒体社の収益をもっとあげたい 広告リクエストがサーバーに届いた時にどの広告を配信すべきだろうか。 ### 実装 CPAの制約の元で媒体社収益を最大化する。基本的には多腕バンディットのアプローチ。活用と探索という考えを取りいれる。既存のバンディットアルゴリズムは、最良の腕が決まるとそれを選択し続ける動作となるため、活用についてはそのまま使わない。 探索についてはeCPM (収益性の指標) の信頼上界を求め、枠に流れる広告同士でこれを比較し、上位となる見込の無い広告は探索配信を止める。アドサーバーはScala、バッチ処理はPythonで実装。 ### 結果 ランダム化比較試験を用いて、広告枠をコントロール群とトリートメント群に分けて検証。 広告枠毎の収益が高くなった事を確認。 ## その他 - 中途採用 (求人メディア出稿記事の作成・面接) - 新卒採用 (面接) - チームメンバーのプロジェクト支援 ## 講演資料 スマートフォン向けインターネット広告配信システムの配信最適化(2017) https://speakerdeck.com/hagino3000/sumatohuonxiang-keintanetutoguang-gao-pei-xin-sisutemufalsepei-xin-zui-shi-hua オンライン広告における不正クリック検出手法と歴史(2016) https://speakerdeck.com/hagino3000/onrainguang-gao-niokerubu-zheng-kuritukujian-chu-shou-fa-toli-shi アドネットワークのデータ解析チームを支える技術 (2015) https://www.slideshare.net/hagino_3000/ss-53786917 ## Publication [アドネットワークにおける広告配信計画の最適化 人工知能学会誌 : journal of the Japanese Society for Artificial Intelligence 32(4), 487-493, 2017-07](http://id.nii.ac.jp/1004/00008732/)

## 概要 スマートフォンアプリのサーバーサイド、運用業務の自動化を担当 チームはプロデューサー + iOSエンジニア + 自分 ## サーバーサイド インフラはAWS、サーバーサイドはPerl, Dancerを使って実装。既存のコードベースを流用した。 バッチ処理はPython。 iOSのPush通知サービスで自分達の使い方にfitする物がなかったので通知サービスを独自開発した。 通知の到達速度が粗利に直結するサービスだったので重宝した。 https://github.com/voyagegroup/apns-proxy-server https://github.com/voyagegroup/apns-proxy-client-py 小さめのライブラリも公開した https://github.com/voyagegroup/WebService-PeX-GiftOndemand ## 運用業務自動化 Windowsマシンの画面操作のオートメーション化。 GUIの操作が必要となる業務を自動化するため 1. キュー(SQS)をポーリングしてタスクを取得 2. GUIアプリの起動 3. 画面の状態やボタンの場所を画像認識で判断、Win32APIを叩いてマウス操作+キーボード操作を行なう を行なうPythonのプログラムを実装し、サーバー1台とクライアント4台のマシンで稼動。 プロデューサーをルーチンワークから開放した。

## 概要 チャットアプリ事業部の立ちあげに参加し、スマートフォンアプリの開発とエンジニア採用、業務委託先の選定を行なった。 チームはプロデューサー + iOSエンジニア + 自分の3人構成で自分がサーバーサイドを担当した。 ## スマートフォンアプリのサーバーサイド インフラはAWS。クライアントにJSONを返すのとAppleのPush通知APIを叩くのが役割。アプリケーションサーバーはPython, Django, djago-rest-frameworkを使って実装した。iOSエンジニアとのやりとりのためにAPI仕様書を作成。 開発リソースの不足を補うために、途中からPython + Djangoが得意な会社と共同での開発体制とした。 リリース後に専属エンジニアの採用が成功したので、自分はプロジェクトを抜けた。

## 概要 HTML5によるスマートフォンアプリ開発の実験プロジェクト。 リアルタイムに絵を描きながら1対1のやりとりのできるスマートフォンアプリの開発をした。 開発メンバーは4人。自分はフロント(HTML5)とNode.jsのサーバー(WebSocket通信)を担当した。 ## フロント Sencha Touch + Apache Cordovaによるハイブリッドアプリとした。Single Page WebApp。お絵描きのUIはCanvasを使用、サーバーとの接続はWebSocket。 ## サーバーサイド お絵かきセッションはアプリケーションサーバーとは別にNode.jsサーバーで管理、WebSocket接続を維持してリアルタイムに相手の画面に反映するようにした。 コネクション接続しっぱなしのアプリケーションの運用は初めてだったので、サーバーの再起動がユーザーに与える影響が大きくなってしまう等苦労した。iOSアプリはネイティブ(Objective-C)で作る方がよっぽど楽だという教訓を得た。 ## 発表資料 https://www.slideshare.net/hagino_3000/ioswebviewapp