# アップデートの利用状況を確認する

テレメトリー、パッケージ分布、バージョン別の健全性と端末イベントを読み取り、リリースの拡大や調査に役立てます。

## オープンアナリティクス {#analytics}

サインインし、サイドバーから [**ライブ メトリクス**] を選択します。このページには、リクエストの概要、パッケージの配布、バージョンの状態、デバイス、およびイベントの詳細が含まれます。

1. プラットフォーム アプリケーションを分離したまま、リリースされたアプリケーションを選択します。
2. リリース チャンネルを選択するか、全体的なビューのすべてのチャンネルを選択します。
3. リリース時刻を含む過去 24 時間を選択します。
4. セクションを更新して上から下まで読んでください。

以下のスクリーンショットでは、実際の Pakta コンソール コンポーネントとデモンストレーション データを使用しています。

## 概要: アップデートの進行状況を追跡する {#events}

![リクエストの概要: 5 つの更新イベント カウンターとトレンド ライン。デモデータ](/docs-media/analytics-overview.png)

|カウンター |イベント |意味 |
| --- | --- | --- |
|ダウンロード成功 | `download_success` |ダウンロードされたファイル。アクティベーションはまだ確認されていません |
|ダウンロードの失敗 | `download_fail` |ダウンロードに失敗しました。ネットワークとファイルの URL を調査する |
|パッチの失敗 | `patch_fail` |パッチまたは切り替えに失敗しました。後で完全にダウンロードしても成功する可能性があります。
|ロールバック | `rollback` |アップデートの起動に失敗した後、デバイスが回復しました。
|起動成功 | `mark_success` | SDK は実行中のアップデートを確認しました |

5 本線の傾向グラフの上にマウスを移動すると、ある時点のカウントを検査できます。公開後に障害が発生したかどうかを確認し、個々のバージョンを検査します。

電話機は複数のイベントを送信できます。ここでのリクエスト数は、新規ユーザーでも、更新チェック エンドポイントへのすべてのリクエストでもありません。ダウンロードと起動の確認は、異なる時間枠で行われる場合があります。

## 時間範囲とチャートのコントロール {#trends}

- 24 時間、72 時間、7 日間、またはカスタム範囲を選択します。カスタム範囲にはエンドポイントが増加し、最大 8 日間にわたる必要があります。
- 間隔は、各ポイントを要約した分数です。短いインシデントの場合は 5 分、より長い傾向の場合は 30 分または 60 分を使用するか、自動のままにしておきます。
- イベント タイプを選択すると、そのカーブが強調表示され、イベントの詳細がフィルターされます。概要の合計とバージョンの健全性では、比較のためにすべてのタイプが保持されます。
- [更新] は、現在の選択内容を再ロードします。アプリケーション、チャンネル、範囲を変更した後は、フィルターを再確認してください。

14:00 のリリース後のスパイクの場合は、14:00 前後の 2 時間の範囲と、開始位置を特定する 5 分間隔を選択します。

## パッケージ配布: アクティブなバージョンを検索 {#package-distribution}

パッケージ配布の下で **更新パッケージ / ネイティブ パッケージ** を切り替えます。

|寸法 |グループ化 |質問に答える |
| --- | --- | --- |
|パッケージを更新する |ハッシュを更新 |新しいアップデートのレポートは開始されましたか?古いアップデートはまだ有効ですか? |
|ネイティブパッケージ |ネイティブバージョン |インストールされているバージョンでまだ報告があり、修正が必要なのはどれですか? |

行には、リクエスト数とすべてのパッケージリクエストに占めるリクエストの割合が表示されます。最初の 6 つのパッケージが示されており、残りのパッケージは以下にまとめられています。バーの長さは、インストールされているユーザーの範囲ではなく、主要なパッケージを基準としています。

ネイティブ `1.0.0` のレポートが依然として多く、修正の対象が `2.0.0` のみである場合、`2.0.0` の割合を増やしても、`1.0.0` デバイスは修復されません。リリースターゲットを確認してください。

## バージョンの健全性: 配信を拡大するか判断する {#version-health}

![アップデートおよびネイティブ バージョンによるバージョンの健全性。中国語コンソールのデモ データ](/docs-media/analytics-health.png)

リリース ハッシュとネイティブ バージョンを見つけて、安定したアップデートの数とレートを比較します。

|レート |式 |例 |
| --- | --- | --- |
|ダウンロードの失敗 |失敗 / (成功 + 失敗) | 20 / (980 + 20) = 2% |
|ロールバック |ロールバック数 / (起動確認 + ロールバック数) | 5 / (945 + 5) ≈ 0.5% |

分母がゼロの場合はゼロが生成され、健康の証拠は生成されません。サンプルが小さい場合は、より多くの観察とテストが必要です。

1. ダウンロードの失敗が増える: ネットワーク、HTTP、およびファイルのエラーを検査します。
2. ダウンロードが成功してもパッチの失敗が増える: フォールバックを調査し、完全なダウンロードが成功することを確認します。
3. さらにロールバック: 拡張を停止します。起動エラーと正常性の確認を調査します。
4. 検証されたビジネス フローによるダウンロードと起動の継続的な成功: リリース計画に従って拡張します。

## デバイス: 1 台の端末を調査する {#devices}

**デバイス**でデバイス識別子を見つけます。開発者は `getUpdateMetadata().uuid` で読み取ることができます。

1. OS、5 つのイベント数、両方のレート、および最初/最後のレポート時間を検査します。
2. 行をクリックして、そのデバイスごとにイベントの詳細をフィルターします。選択したデバイスのチップが上に表示されます。
3. ダウンロードから確認またはロールバックまでのシーケンスに従います。
4. 行を再度クリックするか、チップを削除して選択をクリアします。

デバイス テーブルには 1 ページあたり 20 行があります。デバイスの選択によりイベントの詳細がフィルターされます。概要が単一デバイスのダッシュボードになるわけではありません。

## イベントの詳細: 検査失敗 {#event-details}

行には、時間、タイプ、デバイス、OS、ネイティブ バージョン、ビルド情報および詳細が含まれます。イベント タイプでフィルターし、更新ハッシュとタイムスタンプを確認します。

|症状 |次をチェック |
| --- | --- |
|起動確認なしでダウンロード |完全な再起動、アクティベーション戦略、MarkSuccess |
| デバイスのロールバック | ハッシュの不一致と起動エラーを確認します。[エラー診断](/docs/errors) |
|多数の同時ダウンロード失敗 |ホスト、オブジェクトの可用性、およびネットワークをダウンロード |
|記録がありません |タイプ/デバイスフィルターをクリアします。アプリケーション、チャネル、範囲、SDK レポートを確認する |

詳細は、サーバーの構成に応じて、デフォルトで 7 日間保持されます。インシデント時間、デバイス識別子、ネイティブ バージョン、ハッシュを速やかに保存します。

## リリース検証を終了 {#loop}

テスト用電話機で新しいコンテンツを確認し、ダウンロードと起動確認の記録を見つけて、主要なビジネス画面をテストします。

次に[コンソールで配信](/docs/console#rollout)します。問題があれば配信を停止するか、[ロールバック](/docs/console#rollback)して、イベント記録を保存してください。

`disableTelemetry: true` は、関連するクライアント レポートを無効にします。空のページの場合は、レポートが有効になっていて、デバイスが正常なサーバー接続でリリース更新フローを実行していることを確認します。