Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

(beta)アプリを成長させるためのログ取りとログ解析に必要なこと

1,285 views

Published on

DroidKaigi2018の講演の「アプリを成長させるためのログ取りとログ解析に必要なこと」の発表資料です。

Published in: Technology
  • Be the first to comment

(beta)アプリを成長させるためのログ取りとログ解析に必要なこと

  1. 1. DroidKaigi 2018 @cattaka_net アプリを成長させるための ログ取りとログ解析に必要なこと Takao Sumitomo
  2. 2. DroidKaigi 2018 @cattaka_net2 自己紹介
  3. 3. DroidKaigi 2018 @cattaka_net3 自己紹介 ● 住友 孝郎(Takao Sumitomo) ● たぶんAndroidアプリ開発者 ● 職歴的なもの – SIer的なこと – メーカー的なこと ● – 2014年12月〜 所属
  4. 4. DroidKaigi 2018 @cattaka_net4 Wantedlyプロフィール
  5. 5. DroidKaigi 2018 @cattaka_net5 触ったことあるもの プログラム Java, C++, Ruby, PHP, Python データベース Oracle, Sqlite3, PostgreSQL, MySQL, Realm プラットフォーム等 Android, Linux(Debian), MFC, Struts 設計 UML, Excel方眼紙
  6. 6. DroidKaigi 2018 @cattaka_net6 今日のお話に至った経緯
  7. 7. DroidKaigi 2018 @cattaka_net7 Wantedlyにジョインする前 ● いっぱいいろんなものを作った ● 作るだけならどうにかできる
  8. 8. DroidKaigi 2018 @cattaka_net8 不思議なことをいう人達がいた ● 良いものを作れば自然とユーザーは増える ● 面白いものを作ればバイラルで広がる 本当にそうなのか?
  9. 9. DroidKaigi 2018 @cattaka_net9 そんな中でWantedlyにジョインした
  10. 10. DroidKaigi 2018 @cattaka_net10 ジョイン直後 アプリを良くしていきましょう! (どうやったらいいんだろう...)
  11. 11. DroidKaigi 2018 @cattaka_net11 最初にやったこと ● Google Analyticsを見た – 当時はまだFirebase Analyticsはなかった ● TreasureData(ログ収集サービス)を見た ほとんどWebのログ 体系化されてなくて読み取れない わかるのはせいぜいインストール数とアクティブユーザー数
  12. 12. DroidKaigi 2018 @cattaka_net12 そもそも何をもって良くなったいう? ● 指標は? ● その指標の数字を出すためには? うん、さっぱりわからん
  13. 13. DroidKaigi 2018 @cattaka_net13 Wantedly Visitの例を考える
  14. 14. DroidKaigi 2018 @cattaka_net14 最も簡単な指標 ● マッチングアプリ – 応募ボタンを押す
  15. 15. DroidKaigi 2018 @cattaka_net15 1 2 3 4 5 0.00% 10.00% 20.00% 30.00% 40.00% 50.00% 60.00% 70.00% 80.00% 90.00% 100.00% 応募にたどり着くまでのファネル それまでの過程は? ● 1: インストール ● 2: ユーザー登録 ● 3: 探す操作をする ● 4: 詳細画面を開く ● 5: 応募を押す こんな感じ??
  16. 16. DroidKaigi 2018 @cattaka_net16 その過程を追うには? ● インストール – ユーザーIDごとの最初のイベントを探す ● ユーザー登録 – Web側かアプリ側のログ ● 探す操作をする – アプリ側のログ
  17. 17. DroidKaigi 2018 @cattaka_net17 その過程を追うには? ● 詳細画面を開く – アプリ側のログ – キャッシュされるとWeb側のログじゃわからない ● 応募を押す – Web側のログ ログがWeb側とアプリ側に散らばってる、、、
  18. 18. DroidKaigi 2018 @cattaka_net18 あ、、、これ闇雲にやっても無理だ、、、
  19. 19. DroidKaigi 2018 @cattaka_net19 そのためにやったことのお話です
  20. 20. DroidKaigi 2018 @cattaka_net20 どんな指標があるのか?
  21. 21. DroidKaigi 2018 @cattaka_net21 エンジニアリング的な指標 ● クラッシュ率 ● ANR発生率 ● レンダリング時間 ● APIのレスポンス時間 Android Vitals で確認できる
  22. 22. DroidKaigi 2018 @cattaka_net22 非エンジニアリング的な指標 Google Play Console, Firebase Analytics で確認できる
  23. 23. DroidKaigi 2018 @cattaka_net23 インストール数 ● 単純にインストール数
  24. 24. DroidKaigi 2018 @cattaka_net24 アクティブユーザー数 ● DAU : Daily Active User – 1日のユニークユーザー数 ● WAU : Weekly Active User – 7日間のユニークユーザー数 ● MAU : Monthly Active User – 1ヶ月のユニークユーザー数 – 流派によって28日だったり31日だったりする 単純に掛け算ではないので注意
  25. 25. DroidKaigi 2018 @cattaka_net25 リテンション率 ● 継続率とも呼ばれる ● コホート分析とも呼ばれる – (厳密には違うけど) ● 期間ごとにユーザーを分けて見る
  26. 26. DroidKaigi 2018 @cattaka_net26 リテンション率 Firebase Analyics – demo projectより
  27. 27. DroidKaigi 2018 @cattaka_net27 リテンション率 ● 多機能なアプリの場合 – 機能ごとのリテンション率が無いと どの機能がユーザーを繋ぎ止めてるか追えない
  28. 28. DroidKaigi 2018 @cattaka_net28 コンバージョン率 ● ユーザーの中でコンバージョンした率 ● コンバージョン – そのプロダクトの成果 – たとえば ● ECサービスなら何かが売れた ● マッチングサービスならマッチングが成立した プロダクトによって異なる
  29. 29. DroidKaigi 2018 @cattaka_net29 必要なインフラ
  30. 30. DroidKaigi 2018 @cattaka_net30 簡単な構成 ● ログ収集サービス ● データストア ● 抽出環境 ● 可視化
  31. 31. DroidKaigi 2018 @cattaka_net31 具体的なサービスやプロダクト ログ収集系 データストア 抽出環境 可視化 Firebase Analytics ※1 Google BigQuery Google Data Studio( )β ExcelR Domo Fluentd 普通の RDBMS Treasure Data Hadoop ※1:Firebase Analyticsは一部可視化機能がある
  32. 32. DroidKaigi 2018 @cattaka_net32 ログ収集系 Treasure Data Google BigQuery 最近のWantedlyの構成の紹介 データストア 抽出環境 可視化 Firebase Analytics Excel Domo 普通の RDBMS アプリ
  33. 33. DroidKaigi 2018 @cattaka_net33 ここまでで、お気づきの方も いらっしゃるかも知れませんが...
  34. 34. DroidKaigi 2018 @cattaka_net34 アプリの実装の話が1つも出てません
  35. 35. DroidKaigi 2018 @cattaka_net35 昔のWantedlyの構成の紹介 ログ収集系 Treasure Data Google BigQuery データストア 抽出環境 可視化 Firebase Analytics Excel Domo 普通の RDBMS アプリ この2つを考えるのに、 中間層の理解が必要だった
  36. 36. DroidKaigi 2018 @cattaka_net36 初めてやるなら ● Firebase Analytics ● Google BigQuery ● Excel の組み合わせから始めると無難
  37. 37. DroidKaigi 2018 @cattaka_net37 アプリで取るログの種類
  38. 38. DroidKaigi 2018 @cattaka_net38 アプリで取るログの種類 ● イベントログ – Viewの操作 ● タップやスワイプ – 直接的なコンバージョン ● スクリーンログ – 画面名 – 遷移先の画面名 – 滞在時間
  39. 39. DroidKaigi 2018 @cattaka_net39 イベントログ
  40. 40. DroidKaigi 2018 @cattaka_net40 イベントログの項目 ● ユーザー識別子 ● 画面名 – アプリによってはActivity + Fragment ● イベント名 – タップ / ロングタップ / スワイプなど ● イベントの追加属性 – View ID / アイテムのIDなど – 内部実装はJSONが良いかも(?)
  41. 41. DroidKaigi 2018 @cattaka_net41 イベントログの例 ユーザー 識別子 画面名 イベント名 イベントの 追加属性画面の 追加属性 time user_id screen screen_params event event_params 1234 ListActivity click {"view_id": "title", "item_id": 432} 1234 DetailActivity {"item_id": 432} press_back 1234 ListActivity click {"view_id": "title", "item_id": 234} 1234 DetailActivity {"item_id": 234} click {"view_id": "apply"} 1234 DetailActivity {"item_id": 234} cvt_apply {"item_id": 234} 2018/02/09 12:30 2018/02/09 12:31 2018/02/09 12:32 2018/02/09 12:33 2018/02/09 12:33
  42. 42. DroidKaigi 2018 @cattaka_net42 イベントログのアプローチ ● 自動的にできれば理想だけど、、、 – touchイベントをフックすればできなくはない – 付加情報を追加せざるを得ないケースが多い – 過度に冗長になることがある – デザイン的な事情の独自実装に対応できない 要所要所に丹精込めて埋める
  43. 43. DroidKaigi 2018 @cattaka_net43 Viewの操作 vs コンバージョン ● どっちが解析しやすいか? – Viewの操作として記録 – コンバージョンとして記録 ● ツールに寄る – FAはコンバージョンが扱いやすい time user_id screen screen_params event event_params 1234 DetailActivity {"item_id": 234} click {"view_id": "apply"} 1234 DetailActivity {"item_id": 234} cvt_apply {"item_id": 234} 2018/02/09 12:33 2018/02/09 12:33 ※:2つはユーザーの操作としては 同じ 重要な指標だから両方取る
  44. 44. DroidKaigi 2018 @cattaka_net44 ライブラリごとの実装の違い
  45. 45. DroidKaigi 2018 @cattaka_net45 イベントログの実装:Treasure Data Map<String, Object> event = new HashMap<>(); event.put("user_id", userId); event.put("activity", activityName); event.put("fragment", fragmentName); event.put("event", "select_cotent"); event.put("item_id", itemId); event.put("name", name); TreasureData.sharedInstance() .addEvent("event_log", event); ユーザー識別子 画面 イベント名 追加属性 全部自分でやる!
  46. 46. DroidKaigi 2018 @cattaka_net46 イベントログの実装:Firebase Analytics Bundle bundle = new Bundle(); bundle.putLong (FirebaseAnalytics.Param.ITEM_ID, itemId); bundle.putString (FirebaseAnalytics.Param.ITEM_NAME, name); bundle.putString (FirebaseAnalytics.Param.CONTENT_TYPE, "image"); mFirebaseAnalytics.logEvent( FirebaseAnalytics.Event.SELECT_CONTENT, bundle); ↓追加属性 ↑イベント名 画面やユーザー識別子はやってくれる
  47. 47. DroidKaigi 2018 @cattaka_net47 イベントログの実装:Google Analytics mTracker.send(new HitBuilders.EventBuilder() .setCategory(category.category) .setAction("select_content") .setNonInteraction(false) .build()); ↑イベント名 画面やユーザー識別子はやってくれる
  48. 48. DroidKaigi 2018 @cattaka_net48 ライブラリごとの実装の違い ● TD, FA, GAでそれぞれ微妙に違う ● 特に画面とイベントの紐付けが異なる
  49. 49. DroidKaigi 2018 @cattaka_net49 スクリーンログ
  50. 50. DroidKaigi 2018 @cattaka_net50 スクリーンログの項目 ● 画面遷移が追えるくらい取る ● アプリからの離脱もわかるようにする リスト画面 商品画面 item_id=3 関連商品 item_id=3 商品画面 item_id=7 アプリを起動 アプリから離脱
  51. 51. DroidKaigi 2018 @cattaka_net51 スクリーンログの項目 ● ユーザー識別子 ● 画面名 – アプリによっては Activity + Fragment – 追加の属性 ● 次の画面名 ● 滞在時間 – ミリ秒やナノ秒
  52. 52. DroidKaigi 2018 @cattaka_net52 スクリーンログの例 画面名 画面の 追加属性 次の画面の 追加属性 次の画面名 滞在時間 time user_id screen screen_params next_screen next_params duration 1234 ListActivity DetailActivity {"item_id": 432} 46231 1234 DetailActivity {"item_id": 432} ListActivity 82323 1234 ListActivity DetailActivity {"item_id": 234} 53341 1234 DetailActivity {"item_id": 234} 72652 2018/02/09 12:30 2018/02/09 12:31 2018/02/09 12:32 2018/02/09 12:33
  53. 53. DroidKaigi 2018 @cattaka_net53 スクリーンログのアプローチ ● ActivityやFragment単位で取る ● トラッカーを埋める場所 – onStart / onResume – onStop / onPause ● onStart 〜 onStop で滞在時間が出せる – FAは滞在時間は自動でやってくれる
  54. 54. DroidKaigi 2018 @cattaka_net54 ライブラリごとの実装の違い
  55. 55. DroidKaigi 2018 @cattaka_net55 スクリーンログの実装:Treasure Data Map<String, Object> event = new HashMap<>(); event.put("user_id", userId); event.put("activity", activity); event.put("fragment", fragment); event.put("params", params); event.put("next_activity", nextActivityName); event.put("next_fragment", nextFragmentName); event.put("next_params", nextParams); event.put("duration", duration); TreasureData.sharedInstance() .addEvent("screen_log", event);全部自分でやる! ユーザー識別子 画面 次の画面 滞在時間 ※:onStopなどに書く
  56. 56. DroidKaigi 2018 @cattaka_net56 スクリーンログの実装:Firebase Analytics mFirebaseAnalytics.setCurrentScreen( activity, // Activity "DetailActivity", // screenName null // screenClassOverride ); ←画面名 滞在時間や次の画面の遷移、 ユーザー識別子はやってくれる ※:onStartなどに書く
  57. 57. DroidKaigi 2018 @cattaka_net57 スクリーンログの実装:Google Analytics ←画面名mTracker.setScreenName("DetailActivity"); mTracker.send( new HitBuilders.ScreenViewBuilder().build()); ※:onStartなどに書く
  58. 58. DroidKaigi 2018 @cattaka_net58 トラッカーの実装Tips
  59. 59. DroidKaigi 2018 @cattaka_net59 トラッカーのコードは簡潔安全にしたい
  60. 60. DroidKaigi 2018 @cattaka_net60 WHY ● 機能の実装者の負荷を減らしたい ● トラッカー起因のクラッシュは0にしたい ● トラッカーはミスなく動いてほしい
  61. 61. DroidKaigi 2018 @cattaka_net61 FAでベタで書いたときの問題 Bundle bundle = new Bundle(); bundle.putLong ( "item_id", id ); bundle.putString( "item_name", name ); mFirebaseAnalytics.logEvent("select_content", bundle); イベント名を定数にしたい 属性名を定数にしたい 値を型安全にしたい これらは一度コードに散らばると回収不可能になる
  62. 62. DroidKaigi 2018 @cattaka_net62 アプローチ ● トラッカー用の便利メソッドを作る – イベントをenum化する – 属性をGenericsで型のある定数にする – Generics芸を使った便利メソッドを作る
  63. 63. DroidKaigi 2018 @cattaka_net63 イベントをenum化する public enum Event { SELECT_CONTENT("select_content"), CLICK("click"), // TODO: イベントはここに追加していく ; public final String key; Event(String key) { this.key = key; } }
  64. 64. DroidKaigi 2018 @cattaka_net64 属性をGenericsで型のある定数にする public class Param<T> { public static final Param<Long> ITEM_ID = new Param<>("item_id", BaseBundle::putLong); public static final Param<String> ITEM_NAME = new Param<>("item_name", BaseBundle::putString); String key; IFunc<T> putFunc; private Param(String key, IFunc<T> putFunc) { this.key = key; this.putFunc = putFunc; } public interface IFunc<V> { void put(Bundle dest, String key, V value); }
  65. 65. DroidKaigi 2018 @cattaka_net65 Generics芸を使った便利メソッドを作る public <V1, V2> void logEvent( Event event, Param<V1> k1, V1 v1, Param<V2> k2, V2 v2 ) { Bundle bundle = new Bundle(); k1.putFunc.put(bundle, k1.key, v1); k2.putFunc.put(bundle, k2.key, v2); mFirebaseAnalytics.logEvent(event.key, bundle); } // イベント名 // 属性1 // 値1 // 属性2 // 値2 型安全が守られる 型安全が守られる
  66. 66. DroidKaigi 2018 @cattaka_net66 便利メソッドを使った場合 MyTracker.getInstance().logEvent( Event.SELECT_CONTENT, Param.ITEM_ID, id, Param.ITEM_NAME, name); ● だいぶ短くなった ● イベント名と属性名が定数化された ● 属性の値が型安全になった
  67. 67. DroidKaigi 2018 @cattaka_net67 このアプローチの課題の考察 ● 属性の個数は可変だよね? ● メソッドチェーンの方が良くない?
  68. 68. DroidKaigi 2018 @cattaka_net68 属性の個数は可変だよね? ● 諦めて属性の 数ごとに作る ● RxJavaも 似たことをしてる ● 0〜7個あれば 実用十分 public <V1, V2, V3, V4, V5, V6> void logEvent( Event event, Param<V1> k1, V1 v1, Param<V2> k2, V2 v2, Param<V3> k3, V3 v3, Param<V4> k4, V4 v4, Param<V5> k5, V5 v5, Param<V6> k6, V6 v6 ) { Bundle bundle = new Bundle(); k1.putFunc.put(bundle, k1.key, v1); k2.putFunc.put(bundle, k2.key, v2); k3.putFunc.put(bundle, k3.key, v3); k4.putFunc.put(bundle, k4.key, v4); k5.putFunc.put(bundle, k5.key, v5); k6.putFunc.put(bundle, k6.key, v6); mFirebaseAnalytics.logEvent(event.key, bundle); } 例:属性が6つの場合
  69. 69. DroidKaigi 2018 @cattaka_net69 メソッドチェーンの方が良くない? MyTracker.getInstance() .logEvent(Event.SELECT_CONTENT) .put( Param.ITEM_ID, id ) .put( Param.ITEM_NAME, name ) .send(); たしかに、いいかもしれない、、、けど、、、 これを忘れる事故が起こる
  70. 70. DroidKaigi 2018 @cattaka_net70 僕の結論 ● 便利メソッドが泥臭くなるのは諦める ● 機能の実装者の負担を下げることを最優先
  71. 71. DroidKaigi 2018 @cattaka_net71 複数のライブラリを使うときのアプローチ
  72. 72. DroidKaigi 2018 @cattaka_net72 ログ収集サービスは何個入れる? ● 本発表でも既に複数が出ている – Firebase Analytics – Google Analytics – Treasure Data ● 他にも広告用のものも使うことがある ● 理想は1つに絞るべきだが、そうも行かない
  73. 73. DroidKaigi 2018 @cattaka_net73 複数のログ収集サービスへの送り分けは? ● 専用の便利クラスを作る Firebase Analytics Treasure Data Google Analytics 便利クラスイベント 個別にコードを書くと長くなるので 送り分けのコードはここにまとめる 後々、どんな計測系サービスを使うかわからないので、 1つしか使わない場合も作っておいたほうが良い
  74. 74. DroidKaigi 2018 @cattaka_net74 スクリーンログのトラッカー
  75. 75. DroidKaigi 2018 @cattaka_net75 個別にコードを入れるのは大変 ● 対策1 – BaseActivity や BaseFragment を作る ● onStart や onStop などに仕込む public class BaseFragment extends Fragment { @Override public void onStart() { super.onStart(); MyTracker.getInstance().logScreen(this); } } ↑画面用のメソッド
  76. 76. DroidKaigi 2018 @cattaka_net76 個別にコードを入れるのは大変 ● 対策2 – LifeCycleCallbacks を使う ● ActivityLifecycleCallbacks ● FragmentLifecycleCallbacks
  77. 77. DroidKaigi 2018 @cattaka_net77 FragmentLifecycleCallbacks public class TrackFragmentLifecycleCallbacks extends FragmentManager.FragmentLifecycleCallbacks { @Override public void onFragmentStarted( FragmentManager fm, Fragment f) { super.onFragmentStarted(fm, f); MyTracker.getInstance().logScreen(f); } } ↑画面用のメソッド
  78. 78. DroidKaigi 2018 @cattaka_net78 FragmentLifecycleCallbacks の問題 ● 1つの画面に2つFragmentがあると衝突する ● 対策 – マーカーインターフェースを計測の要否に使う
  79. 79. DroidKaigi 2018 @cattaka_net79 マーカーインターフェースを使う @Override public void onFragmentStarted( FragmentManager fm, Fragment f) { super.onFragmentStarted(fm, f); if (f instanceof ITrackScreen) { MyTracker.getInstance().logScreen(f); } } public interface ITrackScreen {}
  80. 80. DroidKaigi 2018 @cattaka_net80 ViewPagerの問題 ● 左右のFragmentがstart状態になる ● 対策 – 中のFragmentのonResumeでは計測しなくする – 親側で泥臭くハンドリングする ● onStartで最初のFragmentを記録 ● onPageSelectedで切り替わりを記録
  81. 81. DroidKaigi 2018 @cattaka_net81 パッと確認できるようにしておく
  82. 82. DroidKaigi 2018 @cattaka_net82 logcatに出しておく ● トラッカーの確認を検証作業に含めるのは酷 ● 実装者がチラ見でもチェックできるようにする
  83. 83. DroidKaigi 2018 @cattaka_net83 Firebase AnalyticsのDebugViewを使う ● デバッグを有効にしたデバイスの操作が Webブラウザ上でリアルタイムに確認できる
  84. 84. DroidKaigi 2018 @cattaka_net84 通信についての気遣い
  85. 85. DroidKaigi 2018 @cattaka_net85 実装上の気をつけないといけないこと ● 再送制御 – 雑に独自実装するとエラーが出たときに欠損する ● 送信タイミング – 都度通信するとバッテリーに優しくない – 適当なタイミングでまとめてやって欲しい FA, GA, TDは全部やってくれる
  86. 86. DroidKaigi 2018 @cattaka_net86 Firebase Analyticsへの気遣い
  87. 87. DroidKaigi 2018 @cattaka_net87 Firebase Analyticsへの気遣い ● Firebase Analyticsには地味に制約が多い – 制約を守らないとエラーになってログが送れない ● 主な制約 – イベント名の種類は500個まで – イベント名と属性名 ● 英数とアンダースコアで40文字まで – 属性の値は100文字まで – 同一属性名の型は揃えること
  88. 88. DroidKaigi 2018 @cattaka_net88 銀の弾丸は無い、筋肉でカバー
  89. 89. DroidKaigi 2018 @cattaka_net89 ログ取りで気をつけてること
  90. 90. DroidKaigi 2018 @cattaka_net90 1つの指標は最低3系統で確認できること ● おかしな値は割と出る ● 最低3つあれば多数決ができる ● よく使う系統 – アクションログ – コンバージョンログ – Web側のログやDB
  91. 91. DroidKaigi 2018 @cattaka_net91 ログだけでユーザーの操作を 把握できるようにする ● おかしな数字がでたときは生ログを見る ● 計測がおかしいユーザーを探し、 その行動ログから異常を探る
  92. 92. DroidKaigi 2018 @cattaka_net92 機密情報は入れないこと ● 取扱に困るものはログにいれないこと – パスワード – メッセージ – 利用規約やプライバシーポリシーに反するもの
  93. 93. DroidKaigi 2018 @cattaka_net93 定量的な数字も必要ならとる ● RecyclerView – 何処までスクロールしたか – どのViewが何秒表示されたか – getGlobalVisibleRectで頑張って実装
  94. 94. DroidKaigi 2018 @cattaka_net95 可視化する
  95. 95. DroidKaigi 2018 @cattaka_net96 最初はExcelとSQL ● Google BigQueryからSQLでデータを取り出 す ● ピボットテーブルでパッと項目別に集計する
  96. 96. DroidKaigi 2018 @cattaka_net97 Excelは強い ● 数十MB、数十万レコードのCSVを開ける ● そのサイズでもピボットテーブルが動く
  97. 97. DroidKaigi 2018 @cattaka_net98 Google Data Studio(beta) ● データをダッシュボードやレポートにできる ● BigQueryやRDBMSからデータを引っ張れる
  98. 98. DroidKaigi 2018 @cattaka_net99 Domo ● ビジネス管理プラットフォーム ● データの可視化や集約、共有できるサービス ● RDBMSやBigQueryに繋いでグラフが作れる
  99. 99. DroidKaigi 2018 @cattaka_net100 その他 ● Jupyter notebook ● R ● Tableau ● Metabase ● re:dash ● Chartio 他にもたくさんあるのでググってください
  100. 100. DroidKaigi 2018 @cattaka_net101 過去に起こった失敗
  101. 101. DroidKaigi 2018 @cattaka_net102 Notificationでスパイク ● アクティブユーザーに誤検知されていた ● 操作ではないイベントはNonInteractiveにす る – Receive, Open, Cancel など
  102. 102. DroidKaigi 2018 @cattaka_net103 Notificationは麻薬 ● 送れば必ず数字が上がる – 送れば数%のユーザーさんが開いてくれるから ● でも送りすぎるとアンインストールされる ● 開封される傾向を見て送り分けるようにする – BroadcastReceiveで計測できる – Firebaseは標準で開封率が見れる
  103. 103. DroidKaigi 2018 @cattaka_net104 荒ぶるグラフ ● いろんな要因でグラフは壊れる – アプリの改修時の実装ミス – Web側のDBの構成変更 – APIの改修時の構成変更 壊れたら直す リリース日
  104. 104. DroidKaigi 2018 @cattaka_net105 ProGuard先生ェ... ● ログ上の画面名が a とか b になっていた – 雑にclass.getSimpleName()でログを取っていた – 何かの弾みで除外指定が外れて難読化されていた
  105. 105. DroidKaigi 2018 @cattaka_net107 onClickイベントが他所から叩かれていた ● トラッカーは暗黙的にonClickに埋めていた ● 一部の実装がonClickを直接叩いていた ● 画面を開いただけでトラッカーが発火していた
  106. 106. DroidKaigi 2018 @cattaka_net108 広告媒体の違いは怖い ● 広告媒体ごとにユーザーの質が異なる – CPI(Cost Per Install)と継続率は別 ● 対策 – インストール時のリファラーを記録する ● com.android.vending.INSTALL_REFERRER – 広告の計測ライブラリを使う
  107. 107. DroidKaigi 2018 @cattaka_net109 A/Bテストは同時期にやる ● 時間で分けたA/Bテストは恐ろしい – 「先週と今週で比較」は良くない – 広告を使っていると顕著 ● 同じ期間じゃないと徒労に終わる – Firebase Remote Config的なもので サクッと切り替えられるようにする
  108. 108. DroidKaigi 2018 @cattaka_net111 Next Action
  109. 109. DroidKaigi 2018 @cattaka_net112 ディープラーニングで!
  110. 110. DroidKaigi 2018 @cattaka_net113 ごめんなさいよくわかりません
  111. 111. DroidKaigi 2018 @cattaka_net114 アプリエンジニア的アプローチ ● 改善したい数字を決める ● 仮設を立てる ● 効果を見積もる ● 施策を実装してリリースする ● 結果を確認する
  112. 112. DroidKaigi 2018 @cattaka_net115 べき論では良くならない ● 「ガイドラインではこう言われています」 ● 「デザインパターンではこう言われています」 ● 本当にそれが人を幸せにするのか?
  113. 113. DroidKaigi 2018 @cattaka_net116 まとめ
  114. 114. DroidKaigi 2018 @cattaka_net117 アプリにはたくさんの人が関わる ● エンジニア ● デザイナー ● ディレクター ● マーケター ● ビジネス ● カスタマーサポート ● etc
  115. 115. DroidKaigi 2018 @cattaka_net118 それぞれの意図が 正しく成功したか失敗したかを 指し示せるかはログに掛かっている
  116. 116. DroidKaigi 2018 @cattaka_net119 アプリエンジニアが ログをちゃんと取れば メンバーが動きやすくなり プロダクトの成長に繋がる
  117. 117. DroidKaigi 2018 @cattaka_net120 ログを取ろう
  118. 118. DroidKaigi 2018 @cattaka_net121 WANTEDLY TECH BOOK 配布中 ● 技術書典1〜3で 頒布した記事の中から アプリ向けのものを激選
  119. 119. DroidKaigi 2018 @cattaka_net122 ご清聴ありがとうございました

×