minne でのログの活用事例の一部を紹介

1. bigfoot 活用事例
minne 事業部 CTL shiro16

2. @_shiro16 shiro16

3. shiro16 #とは
● 2015/07 入社 EC 事業部に配属
● 前職、前々職でインフラ〜アプリ(Android) まで一通り経験
● 2015/10 minne に異動
○ 社内公募があったので試用期間にも関わらず応募
● なんやかんやあってチーフテクニカルリード
● 主な仕事は 愛犬と戯れること Elasticsearch 等を使った検索機能の開
発 + 改善 と CTL 業

4. 本題: bigfoot 知ってますか？
bigfoot #とは

5. bigfoot #とは
● ペパボの次世代ログ基盤
● 各サービスの行動ログを集約することにより他サービスの行動も自サービスに
活用できる

6. 詳細は こちら
bigfoot #とは

7. bigfoot #とは

8. ● ログを送る = rack-bigfoot
● ログを貯める = Treasure Data(PlazmaDB)
● ログを扱う = Hive QL(クエリ)
○ 定期実行管理 = bigfoot-cron
● ログを可視化 = redash
● 集計結果を貯める = Treasure Data(PlazmaDB/Datatank)
bigfoot #とは

9. それでは事例のご紹介
bigfoot #とは

10. 事例その 1 : 作家向けアクセス解析

11. 事例その1 : 作家向けアクセス解析
1. 作家が自分の作品のアクセス数を閲覧することが可能
2. アクセス数は作品毎に閲覧が可能
3. アクセス数は日毎に閲覧が可能
4. 閲覧可能なアクセス数の期間は前日までの過去一週間
a. リアルタイムではない
どんな機能か？

12. 設計しよ！
事例その1 : 作家向けアクセス解析

13. 事例その1 : 作家向けアクセス解析
● user_id, product_id, date, pv のカラムを持つテーブル作る
● 作品毎は WHERE user_id = ? でいける
● 日付毎の合計は WHERE user_id = ? GROUP BY date とかでいける
な
● 作品ページにアクセスする毎にインクリメントすればいいか〜
設計

14. という設計にはしません
事例その1 : 作家向けアクセス解析

15. 事例その1 : 作家向けアクセス解析
● 今回の機能はあくまで第一弾の仕様
● 第二弾、第三弾の機能拡張で他にもいろいろなこと見れるようにしたい
なぜか？

16. どうしたか？
事例その1 : 作家向けアクセス解析

17. 事例その1 : 作家向けアクセス解析
● クエリは bigfoot-cron で管理し定期実行
○ ※定期実行機能は Treasure Data のもの
● bigfoot-client を使用して rails からクエリの結果を取得
● 取得した結果を Elasticsearch に保存
● rails では 1 日 1 回上記の job を実行
シン・設計

18. 事例その1 : 作家向けアクセス解析

19. 事例その1 : 作家向けアクセス解析
● 1 日の在庫の復活回数がリリース前より増加
○ アクセス多いが在庫が 0 の作品を(売れそうなので)復活させてくれた
● #minneの人気作品 というハッシュタグをつけての tweet 多数
● 喜びの声多数
結果

20. ちなみにこの機能 3 月中旬にリリースされたのですが、
1 月に配属された ogidow がほぼ 1 人で作ってます
事例その1 : 作家向けアクセス解析

21. 新卒が出来るんだから皆さんなら余裕ですよね？(煽り)
事例その1 : 作家向けアクセス解析

22. 事例その 2 : 注目ワードの更新

23. 事例その2 : 注目ワードの更新
● 実は元々は yaml 管理
● 最終更新日 2016/01 …
● 全く更新されていない
● しかし、一定数のクリックはあるっぽい
注目ワード #とは

24. 自動更新して click 数アゲアゲにしたいので設計しよ！
事例その2 : 注目ワードの更新

25. ● 人気とか最近急に検索回数が増えた(急上昇)単語出すと良さそう
● カテゴリ毎に 10 件からランダムで表示するといいかも
● どんな単語で検索されているか？はログから追う必要がある
● マーケとかでも使いたいから redash でも見れるといいな
○ でも bigfoot-cron と redash でクエリを二重管理したくない
● 集計結果を datatank に入れれば rails + redash で使えて便利
● rails 側は datatank から取得したものを redis に保存しておこう
○ レスポンスタイムの向上の為
設計
事例その2 : 注目ワードの更新

26. 事例その2 : 注目ワードの更新

27. 自動化した結果
事例その2 : 注目ワードの更新
click 数約 1.25 倍

28. ● 最終的に click 数は約 1.25 倍になった
● 過程を省略していますが、注目ワードのロジックは ”人気の単語のみ”
→ “急上昇の単語のみ” → “人気 + 急上昇の単語” という順で変更を行
なった。
● 変更の結果を集計し、最終的に数値が高かった “人気 + 急上昇の単
語” になった
結果補足
事例その2 : 注目ワードの更新

29. 事例その 3 : 開発以外への活用

30. 事例その3 : 開発以外への活用
1. 機能開発後に bigfoot を使用して効果検証をするのは minne ではアタ
リマエ
2. 前日の人気の検索単語を使って twitter に投稿
3. 昨年のログを集計し、バズった検索単語を抽出
a. 例えば “父の日” などの季節要因の単語を何月何日からユーザは探し出す
か？
b. この結果に合わせてマーケ側が特集などを計画
4. GA から完全移行も可能で minne mag は全ての数値を bigfoot から取
得するように変更した
一部を紹介

31. bigfoot 活用事例
1. ログは出来るだけ早く貯めた方が良い
a. 昨年のログを元に色々考えたり出来る
2. 効果検証大事
3. 複雑なクエリむずいけど楽しい
4. ログは貯めるだけではなく、分析、活用するのが大事
5. 思い付きでシュッと出したデータでもマーケの人めっちゃテンション上
がってた
a. 承認欲求満たされる
b. こんなやつ出しましたよって声を出すの大事
c. 見える化も大事
まとめ

32. おわり