LIMIAでのBigQuery活用事例

Copyright © LIMIA, Inc. All Rights Reserved.
LIMIAでの
BigQuery活用事例

● グリーグループのリミア株式会社で、LIMIA という住まい領域のメディア
を作っています。ゲーム会社ですが、最近はメディアに力を入れていま
す。
● 機械学習のエンジニアですが、iOS, Android,JSなどもやっている何でも
屋です。5歳の娘のパパ。twitter: @mahiguch1
● 部活動でグリー技術書典部というのを立ち上げました。
● https://limia.jp/
● https://arine.jp/
● https://aumo.jp/
● https://www.mine-3m.com/mine/
Masahiro Higuchi/樋口雅拓技術書典7@い05C
2

LIMIAとは?
3
● メディアサービス
● Android, iOS, Web
● 記事一覧を表示し、タップすると
記事詳細を閲覧できる。
● 記事一覧はパーソナライズ。
● 記事詳細読了後に関連記事を出
している。
● AWS:90%、GCP:10%。
● PHP/EC2 → Go/ECS移行中
● コンテナ間はgRPC+NLB
● 偏りが激しいのでEnvoy使いたい

LIMIAでは、分析や集計のためにBigQueryを多用しています。利用方法は、
次のような形です。
1. 全てのデータをBigQueryに流す
2. 特徴を分析して運営で最適化
3. 機械に置き換えて最適化を加速
本当は(3)に注力したいが、(1)(2)に工数を取られてしまう。良さげな方法が
あれば指摘していただき、加速させたい！
ぶっちゃけ、ログ周りは面倒なので、知識を共有して機能開発に集中したいっ
す。o(> <)o
背景と目的
4

1. 全てのデータをBigQueryに流す

Firebase管理画面でボタンを押すだけでBigQueryにデータが連携される。
連携されるデータは、次のもの。
● Analytics: 送信した全てのイベント
● Crashlytics: 発生した例外の情報
● Predictions: 予測結果
● FCM: プッシュ通知送受信ログ
● Performance: 送信したトレース情報
Analytics以外のBigQueryデータは使いこなせていない。良い使い道があれ
ば教えて欲しい。
イベントログ
Firebase
6

Embulkを使ってBigQueryへ転送している。Embulkコンテナを作り、ECS
Fargateで回している。以下に要点だけ示す。
● ALB: daily table(xxlog_20190828)に前日分を転送
● CloudFront: ファイル名で前日分を特定できないので、手元に最終更新
日時指定でs3 syncしてから転送。
● RDS: 負荷を考慮して1テーブルずつ転送。daily tableを切らずに上書
きしていく。履歴は残らないが、MySQLと同じqueryが使える。
● Dynamo: 構造化データはjson文字列として格納。
GCP service accountは、EKSで暗号化したファイルをcontainerに含めて
いる。embulkはfargateのExecRoleを見てくれないので、AWS IAM user
を環境変数で渡している。
アクセスログ
ALBとCloudFrontのアクセスログ/RDSとDynamoのデータ
7

● Search Console: golangバッチでAPIから取得し、BigQueryへ転送。
ECS fargate taskで毎晩実行。
● Google Analytics: 集計パターンをいくつか作り、それぞれをBigQuery
の対象テーブルへ転送。実行環境はSCと同じ。
● Adjust: Cloud FunctionsにEndpointを作り、来たデータを全て
BigQueryに格納。AdjustのGlobal Callbackに設定。
● Kintone: 一部業務の管理ツールとしてKintoneが使われていたため、
Kintone APIをGASで叩いてBigQueryへ。
その他
SearchConsole/GoogleAnalytics/Adjust
8

2. 特徴を分析して運営で最適化

● エンジニア: エラーログ、動作速度、機能の利用状況などでシステムの健
全性を分析。パーソナライズを行うため、ユーザやアイテムの特徴を分析。
● ビジネス職: 施策立案のための状況把握。施策の想定効果見積もりと効
果測定。KPI変化の要因分析。
● 分析部隊: 基本は依頼を受けて。気づきがあれば、それとなく教えてくれ
る。
誰が何を分析しているのか
仮説を立てて定量的に検証する
10

● エンジニア: 原則データの確認はRDS/Dynamo等は使わず、
BigQueryにある早朝に取ったスナップショットに対して行う。BigQuery
画面からが多く、MLの人はJupiter+pandasから。
● ビジネス職: SQLが書ける人は、BigQuery画面を使う。そうでない人は、
分析部隊に依頼する。
● 分析部隊: データサイエンティストを中心にインターン数名。BigQuery画
面でSQL実装し、re:dashに貼り付ける。それをSpreadSheetにimport
している。
Google AnalyticsのWeb+Appの分析機能を使えば、SQLを書けない人で
も自分で必要な分析を行えるような気がしている。
どうやって分析しているのか
分析体制と分析手法
11

分析結果が明らかなら良いが、大抵はやってみないと分からない。そこで、管
理ツールを作り、人手でパターンを作ってオンライン検証(A/Bテスト)を行う。
例えば、分析結果から導いた次のような仮説を検証する。
● 仮説: タイトルを20文字にするとCTRが高い —> 15, 20, 25文字で
A/Bテスト。
● 仮説: ユーザの興味に近い記事をプッシュ通知で送信すると開封率が高く
なる —> 特徴的なユーザリストと記事を手動で作り、既存手法とA/Bテス
ト。
分析結果をどう使うか
運営による改善手法
12

3. 機械に置き換えて最適化を加速

オフライン検証のベースラインとして、人気のあるコンテンツを全員に配信した
ときを想定する。
Cell/Itemを表示したらAnalyticsにimpression eventを送信し、Clickした
らclick eventを送信してBigQueryに格納する。イベント数で割り算したCTR
を人気記事の定義とした。
例えば2日前のCTRが高いものを掲載したと仮定して、1日前にクリックされた
かを確認する。これをBigQueryのqueryとして実装する。
Popular Model
オフライン検証のベースライン
14

類似ユーザに人気の記事を配信することで、CTRが上がるという仮説を検証し
た。
ユーザをいくつかのクラスタに分類する。
分類結果をBigQueryに送信し、クラスタ毎のCTRを集計する。
定期的に集計してストレージに格納しておき、ユーザは所属するクラスタ内で
CTRが高い記事を一覧表示する。
これをPopular Modelとオフラインで比較して、既存手法とオンラインで比較し
た。
Segmentation Popular Model
素朴な機械化　
15

LIMIAにはtwitterのようにユーザをフォローする機能がある。フォロー数が多
いほど来訪頻度が高いことが分かっている。興味のあるユーザを推薦すること
でフォロー数が増えるという仮説を検証した。
BigQueryにあるフォロー情報を使ってUser x Userの行列を作る。
コサイン距離を計算するUDFを作り、類似ユーザを抽出した。自分がフォロー
している人の類似ユーザや類似ユーザがフォローしていて自分がしていない人
を推薦した。
協調フィルタリング
UDFを使った手法
16

まとめ

● BigQueryにデータを集約することで、SQLさえ書ければ分析可能となっ
た。
● 分析する人が増えたので、ユーザやアイテムへの理解が進み、機械化が
可能となった。
● 詳細については「グリー技術書典部誌2019秋号」に掲載し、技術書典7@
い07Cで頒布予定。
グリー技術書典部のブースに遊びに来てください！
まとめ
18

LIMIAでのBigQuery活用事例

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (20)

Ähnlich wie LIMIAでのBigQuery活用事例

Ähnlich wie LIMIAでのBigQuery活用事例 (20)

Mehr von gree_tech

Mehr von gree_tech (20)

LIMIAでのBigQuery活用事例