エンジニア以外の方が自らSQLを使ってセグメント分析を行うカルチャーをどのように作っていったか

Slide 1

Slide 1 text

Slide 2

Slide 2 text

Copyright © LIMIA, Inc. All Rights Reserved. ● グリーグループのリミア株式会社で、LIMIA という住まい領域のメディアを作っています。ゲーム会社ですが、最近はメディアに力を入れています。 ● 機械学習(RecSys)のエンジニアですが、iOS, Android,JSなどもやっている何でも屋です。5歳の娘のパパ。twitter: @mahiguch1 ● PHP Conferenceでgoの話をしたら、社内Slackがざわざわしました。w ● https://limia.jp/ ● https://arine.jp/ ● https://aumo.jp/ ● https://www.mine-3m.com/mine/ Masahiro Higuchi/樋口雅拓 2

Slide 3

Slide 3 text

Slide 4

Slide 4 text

Slide 5

Slide 5 text

Slide 6

Slide 6 text

Slide 7

Slide 7 text

Slide 8

Slide 8 text

Copyright © LIMIA, Inc. All Rights Reserved. 画面遷移でGoogleAnalytics(GA)イベントを飛ばし、PageView(PV)を計測していた。広告はAdNetの管理画面の数字を SpreadSheetにコピペして管理。 Adjust/Kintoneなどのサービスも同様にSpreadSheet管理。従来方式の計測手法 2017年12月時点の状況 8

Slide 9

Slide 9 text

Copyright © LIMIA, Inc. All Rights Reserved. • GA画面でPVボリュームを見て、施策の優先順位を提案。 • 施策の結果は一度確認するだけ。確認しないことも多かった。 • グループ内のメディアで、指標(PV)の基準が違い、横比較できない。 • SpreadSheetは非常に精巧に作られていた。神Excel状態。外部参照やGASでコピーを繰り返しており、中間ファイルを不用意に変更すると大騒ぎに。従来方式の分析手法 2017年12月時点の状況 9

Slide 10

Slide 10 text

Copyright © LIMIA, Inc. All Rights Reserved. ● 全ユーザに効果がありそうな施策は出尽くし感があり、効果が薄くなっていた。 ● ユーザをセグメントに分けて分析し、それぞれに合わせた施策が必要。 ● 分析軸となるCustom Dimentionは上限の20個に達していた。 → 誰でも自由にセグメント分析できるようにしたい。 → FirebaseAnalyticsで計測して、BigQueryにログを落としたい! 従来方式の問題点 2017年12月時点の状況 10

Slide 11

Slide 11 text

Slide 12

Slide 12 text

Copyright © LIMIA, Inc. All Rights Reserved. 同時期に別の課題が発生。 ● グリーグループのメディア(LIMIA/arine/aumo/mine)は、それぞれで数値管理を行っており、集計定義が異なった。 ● 統一定義を作り、FirebaseAnalyticsで計測しようとした。 ● これにより、計測、集計、レポートをグループ内のメディアで統一的に行う事ができる。 → セグメント分析のためFAを導入しようとしていたので、他メディア等と協力して対応を行いました。背景と目的 2017年12月開始の施策 12

Slide 13

Slide 13 text

Copyright © LIMIA, Inc. All Rights Reserved. ● 当時Web向けFirebaseAnalyticsはなかったので、Webは GoogleAnalyticsを引き続き利用することに。定義に差がなかったため。 ● iOS/AndroidはGoogleAnalyticsに飛ばしていたイベントを FirebaseAnalyticsにも飛ばすようにした。 ● GoogleAnalyticsのEventは、パラメータにactionとlabelという物を付けていた。それをそのままFirebaseAnalyticsにも飛ばした。イベントログ 2017年12月開始の施策 13 select event_name, (select value.string_value FROM UNNEST(event_params) WHERE key = 'action') as action, (select value.string_value FROM UNNEST(event_params) WHERE key = 'label') as label, from `analytics_1234.events_*` where _TABLE_SUFFIX = REPLACE(CAST(DATE_SUB(CURRENT_DATE, INTERVAL 1 day) AS string), '-', '')

Slide 14

Slide 14 text

Copyright © LIMIA, Inc. All Rights Reserved. Embulkを使ってBigQueryへ転送している。Embulkコンテナを作り、ECS Fargateで回している。以下に要点だけ示す。 ● RDS: 負荷を考慮して1テーブルずつ転送。daily tableを切らずに上書きしていく。履歴は残らないが、MySQLと同じqueryが使える。 ● Dynamo: 構造化データはjson文字列として格納。 GCP service accountは、KMSで暗号化したファイルをcontainerに含めている。embulkはfargateのExecRoleを見てくれないので、AWS IAM user を環境変数で渡している。マスターデータ RDSとDynamoのデータをBigQueryへ 14

Slide 15

Slide 15 text

Copyright © LIMIA, Inc. All Rights Reserved. ● Search Console: golangバッチでAPIから取得し、BigQueryへ転送。 ECS fargate taskで毎晩実行。 ● Google Analytics: 集計パターンをいくつか作り、それぞれをBigQuery の対象テーブルへ転送。実行環境はSCと同じ。 ● Kintone: 一部業務の管理ツールとしてKintoneが使われていたため、 Kintone APIをGASで叩いてBigQueryへ。 ● Adjust: Cloud FunctionsにEndpointを作り、来たデータを全て BigQueryに格納。AdjustのGlobal Callbackに設定。 → 全てのデータをBigQueryに転送して分析可能に周辺システムログ SearchConsole/GoogleAnalytics/Adjust 15

Slide 16

Slide 16 text

Slide 17

Slide 17 text

Copyright © LIMIA, Inc. All Rights Reserved. ● 協力して全メディアの基本指標のSpreadSheetを作った。 ● 神Excel達のデータソースをこのシートに切り替えてもらった。 ● 基本指標のSQLを共有し、知識と経験があれば、それをベースにセグメント分析可能な状況を作った。 → しかし、この時点ではSpreadSheetのみを使った分析が中心。ここからセグメント分析の普及活動を開始した。この時点での分析の進め方 17

Slide 18

Slide 18 text

Slide 19

Slide 19 text

Copyright © LIMIA, Inc. All Rights Reserved. ● 書籍「10年戦えるデータ分析入門」を読んでもらった。 ● 初回演習ではSQLへの抵抗を減らすため、サンプルのSQLをベースに実行してもらった。 ● 隔週で5回程度演習を行い、相談用Slack Channelを作った。 → このときの勉強会参加は約10名。そのうち半数がSQLでセグメント分析可能に！　その後は教え合って、できる人が増えていった。勉強会開催 2018年前半に実施 19

Slide 20

Slide 20 text

Slide 21

Slide 21 text

Slide 22

Slide 22 text

Slide 23

Slide 23 text

Slide 24

Slide 24 text

Slide 25

Slide 25 text

Copyright © LIMIA, Inc. All Rights Reserved. 目標はLTV - CPI > 0の状態を保つこと。ブレストを行い、LTVに繋がりそうな仮説を立てた。 ● ユーザの興味に合わせた記事を配信すると起動率が上がる ● 読了率が高い記事を配信すると起動率が上がる ● ユーザが普段使っている時刻に配信すると起動率が上がる ● 配信回数を減らすとアンインストールが減る ● 配信回数を増やすと起動数が増える過去ログを使って想定効果を検証した。仮説立案 25

Slide 26

Slide 26 text

Copyright © LIMIA, Inc. All Rights Reserved. ● ユーザが直近見た30記事のカテゴリを調べ、最も多かったものをユーザの興味セグメントとした。 ● 興味セグメント毎に起動率(=起動数/ユーザ数) を集計。 ● 配信した記事のカテゴリと興味関心が一致/不一致で起動率を比較 ● 一致していたケースでは不一致に比べて、20% 起動率が高かった。採択。オフライン検証(採択事例) ユーザの興味に合わせた記事を配信すると起動率が上がる 26

Slide 27

Slide 27 text

Copyright © LIMIA, Inc. All Rights Reserved. ● 15日前から2日前のログからアプリ起動時刻を調べ、時刻毎のユーザセグメントを作成。 ● 1日前のログから「その時刻のみに送信」と「全時刻に送信」を比較。 ● 対象時刻のみだと、起動数が40%減少。アンインストールが減ってもカバーしきれない減少幅だったため、棄却。今考えると、訓練/テストはユーザを80/20に分けて検証した方が良かった。結果は変わりそうもないが。オフライン検証(棄却事例) ユーザが普段使っている時刻に配信すると起動率が上がりアンインストール減少 27

Slide 28

Slide 28 text

Copyright © LIMIA, Inc. All Rights Reserved. オフライン検証で効果が見込めるものをABテストした。 2週間を1ラウンドとし、ラウンド毎に異なる仮説を検証した。 30ラウンドあたりで収束したので、検証を終了した。その結果、以下のパターンが最もLTVが高かった。 ● 一斉送信は1日5回 ● そのうち4回は興味関心と一致した記事 ● 記事は直近2週間の読了率が高かったものこの結果は当時のLIMIAユーザに対する最適値なので注意！そのまま使っても上手くいかない可能性が高い。参考にするなら結果ではなくプロセスを。オンライン検証 ABテスト 28

Slide 29

Slide 29 text

Copyright © LIMIA, Inc. All Rights Reserved. 興味関心に合わせた記事を配信しようとすると、興味セグメント毎に配信記事を選ぶ必要がある。興味セグメントを10個にした場合、10倍の記事を選ばなければならない。人手では10倍のコストがかかってしまうため、抽出作業を自動化した。 ● 配信枠に自動で3件づつ入稿 ● それを人が確認し、最適なものを選ぶ。完全自動化すると、季節外れの記事(イベント終了後にイベント記事など)を送ってしまう可能性があるため、人手でのチェックを残した。運用改善: 配信記事抽出自動化ここからは少しシステムの話です 29

Slide 30

Slide 30 text

Slide 31

Slide 31 text

Slide 32

Slide 32 text

Slide 33

Slide 33 text

Slide 34

Slide 34 text

Slide 35

Slide 35 text

Slide 36

Slide 36 text

Copyright © LIMIA, Inc. All Rights Reserved. 目標はユーザにより多くの記事を閲覧してもらうこと。それに繋がりそうな、以下の仮説を立てた。 ● CTRが高い記事を掲載する ● ユーザの興味関心に合った記事を掲載する(パーソナライズ) パーソナライズの方がポテンシャルは高そうだが難しい。そこで、高CTRをベースラインとして、これを超えるようなパーソナライズモデルを開発する。仮説立案 36

Slide 37

Slide 37 text

Slide 38

Slide 38 text

Slide 39

Slide 39 text

Slide 40

Slide 40 text

Copyright © LIMIA, Inc. All Rights Reserved. 過去2週間のクリックログを使い、80%のユーザ情報で訓練させ、残り20%のユーザへの推薦を行い評価しました。まずは形態素解析に使った辞書を検証します。評価はnDCGを使って行いました。 ● ベースライン(高CTR): 0.100 ● パーソナライズ(ipadic): 0.0846 ● パーソナライズ(neologdを追加): 0.0866 ● パーソナライズ(さらにユーザ辞書にLIMIAキーワードを追加): 0.100 結果が良かったLIMIA辞書付きの辞書を採択しました。オフライン検証どの辞書が最適か 40

Slide 41

Slide 41 text

Slide 42

Slide 42 text

Slide 43

Slide 43 text

Slide 44

Slide 44 text

Copyright © LIMIA, Inc. All Rights Reserved. ● エンジニア以外の方は最初SQLに抵抗がある。 ● 覚えてしまえば、エンジニアより良い分析を行なってくれる。 ● 現在は機械学習プロジェクトの分析や企画立案まで行なってくれるている。 → SQLを使った複雑な分析はエンジニアしかできないというのは、単なる思い込み。運営側はエンジニアより分析が上手い！みんなを巻き込むことで、より良いサービスを作っています。まとめ 44

Slide 45

Slide 45 text

Copyright © LIMIA, Inc. All Rights Reserved. グリーグループ及びリミアでは、一緒にメディアを作っていく仲間を募集中です。興味のある方は、以下のサイトをご覧ください。 http://corp.gree.net/jp/ja/recruit/ https://www.wantedly.com/companies/limia ご静聴、ありがとうございました。 We are hiring! 45