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

ZOZOTOWNアプリへのIn-app_updatesの導入とその運用について.pdf

Yusuke Yamada
October 28, 2021
1.4k

 ZOZOTOWNアプリへのIn-app_updatesの導入とその運用について.pdf

Yusuke Yamada

October 28, 2021
Tweet

Transcript

  1. © ZOZO, Inc. 株式会社ZOZO
 ZOZOTOWN開発本部 ZOZOTOWNアプリ部 
 Androidブロック ブロック長 山田

    祐介
 2015年に現在の株式会社ZOZOに入社。
 ZOZOTOWNアプリ開発には2016年から参画し2019年から Androidアプリチームのマネジメント業務を担当。
 現在9名のメンバーに支えられながら奮闘中。
 好きな言葉は適材適所。
 
 
 2
  2. © ZOZO, Inc. https://zozo.jp/
 3 • ファッション通販サイト
 • 1,400以上のショップ、8,400以上のブランドの取り扱い
 •

    常時83万点以上の商品アイテム数と毎日平均2,900点以上の新着 商品 を掲載(2021年6月末時点)
 • ブランド古着のファッションゾーン「ZOZOUSED」や
 コスメ専門モール「ZOZOCOSME」、靴の専門モール
 「ZOZOSHOES」、ラグジュアリー&デザイナーズゾーン
 「ZOZOVILLA」を展開
 • 即日配送サービス
 • ギフトラッピングサービス
 • ツケ払い など

  3. © ZOZO, Inc. 4 アジェンダ
 • In-app updatesとは? • 導入背景

    • 仕様・運用方法 • 導入結果 • Tips
  4. © ZOZO, Inc. In-app updatesとは?
 アプリ内でアプリの更新ができる機能
 Play Core ライブラリが提供する機能、Version 1.5.0

    以降で利用可能
 Android 5.0以上がサポート対象
 
 フレキシブル アップデートと即時アップデートの2種類のUXフローがある
 6
  5. © ZOZO, Inc. 8 In-app updatesとは?
 着目したポイント • UIの実装はほぼライブラリが提供 •

    アプリの利用を極力妨げない(フレキシブル アップデート) デザイナーのリソースをほとんど必要としないため、導入できるかはAndroidエンジニア次第
 フレキシブルアップデートはダウンロードしながらアプリが利用できユーザーフレンドリー

  6. © ZOZO, Inc. 導入背景
 11 <具体例1>
 2021/3/18にリリースしたVersionにてクラッシュ発生
 Firebase Crashlytics上でのデイリーのクラッシュフリー率が97%まで低下
 (ユーザーがアプリをバックグラウンドにした際にクラッシュ)


    
 2021/3/23修正版リリース
 リリース後徐々に改善したがクラッシュフリー率を元の状態に戻すのに1週間以上必要だった
 ※この期のチーム目標の1つにクラッシュフリー率の維持を掲げていた
 低下した場合は1週間以内にリカバリーするとしていたが上記の通り目標を達成することはできな かった

  7. © ZOZO, Inc. 導入背景
 12 <具体例2>
 2021/3/18にリリースしたVersionにて不具合発生
 検索結果の画面でページングすると並び順がリセットされる不具合
 1日に3件前後同じ内容で問い合わせが発生
 


    2021/3/22修正版リリース
 問い合わせはリリースから1週間ぐらいで落ち着いた
 しかし更新に気づいていないユーザーから6、7月にも問い合わせが発生

  8. © ZOZO, Inc. 仕様・運用方法
 15 更新訴求の仕様 • フレキシブルアップデートを採用 • 更新内容に応じて訴求の頻度を変更

    開発チーム内での仕様検討時に「購入しようとした時に更新が始まると購買意欲が下がる」や「短 い期間に何度も出てくるとキャンセルが常態化する」等の意見があり、訴求の頻度を4パターンに分 類して運用することに決定
 

  9. © ZOZO, Inc. 16 仕様・運用方法
 4パターンの訴求頻度 1. 訴求なし 2. 1回のみ訴求

    3. 24時間に1回のみ訴求 4. アプリがフォアグラウンドになるたびに訴求 
 
 

  10. © ZOZO, Inc. 18 仕様・運用方法
 訴求頻度使い分けイメージ • 24時間に1回訴求 → キャンペーンと連動する機能のリリースやA/Bテスト、クラッシュ改

    善、不具合改修 • アプリがフォアグラウンドになるたびに訴求 → アプリ利用を妨げる重大な不具合改修 この訴求頻度の制御はIn-app updatesのinAppUpdatePriorityで実施

  11. © ZOZO, Inc. 仕様・運用方法
 19 inAppUpdatePriorityについて • apk・aabごとに設定できる0~5の値
 • 値の設定はGoogle

    Play Consoleにapk・aabをアップロード時
 ◦ Google Play Developer API でのみ設定可能
 ◦ ZOZOTOWNでは gradle-play-publisher を利用して設定
 • アプリ上ではAppUpdateInfo.updatePriority()で取得
  12. © ZOZO, Inc. 仕様・運用方法
 20 inAppUpdatePriorityに値を設定 ZOZOTOWNでは gradle-play-publisher を利用して設定 app/build.gradleに以下のようなブロックを用意し

    ./gradlew publishReleaseBundle を実行 play { track.set("internal") releaseStatus.set(com.github.triplet.gradle.androidpublisher.ReleaseStatus.DRAFT) updatePriority.set(5) } 上記の場合は内部テスト配信にaabファイルビルドしてDRAFT状態でアップロードしている その際にinAppUpdatePriorityには5を設定している
  13. © ZOZO, Inc. 仕様・運用方法
 21 inAppUpdatePriorityの取得 val appUpdateInfo = AppUpdateManagerFactory.create(context).requestAppUpdateInfo()

    val updatePriority = appUpdateInfo.updatePriority() requestAppUpdateInfo()はsuspend関数でGoogle Play Storeからデータを取得している ここで取得できるinAppUpdatePriorityは単純に最新のアプリバージョンのinAppUpdatePriorityを返 すわけではなくちょっと気が利いた自動計算の仕組みが組み込まれている
  14. © ZOZO, Inc. 22 仕様・運用方法
 inAppUpdatePriorityの自動計算の仕組み 公式ドキュメントより アプリのコードで、updatePriority() を使用して特定のアップデートの優先度を確認できます。返される優先度は、 インストールされているバージョンと利用可能な最新バージョン間のすべてのアプリ

    バージョン コードの inAppUpdatePriority を考慮します。 この文章のみから読み取ることは難しいが、実はこの仕組み
 「現在使っているバージョンと最新バージョンの間のリリースの中でもっとも優先度の高い値が取得 できる」
 ということ

  15. © ZOZO, Inc. 23 仕様・運用方法
 inAppUpdatePriorityの自動計算の仕組み(図解) APP Ver:3.1.0 inAppUpdatePriority:1 更新内容:機能追加

    APP Ver:3.1.1 inAppUpdatePriority:2 更新内容:不具合修正 10/1 10/2 リリース ユースケース APP Ver:3.1.2 inAppUpdatePriority:0 更新内容:リファクタリング 10/10
  16. © ZOZO, Inc. 24 仕様・運用方法
 inAppUpdatePriorityの自動計算の仕組み(図解) APP Ver:3.1.0 inAppUpdatePriority:1 更新内容:機能追加

    APP Ver:3.1.1 inAppUpdatePriority:2 更新内容:不具合修正 10/1 10/2 リリース ユースケース APP Ver:3.0.0 updatePriority:1 
 Ver 3.1.0リリース後、Ver 3.1.1がリリースされるまでの間は、updatePriorityは1となる
 APP Ver:3.1.2 inAppUpdatePriority:0 更新内容:リファクタリング 10/10
  17. © ZOZO, Inc. 25 仕様・運用方法
 inAppUpdatePriorityの自動計算の仕組み(図解) APP Ver:3.1.0 inAppUpdatePriority:1 更新内容:機能追加

    APP Ver:3.1.1 inAppUpdatePriority:2 更新内容:不具合修正 10/1 10/2 APP Ver:3.1.2 inAppUpdatePriority:0 更新内容:リファクタリング 10/10 リリース ユースケース 
 Ver 3.1.1リリース後はVer 3.0.0、3.1.0利用ユーザーのupdatePriorityは2となる
 APP Ver:3.1.0 updatePriority:2 APP Ver:3.0.0 updatePriority:2
  18. © ZOZO, Inc. 26 仕様・運用方法
 inAppUpdatePriorityの自動計算の仕組み(図解) APP Ver:3.1.0 inAppUpdatePriority:1 更新内容:機能追加

    APP Ver:3.1.1 inAppUpdatePriority:2 更新内容:不具合修正 10/1 10/2 APP Ver:3.1.2 inAppUpdatePriority:0 更新内容:リファクタリング 10/10 リリース ユースケース 
 Ver 3.1.2リリース後、Ver 3.1.1利用ユーザーのupdatePriorityは0となる
 しかし、Ver 3.0.0、3.1.0利用ユーザーのupdatePriorityは2となる
 -> Ver 3.1.1のユーザーにとってはVer 3.1.2の更新は重要ではないが、
 Ver 3.1.0以下のユーザーにとってはVer 3.1.1の修正を含むVer 3.1.2は重要な更新
 APP Ver:3.1.1 updatePriority:0 APP Ver:3.0.0,3.1.0 updatePriority:2
  19. © ZOZO, Inc. 仕様・運用方法
 27 inAppUpdatePriorityの仕組みまとめ • Version毎に0~5の値が設定可能 • アプリで取得する際には現在のVersionから最新のVersionまでの間で

    一番高い値を返す 
 
 この仕組みを利用するためにエンジニアがやることは、apk・aabをGoogle Play Consoleにアップロードす るときに値を設定するのみ
 
 なので、Androidエンジニアのリソースのみで運用可能!

  20. © ZOZO, Inc. 仕様・運用方法
 28 inAppUpdatePriorityを仕様に適応 • 0・・・訴求なし • 1・・・1回のみ訴求

    • 2・・・24時間に1回のみ訴求 • 3・・・アプリがフォアグラウンドになるたびに訴求 • 4,5・・・利用しない(実装上は3と同じ) ZOZOTOWNの仕様としては4パターンで十分だったため0~3を利用することにし、4,5は利用はしないが 実装上は3と同じ扱いにした

  21. © ZOZO, Inc. 仕様・運用方法
 29 まとめ • フレキシブルアップデートを採用 • 更新内容に合わせて訴求の頻度を制御

    • 制御はAndroidエンジニアが管理可能なinAppUpdatePriorityを利用 
 
 ※こちらZOZOTOWNアプリのVer 7.1.7(2021/6/21リリース)から導入しています

  22. © ZOZO, Inc. 導入結果
 31 赤:優先度2 黄:優先度1 青:優先度0 優先度(inAppUpdatePriority)ごとの浸透率 アプリリリース後から4日後までの最新Ver更新率をグラフ化


    リリース日から4日ほどたつと数値が横ばいになってくるためそこまでのデータを集計
 優先度以外の要因で変化している可能性もある(プレスリリースやリリースした曜日等)

  23. © ZOZO, Inc. 導入結果
 32 赤:優先度2 黄:優先度1 青:優先度0 優先度2について ※更新訴求は24時間に1回

    優先度(inAppUpdatePriority)ごとの浸透率 リリース1日後から全体的に有意差がある、数値的には10%ほど
 3日後からほぼ横ばい

  24. © ZOZO, Inc. 導入結果
 33 赤:優先度2 黄:優先度1 青:優先度0 優先度1について ※更新訴求は1回のみ

    優先度(inAppUpdatePriority)ごとの浸透率 データが2回分しかなく、それぞれで結果に差異があるため、もう少しデータが必要そう

  25. © ZOZO, Inc. 導入結果
 34 赤:優先度2 黄:優先度1 青:優先度0 優先度0について ※更新訴求なし

    優先度(inAppUpdatePriority)ごとの浸透率 優先度2に比べると全体を通して低い数値となっている
 1つ高い数値をとっているものは2日前に優先度2のリリースがあったためその影響が考えられる

  26. © ZOZO, Inc. 導入結果
 35 まとめ • 24時間に1回の訴求(優先度2)で効果はでた • 特にリリース翌日の数値は10%ほどの差がでた

    • 4日目ぐらいから変化が少なくなっている 
 
 迅速にユーザーに更新を提供する効果あり!

  27. © ZOZO, Inc. 36 全体のまとめ • クラッシュ改善&不具合改修を迅速にユーザーに届けたかった • 実装&運用をAndroidエンジニアのリソースで賄いたかった ◦

    In-app updatesとInAppUpdatePriorityの仕組みが適していた • 実際に導入してユーザーの最新Versionへの更新速度に効果があった
  28. © ZOZO, Inc. InAppUpdatePriority Tips
 38 UpdatePriority取得の確認方法について • Google Play

    Storeのデータを削除が良い(logcatで確認可) • 内部テスト配信でも確認可能 • 内部アプリ共有では確認不可 • 動作確認のapkはApp Bundle エクスプローラから取得が簡単 
 

  29. © ZOZO, Inc. InAppUpdatePriority Tips
 39 Google Play Storeのデータを削除が良い(logcatで確認可) 


    
 データ削除後にGoogle Play Storeを起動すると以下のようなログが出力され る I/Finsky: [1596] afae.run(35): UCtl: Package jp.zozo.android.town client staleness timestamp changed from 0 to 1635133443611, available version changed from 0 to 428 or in-app update priority changed from 0 to 2. 上記の場合は2がAppUpdateInfo.updatePriority()で返却されるようになる
  30. © ZOZO, Inc. InAppUpdatePriority Tips
 40 内部テスト配信でも確認可能 
 
 スライド20にもある通りInAppUpdatePriorityは

    Play Store Consoleにアップロード時に設定 内部テスト(internal)でもアップロード可能でその 時点でアプリ側で値を取得できるようになる ※Google Play Storeのデータ削除を推奨
  31. © ZOZO, Inc. InAppUpdatePriority Tips
 41 内部アプリ共有では確認不可 
 
 内部アプリ共有にもGoogle

    Play Developer API を使ってアッ プロードは可能だが、この場合は AppUpdateInfo.updatePriority()は0になってしまう。 ※In-app updates自体の動作確認は内部アプリ共有でも可
  32. © ZOZO, Inc. InAppUpdatePriority Tips
 42 動作確認のapkはApp Bundle エクスプローラから取得が簡単 


    
 すでに一度リリースしている前提とはなるが、 App Bundle エクスプローラなら署名付のapk がダウンロード可能なのでこちらを利用するの がおすすめ