コミュニケーションアプリ「LINE」の機能改善を支えるデータサイエンス
2019/11/20 15:14
LINEのデータサイエンティストがどう貢献しているのかのプロジェクトの実例
LINEアプリ本体のデータを使った改善プロセスの実例kadoyau.icon
Agend
Data Science Teamとは？
LINEアプリのチャレンジ
Create Group機能のimprovemnent
LINE App改善プロジェクト
Users First
Data Driven
Diverse Team
Inhouse development
Data Science Teamとは？
組織図
内部的に4つのチームに分かれている
話者はLINE/Stamp事業のTeam 2所属
一緒に仕事をするグループ
Data ScienceのプロジェクトはData Scientistだけがやるものではなく、様々なプロフェッショナルと一緒にやる
プロジェクトの流れ
起点がUser Research
対面インタビュー
オンラインインタビュー
Data Scientistも関わることがある
ここを知っているかどうかで分析のアウトプットが変わる
気になった数値は毎回共有している
このように定量・定性の両方を見るのがポイント
Test: A/Bテストみたいなやつ
Plan& Development
development
企画・開発者と一緒にやるのが非常に休養
Test & Feedback
一番専門性が求められる
LINEでテストというと、オンラインのA/Bテスト
行動変化を統計分析する
2018〜 20+のテスト
典型的な規模感はグローバルで1000万人
単一指標ではなく100+の指標を網羅的に見る
ユーザの求めているものを分析を通じて理解するための機会
「ここまでの流れはWeb系の企業ならどこでもやってると思う」
LINEならではのチャレンジ
グローバル展開なのでユーザが多い
164M MAU
MAU 82M (in JP)
20+ message types
stickerとか
No Single KPI
LINEは無料アプリ。アプリ自体にそれだけで経済価値はない
主要な国だとユーザは結構とってるから2倍とかになることはないのでユーザ数の伸びとか見てもしょうがない
根源的な価値は何かに立ち戻って考える
LINEのミッションは"Closing the Distance"
メッセンジャー機能でいうと
「身近な友達とかんたんに楽しくコミュニケーションができること」
これが追求するべき価値
実現されたとき、機能はなにかを考える前に、友達ネットワークを考えてみたい
7人の友だちとつながる自分の頭
このユーザネットワークは社会的関係性を表しているはず
これがclosing the distanceがLINE appで実現されている状態
これを機能に落とすと Group Feature
グループ機能の改善に着手
ユーザリサーチから得られた仮設
LINEアプリのグループ作成の手順がわかりにくいのではないか？
従来の手法
まずグループ名を決めてから所属ユーザを選択させていた
グループを作ることを考えたときに、まずグループの人を思い浮かべると想定して、手順の順番を入れ替えた
まずユーザを選択させてから、グループを作成
意外なことに、グループ作成には変化が出なかった
なぜ変化が見られなかったのか？
分析の切り口を予め設定
作成したユーザ、しなかったユーザは？
地域の影響は？
字間的な影響は？（テストの初期と後期では？）
など
これにもとづいて分析
網羅的に分析したのでわかってきたこと
失敗したユーザはアイコンとグループ名のページまで進んでいなかった
→つまり、スムースに人を選べなかった
テストの失敗は、どれだけのユーザが対象になるのかを知ることができる
最終日にグループ作成に成功しなかった人の図
テスト期間中にグループ作成できたのが7%
複数回完了できなかった人28%。これがターゲットユーザ
Recentの友達を上位に表示してみた
LINEの友達に情報共有するときにはもうこの画面はあった
ここは開発者と会話することで工数削減につながった
Plan B（1画面にグループ作成と所属ユーザをまとめる）も提案した。
4パターンでテストをすればいいが
デメリットも有る
1つのテストで6つの比較。多重比較になる。false positiveが増える
優位性の水準を厳しくするとサンプルサイズが大きくなる。ネガティブだったらユーザにインパクトが有る
統計分析によって、3通りに絞り、2つだけにした
ナイーブでないテスト設計
統計の専門知識とアプリの知識の両方を持ったデータサイエンティストが必要
結局違いがなかった
完了にかかる字間が短くなっていたら、利用率が同じでも改善なのではないか？
JP/TW/THで短縮されていた
一つのスクリーンの場合
ネガティブ
1人グループが増加
誤ったと推測
2人以上のグループは作成成功率が下がった
「グループ作成に行ったあと、トーク作成」が増えた
ユーザが諦めた
作成完了ボタンが2回押されるのが増えた
必要な事項が入力できてなくてやり直した
以上から、2 stepでrecentを表示するようになっている
上を通じて、そもそもグループ作成ボタンを知らないユーザがいるのでは？と仮設を得た
アプリを開かずに考えてもらいたい
A/B/Cのどこにもある
直感的に選ばれるところに置く
トーク作成の画面におかれたのはA/Bテストの結果に基づく
トーク作成でグループ作成もつくる選択肢をつくった
JP/IDで大きく作成率が上昇した
100%リリースするか？No!
なにかの指標が大きく上昇したら何かが下がっているはず
トークを作成するユーザが減っていたら、食い合っているだけ
トークルームを作る/グループまたはトークルームを作るユーザを調べた
トークはやはり減ったが、どちらかでもさくせししたユーザは少し増えていた
じゃあ安心してリリース…できない
動線を追加したので、友だち追加とかが減少してるかもしれない（なぜ？）
分析した：分析した特にネガティブな降下はなかった
ここでやっとリリース
内製ツールの紹介
データサイエンティストが企画開発に提供するもの
サンプルサイズ
ダッシュボード
tagret user slot
OASIS
Presto SparkSQL SparkR PySpark Markdownでノートがかける
全車アクセスができるのでこのノートブック一つ作ればいい
夕方に発表あり
LIBRA
どのユーザをテスト対象にするのかのツール
A/Bテストのユーザ振り分け
ランダムに振り分けた1024 slotsを保持している
テスト反映サーバに配信される
分析のために逐次テーブルをひかなくてもいいようになっている
どうなってるんだ…kadoyau.icon
モニタリングツール
LIBRA REPORT
クエリをGHEを通じてApache Airflowの実行ワークフローを自動作成して分析基盤に保存される
データサイエンティストが事後分析をしようと思ったときには、処理済のデータが集計されている状態になる
R Shiny
LABRA REPORよりflexibleなダッシュボード
ポスターセッション motoyuki oki
Conflr
R markdownをAtlassion Confluence Wikiに共有できる
line/conflr