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

Copyright © LIMIA, Inc. All Rights Reserved.
エンジニア以外の方が自らSQL
を使ってセグメント分析を行うカ
ルチャーをどのように作っていっ
たか
July Tech Festa2019発表資料

View Slide

● グリーグループのリミア株式会社で、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

View Slide

グリーグループ公式部活動とし
て技術書典部を立ち上げ、合同
誌を作って頒布しました。
次の合同誌を制作着手してお
り、技術書典8にもサークル参加
予定です。
企業部活動として技術書典7にサークル参加
3

View Slide

オフィスが新宿に移
転しました。最大190
名収容可能な勉強会
スペースがあります。
社内外の勉強会を開
催できたらと思ってい
ます。
松屋自販機もありま
す！
最高すぎる勉強会スペースと松屋自販機
4

View Slide

「エンジニア以外の方が自らSQLを使ってセグメント分析を行うカルチャーをどのように
作っていったか」について、次の構成で説明します。
• 従来の分析
• 新しい分析
• 普及活動
• 事例1: プッシュ通知改善
• 事例2: 編成改善
アジェンダ
5

View Slide

従来の分析方式

View Slide

LIMIAとは?
7
● メディアサービス
● Android, iOS, Web
● 記事一覧を表示し、タップすると
記事詳細を閲覧できる。
● 記事一覧はパーソナライズ。
● 記事詳細読了後に関連記事を出
している。
● Fuel PHP/EC2, go/ECS
● 分析基盤はBigQuery

View Slide

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

View Slide

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

View Slide

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

View Slide

新しい分析方式

View Slide

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

View Slide

● 当時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), '-', '')

View Slide

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

View Slide

● 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

View Slide

● Webは従来方式。各メディアでGASでGA
APIを叩いてSpreadSheetに出力。
● iOS/AndroidはBigQueryにあるデータを
統括部門が全メディアの集計を行い、
SpreadSheetに出力。それを各メディア側
で参照。
→ これにより、横比較が可能となった。
KPIシートの流れ
16

View Slide

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

View Slide

普及活動

View Slide

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

View Slide

様々な要望があったため、
re:dashを導入した。
BigQuery Consoleで実
装し、ここに貼り付けてレ
ビューします。
環境整備(redash)
20

View Slide

re:dashからquery結果をcsvで取得
できる。queryを定期実行させ、その
結果を参照することで、自動更新する
KPIシートを作成することができる。
KPIシート作成支援
21

View Slide

傾向を把握するため、協力して
Data Studioで主要KPIのダッ
シュボードを作成した。
メディアの横比較は、このグラフ
を見ていた。
ダッシュボード提供
22

View Slide

事例1: プッシュ通知改善

View Slide

● 起動経路で最も多かったのは、プッシュ通知からの
起動。
● 以前は人手で良さそうな記事を送信していた。
● 分析して特徴を見つけ、自動で最適な記事を送信
する。
● 2018年に行なった施策事例のため、現時点では仕
様が異なる可能性があります。
背景と目的
24

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

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

View Slide

条件を満たした記事をBigQueryで集計。バッチで結果を読
んで、MySQLに書き込む。当時の基準は、以下のもの。
● CTRが高い
● 読了率が高い
● 記事の長さが一定以上
システム構成(自動入稿)
30

View Slide

バッチが毎分起動して、送信時刻になると原
稿と対象ユーザをSQSに送る。送信バッチ
はSQSにqueueがあると、それをFCMに対
して送信する。
システム構成(配信)
31

View Slide

管理ツールでは、次の4つの画面を
作った。
● 通知: 配信時刻
● 条件: どの原稿を誰に送るか
● 原稿: 通知送信内容
● コンテンツ: 遷移先コンテンツ
条件を設定すれば、ABテストや特定
のユーザへの配信が可能。原稿を工
夫することで複雑な通知を送信可能。
管理ツール
32

View Slide

● 既存ユーザが多いため、起動率は低下傾向。
● しかし、施策稼働中は起動率をほぼ横ばいにすることができた。
● 入稿作業の属人性排除と工数削減ができた
改善結果
33

View Slide

事例2: 一覧表示改善

View Slide

● アプリを起動すると、記事一覧が表示される。
● 記事への導線として、一番大きい。
● ここを改善することで、記事閲覧数を増加を目指
す。
背景と目的
35

View Slide

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

View Slide

記事とUserの距離を計算し、近い物を出す。た
だし、全記事との距離をリアルタイムに計算す
ると遅いので、分類して中心点との距離を計算
することにした。クラスタ内での順位はCTRを
使った。
次に記事とユーザをベクトル化する仕組みを説
明します。
記事の推薦の仕組み
37

View Slide

記事が更新されると、
SQSに通知されます。そ
れをLambdaで読み込ん
で、単語に分割し、単語を
vectorにします。記事に
含まれる単語の平均を記
事のvectorとします。ただ
し頻出単語の影響緩和の
ため、IDFで補正します。
記事ベクトル作成
38

View Slide

ユーザが記事を閲覧すると、その情報がKinesisに流れます。
Lambdaで受け取り、直近30件の閲覧履歴をDynamoDBに保存
します。その変更をDynamoDB Streamに流し、Lambdaで受け
取って記事のベクトルの平均をユーザベクトルとしてDynamoDBに
書き込みます。
ユーザベクトル作成
39

View Slide

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

View Slide

青が高CTR、赤がパーソナライズ。やや負けて
いる。
単純にCTRが高い順に出すより、CTR上位200
件をシャッフルして出した方が結果が良かった。
バグってシャッフルされたことにより発覚。
オンライン検証
41

View Slide

以前行なっていた手動編成に比べると、CTRが20%向上した。
2019年11月28日現在、高CTRとパーソナライズが同じぐらい。
パーソナライズの方がポテンシャルが高いため、引き続き改善を続けている。
注意: ユーザとコンテンツが異なると、結果も異なる。
参考にするなら、施策でなく進め方！
改善結果
42

View Slide

終わりに

View Slide

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

View Slide

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

View Slide

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

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

mahiguch

More Decks by mahiguch

Other Decks in Technology

Featured

Transcript