Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Android Vitalsのデータを自動監視して、 ビジネス指標を向上させよう/ Auto...

Yusuke Suzuki
October 05, 2022

Android Vitalsのデータを自動監視して、 ビジネス指標を向上させよう/ Automatically monitor Android Vitals data to improve business metrics.

DroidKaigi 2022の資料です。
https://droidkaigi.jp/2022/timetable/364446

Yusuke Suzuki

October 05, 2022
Tweet

More Decks by Yusuke Suzuki

Other Decks in Technology

Transcript

  1. © ZOZO, Inc. 株式会社ZOZO
 ZOZOTOWN開発本部 ZOZOTOWNアプリ部
 Android2ブロック 鈴木 優佑
 •

    2020年 新卒入社
 • 静岡県出身 実家はお茶農家🍵
 • Twitter: @s1u2z1u3ki
 
 2
  2. © ZOZO, Inc. https://zozo.jp/
 • ファッションEC
 • 1,500以上のショップ、8,500以上のブランドの取り扱い
 • 常時90万点以上の商品アイテム数と毎日平均2,600点以上の新着

    商品 を掲載(2022年6月末時点)
 • ブランド古着のファッションゾーン「ZOZOUSED」や
 コスメ専門モール「ZOZOCOSME」、靴の専門モール
 「ZOZOSHOES」、ラグジュアリー&デザイナーズゾーン
 「ZOZOVILLA」を展開
 • 即日配送サービス
 • ギフトラッピングサービス
 • ツケ払い など
 3
  3. © ZOZO, Inc. アジェンダ
 • ビジネス指標とエンジニアの貢献
 • ビジネス指標とアプリの品質の関係
 • アプリの品質を確認する方法


    • チームでの品質の維持/改善の取り組みとその改善点
 • 改善点の解決に向けた取り組み
 4
  4. © ZOZO, Inc. 5 ビジネス指標とエンジニアの貢献
 ビジネス指標
 ◦ サービスの性能を測るための指標を指すこととする(e.g. CVR, UU)


    
 
 エンジニアが貢献できること
 ◦ 案件の実装
 ◦ エンジニアからの新機能/機能改善の提案と実装
 ◦ アプリの品質を維持・改善する
 品質の例: 起動速度, クラッシュ, ANR, レンダリングスピード
 ◦ etc.

  5. © ZOZO, Inc. 6 ビジネス指標とエンジニアの貢献
 ビジネス指標
 ◦ サービスの性能を測るための指標を指すこととする(e.g. CVR, UU)


    
 
 エンジニアが貢献できること
 ◦ 案件の実装
 ◦ エンジニアからの新機能/機能改善の提案と実装
 ◦ アプリの品質を維持・改善する
 品質の例: 起動速度, クラッシュ, ANR, レンダリングスピード
 ◦ etc.
 話すこと

  6. © ZOZO, Inc. 7 アプリの品質とビジネス指標の関係①
 
 (前略) アプリの指標が上昇すると宣伝材料となる価値が高まり、Google Play ストアの検索ランキングも向上します。また、

    Google Play の「新着&更新済み」や「エディターのおすすめ」のコレクション、Google Play アワードのノミネート作品に選ばれ る可能性も高まります。
 Android Developers「Android Vitals を使用してアプリのパフォーマンス、安定性、サイズを改善する」. https://developer.android.com/distribute/best-practices/develop/android-vitals?hl=ja 
 Android Developersにおいて、品質に関する指標が上昇すると下記のメリットがあることが言及されている
 
 • Play Storeの検索ランキングの向上
 • 「新着&更新済み」「エディターのおすすめ」への掲載の可能性が上がる
 • Google Play アワードのノミネートの可能性が上がる

  7. © ZOZO, Inc. 8 アプリの品質とビジネス指標の関係②
 Google I/O 2022. 「What’s new

    in app performance」. https://www.youtube.com/watch?v=DYdHLqLVspY 
 
 Google I/O 2022「What’s new in app performance」において紹介されている例
 • ANRを50%減少
 → ユーザリテンション率が20%増加
 → トランザクション数が30%増加
 
 • アプリ起動時間を35%改善
 • ANRを40%減少
 → より良いレビューが20%増加
 

  8. © ZOZO, Inc. 9 Android Vitals
 • アプリの安定性とパフォーマンスを改善するための
 Googleの取り組み
 


    • アプリの品質に関する指標が自動的に記録される
 
 • 主な指標 (=Core vitals)
 ◦ ANR発生率
 ◦ クラッシュ発生率
 ◦ 停止した部分的なwake lock(バックグラウンド)
 ◦ 過度のwakeup
 
 • その他の指標
 ▪ スタートアップ時間と読み込み時間
 ▪ バッテリー情報, etc.
 
 
 Google Play Consoleでの表示例 アプリの品質を確認する方法

  9. © ZOZO, Inc. 10 • ANR発生率
 ◦ ANR(Application Not Responding)が発生した割合


    ◦ ANRはUIスレッドが長時間ブロックされると発生する
 
 • クラッシュ発生率
 ◦ クラッシュが発生した割合
 ◦ クラッシュは未処理の例外やシグナルがスローされると発生する
 
 • 停止した部分的なwake lock (バックグラウンド)
 ◦ アプリがバックグラウンドで実行されており、1時間以上続く部分的なwake-lockが発生した割合
 ◦ 部分的なwake-lockとはディスプレイがオフになった後もCPUを動作させられる仕組み
 
 • 過度のwakeup
 ◦ 平均して1時間に10回を超えるwakeupが発生したセッションの割合
 ◦ wakeupとはAlarmManagerAPIの機能で、指定した時間に処理を開始する仕組み
 Core vitalsの詳細

  10. © ZOZO, Inc. 11 毎朝、手動監視をして、クラッシュとANRの指標の改善・維持に取り組んでいる
 
 
 
 • 手動監視


    ◦ Firebase ConsoleのCrashlytics
 ▪ クラッシュフリー率
 ▪ 増加傾向のクラッシュ
 ◦ Google Play Console
 ▪ ANR発生率
 
 ZOZOTOWN Android チーム内の取り組み
 
 

  11. © ZOZO, Inc. 12 ZOZOTOWN Android チーム内の取り組みと改善点
 
 
 毎朝、手動で監視をして、クラッシュとANRの指標の改善・維持に取り組んでいる


    
 
 
 • 手動監視
 ◦ Firebase Crashlytics
 ▪ クラッシュフリー率
 ▪ 増加傾向のクラッシュ
 ◦ Google Play Console
 ▪ ANR発生率
 
 
 自動監視 + 監視指標を増やす
 
 
 改善点
 
 

  12. © ZOZO, Inc. 13 目標
 
 
 • 「手動監視 →

    自動監視」にする
 ◦ 過去24時間の指標値を自動で取得
 
 
 • 監視する指標を増やす
 ◦ 現状(=クラッシュとANR)に加えて、Android Vitalsで確認可能な指標を取得
 
 
 過去24時間のVitalsの指標値を自動で取得しているイメージ

  13. © ZOZO, Inc. 2022年3月にリリースされ、API経由でCore vitalsの指標が取 得可能になった
 
 • 「Core vitals」の4つ指標を取得可能


    ◦ ANR発生率
 ◦ クラッシュ発生率
 ◦ 停止した部分的なwake lock(バックグラウンド)
 ◦ 過度のwakeup
 
 • 使用例
 ◦ 独自のダッシュボードの構築
 ◦ 他のデータセットとの結合
 ◦ etc..
 14 Google Play Developer Reporting APIが爆誕
 
 Android Developers Blog. 「Access Android vitls data through the new Play Dveloper Reporting API」. https://android-developers.googleblog.com/2022/03/play-developer-reporting-API.html 

  14. © ZOZO, Inc. 17 指標値の取得
 
 
HTTP メソッド
 POST applicationId:

    AndroidのアプリケーションIDを指定
 • 例: jp.zozo.android.town
 
 
 
 
 metricSet: 指標の集合(=MetricSet)を指定
 • ANR: anrRateMetricSet
 • クラッシュ: crashRateMetricSet
 • 停止した部分的なwake lock(バックグラウンド): stuckBackgroundWakelockRateMetricSet
 • 過剰なウェイクアップ: excessiveWakeupRateMetricSet
 エンドポイント https://playdeveloperreporting.googleapis.com/v1beta1/apps/{applicationId}/{metricSet}
  15. © ZOZO, Inc. 20 集計周期と集計期間を指定する。 TimeLineSpecのJSON
 aggregationPeriod
 • 1日周期: DAILY


    • 1時間周期: HOURLY
 • 不特定の周期:
 AGGREGATION_PERIOD_UNSPECIFIED
 
 startTime
 • 集計開始日時を指定する
 • utcOffset, timeZoneなどを指定する
 
 endTime
 • 集計終了日時を指定
 • startTimeと同様にパラメータを指定する
 
 timelineSpec
 
 

  16. © ZOZO, Inc. 22 指標データの「取得軸」を指定する。 dimensionsの例
 • apiLevel: AndroidのAPIレベル
 •

    versionCode: アプリケーションのバージョン
 • deviceModel: 端末のモデルを示す一意の文字列
 • deviceScreenSize: 端末の画面サイズ
 • deviceScreenDpi: 端末の画面密度
 例: dimensionsにapiLevelを指定した場合
 
 → Android APIレベルごとの指標(クラッシュ発生率, ANR発生率など)を取得できる。
 
 
 
 dimensions
 
 

  17. © ZOZO, Inc. 24 取得する指標を設定する。(取得するmetricSetごとに異なる)
 ※crashRateMetricSet のmetricsについて説明する
 crashRate • 集計期間中に少なくとも1回のクラッシュを経験したユーザの割合


    
 crashRate7dUserWeighted • 過去7日間のcrashRateの移動平均
 • その日のユーザ数で重み付けされる
 
 crashRate28dUserWeighted
 • 過去28日間のcrashRateの移動平均
 • その日のユーザ数で重み付けされる distinctUsers • 集計期間内のユーザ数 metrics
 
 

  18. © ZOZO, Inc. 26 • 取得するデータに適用するフィルタを設定する
 • 現状では等号(=)によるフィルタリングをサポートしている
 • dimensionsでフィルタリングができる


    例: filterにapiLevel=30を指定した場合
 
 → APIレベル30にフィルタリングされた指標値が取得できる
 filter
 
 

  19. © ZOZO, Inc. 28 • レスポンスデータの最大サイズを指定する
 • デフォルトで1,000行, 最大で100,000行
 pageToken

    • 前のAPI呼び出しから受け取ったページトークンを指定する
 • 前のAPI呼び出しの後続のページを取得できる
 pageSize
 
 

  20. © ZOZO, Inc. 29 指標取得の例
 
 
条件
 2022/09/04のデイリーのクラッシュ率をAPIレベルごとに取得する
 HTTP メソッド


    POST エンドポイント https://playdeveloperreporting.googleapis.com/v1beta1/apps/{applicationId}/crashRateMetricSet
  21. © ZOZO, Inc. 33 指標値の鮮度情報の取得
 
 
 HTTP メソッド
 GET

    エンドポイント https://playdeveloperreporting.googleapis.com/v1beta1/apps/{applicationId}/{metricSet} レスポンスの例
 APIリクエスト時では、クラッシュのmetricSetは2022/9/24 が取得可能な最新のデータとなる
 
 TimelineSpecで指定可能な最新の時刻を取得できる

  22. © ZOZO, Inc. 34 API一覧(v1 alpha1)
 
 
 • データの異常値情報の取得


    ◦ 過去28日間の指標値に基づき、指標値が予想範囲を超えると異常値として検出される
 ◦ 予想範囲とは検出モデルによって決定し、指標値の異常が続くと予想範囲も広がる
 
 • エラーレポートの情報取得
 ◦ Vitalsが収集したエラーレポートの数やその詳細を取得できる
 

  23. © ZOZO, Inc. 35 • DAILYの結果のみ取得可能
 ◦ 現在の時刻から「N時間前」という指定ができない
 
 •

    Core vitalsの指標のみ取得可能
 ◦ アプリの起動時間やバッテリーの情報などの取得ができない
 
 • タイムゾーンが「America/Los_Angeles」の指定のみ可能
 ◦ 日本のタイムゾーン指定ができない
 
 
 
 
 Google Play Developer Reporting APIを調査した結果
 
 

  24. © ZOZO, Inc. 36 目標
 
 
 • 「手動監視 →

    自動監視」にする
 ◦ 過去24時間の指標値を自動で取得 ❌
 
 
 • 監視する指標を増やす
 ◦ 現状(=クラッシュとANR)に加えて、Android Vitalsで確認可能な指標を取得
 
 
 → Google Play Developers APIでは設定した目標を満たすことが難しい

  25. © ZOZO, Inc. 37 目標を再設定
 
 
目標: 過去24時間のクラッシュフリー率を自動監視し、基準値を割ったらアラートを出す
 
 背景


    ◦ Core vitalsがPlay Storeの検索ランキングなどに影響が大きいとされている
 ◦ ZOZOTOWNではCore vitalsの中でもクラッシュ以外の指標の低下は少ない
 
 
 
 
 
 
 
 

  26. © ZOZO, Inc. 38 クラッシュを自動取得できる方法の比較
 
 
 データソース
 GA4
 Firebase

    Crashlytics
 取得方法
 BigQuery API
 
 ※ データをBigQueryに Exportする必要あり
 Analytics Data API
 BigQuery API
 
 ※ データをBigQueryに Exportする必要あり
 過去24時間前の
 データ取得
 △
 
 ×
 
 
 
 ◯
 
 
 欠損値が発生する
 可能性あり 30分前のデータしか取得 できない ストリーミングエクスポート の使用で取得可能 1. アナリティクス ヘルプ.「[GA4] BigQuery Export」. https://support.google.com/analytics/answer/9358801 
 2. Google Developers Google Analytics Data API. 「Method: properties.runRealtimeReport」. https://developers.google.com/analytics/devguides/reporting/data/v1/rest/v1beta/properties/runRealtimeReport 
 
 1
 
 
 2
 
 

  27. © ZOZO, Inc. 39 クラッシュを自動取得できる方法の比較
 
 
 データソース
 GA4
 Firebase

    Crashlytics
 取得方法
 BigQuery API
 
 ※ データをBigQueryに Exportする必要あり
 Analytics Data API
 BigQuery API
 
 ※ データをBigQueryに Exportする必要あり
 過去24時間前の
 データ取得
 △
 
 ×
 
 
 
 ◯
 
 
 欠損値が発生する
 可能性あり 30分前のデータしか取得 できない ストリーミングエクスポート の使用で取得可能 1
 
 
 2
 
 
 Firebase Crashlyticsのデータを用いることに
 • 過去24時間前のデータが取得可能
 • BigQueryへのエクスポートも簡単にできる

  28. © ZOZO, Inc. 40 自動監視のアーキテクチャ図
 
 
 ① ストリーミング
 エクスポート


    Github Actions
 ② クラッシュフリー率取得 
 (定期実行)
 ③ クラッシュフリー率を通知
 BigQuery

  29. © ZOZO, Inc. 44 アラート発生時の運用
 
 
 1. 日替わりの担当者がアラートの原因を調査する
 2.

    必要に応じてメンバーを招集し以下の対応を進める
 3. 「重要度」を決定する
 ▪ High: hotfix対応
 ▪ Medium: 次回以降のリリースで対応
 ▪ Low: 静観
 4. 修正するバージョンを決定する
 5. 修正 or 調査タスクの作成と見積もりをする
 6. 修正/QA相談の担当者を決める
 7. 上記の対応方針をまとめる
 ◦ 内容: クラッシュの内容, 重要度とその決定理由, 修正担当者/QA相談者, 対応チケット
 8. 必要に応じて関係部署へ連絡
 ◦ 例: 問い合わせが発生しそうな場合はカスタマーサポートのチームへ共有
 

  30. © ZOZO, Inc. 45 重要度決定の観点
 
 
下記の観点を総合的に判断して決定する
 
 • アプリの基本機能に関するクラッシュか?


    ◦ アプリを開く
 ◦ ログインする, etc.
 • ユーザの問い合わせにつながりそうか?
 • 案件に影響があるか?
 ◦ 案件のKPI
 ◦ プレスリリースの有無
 ◦ A/Bテストの分析への影響
 • クラッシュ数は増加する見込みか?
 ◦ クラッシュ増加の傾向の有無
 ◦ 週末をまたぐか?
 ◦ ユーザ数などが増えるイベントが控えているか?
 

  31. © ZOZO, Inc. まとめ
 • ビジネス指標の向上にはアプリの品質を向上させることが重要
 
 • チームの取り組みに対する改善点を目標として設定
 ◦

    手動監視 → (過去24時間の指標値を)自動監視
 ◦ 監視する指標を増やす
 
 • Google Play Developer Reporting APIについて
 
 • 目標を再設定
 ◦ 過去24時間のクラッシュフリー率を自動監視
 ◦ 基準値を割ったらアラート
 
 • Crashlyticのデータを用いる手法を解説
 
 • アラート発生時のチーム内の運用について解説
 46