Google Home Vitals ダッシュボードで製品の品質を測定する方法

1. 始める前に

この Codelab は、エコシステムの品質とユーザー エクスペリエンスを向上させるために、Google Home パートナーと Cloud インテグレーションのデベロッパーを対象としています。

学習内容

Google Home Vitals ダッシュボードは、デベロッパーとパートナーが Google Home 統合の運用状況をモニタリングするための信頼できる一元的な情報源として機能します。レイテンシと信頼性によってユーザー エクスペリエンスが定義されるエコシステムにおいて、Google Home Vitals は、事後対応のトラブルシューティングから事前対応の品質管理への移行に必要な詳細な分析をすべて含むセルフサービス ポータルです。

  • 品質統合スコアの計算方法
  • ダッシュボードの読み方と使い方
  • 品質指標のデバッグ方法

必要なもの

  • Google Home Cloud Integration がある

セットアップ

Google Home Vitals ダッシュボードに移動する方法:

  1. Google Cloud Platform を開く
  2. [モニタリング] > [ダッシュボード]
  3. [Google Home Vitals (Cloud)] ダッシュボードをクリックします。

2. ダッシュボードの読み方

品質スコアの計算 - 「良好」と「不良」の基準

ダッシュボードには、品質スコアの内訳が表示されます。品質スコアは、デバイスタイプの粒度で割り当てられます。デバイス タイプ統合が「良好」と見なされるには、次の 4 つの条件を同時に満たす必要があります。

  1. 全体的な成功率: パートナーから Google への呼び出しの全体的な成功率が 99.5% 以上である必要があります。
    注: 全体的な成功率（99.5% 以上）を満たしていない場合、個々のデバイスのパフォーマンスに関係なく、プロジェクト全体で自動的に「不良」の評価となります。
  2. コマンドの信頼性: QUERY と EXECUTE の成功率は、すべてのデバイスタイプで 99.5% 以上である必要があります。
  3. 応答レイテンシ: QUERY と EXECUTE の 90 パーセンタイルのレイテンシは、すべてのデバイスタイプで 1,000 ミリ秒以下でなければなりません。
  4. 状態の完全性: 状態の精度は 99.5% 以上である必要があります。

これらの指標が重要な理由

  1. グローバル成功率: 統合レベルでのパートナーから Google への呼び出しは、クラウドから Google への呼び出しの健全性を測定します。成功率が 99.5% 以上であれば、Google Home で正しいデバイスの状態が使用されます。たとえば、デバイスの追加と削除、自動化のトリガー、Google Home アプリの [アクティビティ] タブでの履歴イベントの表示などを確認します。
  2. コマンドの信頼性: QUERY と EXECUTE の成功率はデバイスタイプ レベルで測定されます。成功率が 99.5% 以上であれば、ユーザーのコマンドが正しく実行されます（「デバイスにアクセスできません」などのアシスタントの応答や、実行されていないコマンドが誤って確認されることを回避できます）。
  3. 応答性: QUERY と EXECUTE のレイテンシもデバイスタイプ レベルで測定されます。デバイスタイプごとのレイテンシが 1, 000 ミリ秒以下であれば、ユーザーが目的のアクション（ライトが消えるまで数秒待つなど）を実行するまで長く待つ必要はありません。
  4. 状態の完全性: 状態の精度。Google システムに保存され、ユーザーのクエリの処理に使用される状態の精度を測定します。これらの数値が低い場合、ユーザーがデバイスの状態を確認したり、Home に相談などの AI 機能を使用したりしたときに、デバイスの誤った結果が表示されることがあります。自動化が実行されず、履歴エントリが [アクティビティ] に適切なタイミングで表示されないことがあります。

ダッシュボードの読み方

まず、統合の主な健全性指標となる品質スコア指標セクションから始めます。デバイスレベルの「良好」な評価は、このセクションのすべての指標が「緑」の成功基準を満たしていることが条件となります。技術要件と指標の定義について詳しくは、Developer Center のドキュメントをご覧ください。

Google Home Vitals ダッシュボードの上部にある [品質指標スコア] セクションには、統合品質スコアの計算に使用される指標が反映されます。

凡例

  • 緑（良好）: 指標が品質のしきい値を満たしています。
  • 赤（不良）: 指標が品質のしきい値を満たしていません。

例

下の例では、AC_UNIT デバイスタイプが [QUERY Success Rate]、[EXECUTE Success Rate]、[QUERY Latency] の各セクションで品質基準を満たしていますが、[EXECUTE Latency] のバー（赤色）で基準を満たしていないことがわかります。これは、コマンドは合格率で成功しているが、EXECUTE レイテンシが 36 ミリ秒遅すぎることを意味します。[システム健全性] セクションには、統合全体で集計されたメソッドの失敗率が 98.92% と表示されています。これは、Google Home でユーザーのデバイスの状態を正確に把握できるように改善の余地があることを意味します。これは、呼び出し（DeleteAgentUser、Query、ReportStateAndNotification、RequestSyncDevices、Sync）の 1.08% が 2xx または 5xx 以外のレスポンス コード（400 など）を返していることを意味します。404 エラーなど）。AC_UNIT デバイスタイプの合格/不合格の品質を測定するために使用される最後の指標は、状態の精度です。この例では、成功率が 77.43% となっています。これは、ユーザーがデバイスの不正確な結果を目にしている可能性が高いことを意味します。これらの 3 つの指標により、AC_UNIT の総合スコアは「POOR」となり、品質のしきい値を下回ります。

a2c2f3c8d7531fe9.png

これらの品質計算は、以下のデバッグ セクションに対応しています。折りたたまれたステップを開いて、デバッグを続行します。

QUERY/EXECUTE の成功率とレイテンシをデバッグするには、「ステップ 1: クラウド呼び出しを検証する」に進みます。

パートナーから Google への成功率をデバッグするには、「ステップ 2: Google への呼び出しを検証する」に移動します。

各デバイスタイプの状態の精度をデバッグするには、「ステップ 3: 状態の精度を向上させる」に進みます。

a68e651c029391eb.png

31f6a331b86146ed.png

3. デバッグ ステップ 1: クラウド呼び出しを検証する

ステップ 1: 概要

このセクションでは、Cloud Calls（Google からクラウド バックエンドへの通信の健全性を測定する指標。Google-to-Partner 指標とも呼ばれます）に焦点を当てます。これには、Query や Execute などのコマンドが含まれます。

QUERY と EXECUTE の成功率とレイテンシをトラッキングします（これらはデバイスタイプの品質スコアに影響します）。

以下の概要は、統合レベルでの QUERY と EXECUTE の成功率とエラーの集計を示しています。ステップ 1a ～ 1d は、デバイスタイプ/トレイト レベルでのこれらの指標の内訳を示しています。7a79bf5af81226f6.png

ステップ 1a と 1b は、フルフィルメント リクエスト数の推移、エラー数の推移、特定のエラー ステータスを示しています。

ステップ 1a: クエリエラーを確認する

20cd2e1e1114a9df.png 4220b5843d6a2973.png

ステップ 1b: 実行エラーを確認する

79ab571fa31b428f.png

ステップ 1c と 1d では、これらの指標の 90 パーセンタイルと 50 パーセンタイルの内訳も、統合レベルとデバイスタイプ レベルの両方で示しています。

ステップ 1c: クエリ レイテンシを確認する

248735625f9af7cd.png

ステップ 1d: 実行レイテンシを確認する

a71098ac39e06f74.png

4. デバッグ ステップ 2: Google への呼び出しを検証する

ステップ 2: 概要

Google からパートナーへの呼び出しのデバッグに続いて、この 2 番目の手順では、パートナー クラウドから Google への呼び出しのデバッグについて説明します。このセクションでは、デバイスタイプ レベルではなく、パートナー統合レベルの指標について説明します。これには、400 Bad Request、404 Not Found、429 Resource Exhausted などのレスポンス コードが含まれます。

faab83706f20454e.png

ステップ 2a: 割り当ての問題をデバッグする

Google Home では、リソース割り振りを制限し、プロジェクト単位での適切な割り当てを適用しています。Google では、クラウド間統合単位で、クエリ、削除、レポート ステータス、非同期リクエストの同期 API 呼び出しの合計に対し、60 秒あたりのリクエスト数を 6,000 件とするデフォルト上限を適用しています。

割り当ての問題が発生すると、状態の更新が完了せず、不一致が発生する可能性があるため、レポートの状態の精度に悪影響を及ぼす可能性があります。以下は、レポートの状態とリクエストの同期エラー、API メソッド別のカウントとエラーの内訳、割り当て使用率を具体的に示すグラフです。これらのグラフでトラフィックの予期しない増加が示されている場合は、統合を見直して、変更によって Home Graph API に送信されるトラフィックが増加しているかどうかを確認します。

トラフィックが時間の経過とともに自然に増加する場合（デバイス数の増加、新しいデバイスタイプのリリース、その他の想定されるリリースと一致して増加する場合など）は、インテグレーションの割り当てを増やすことが適切な場合があります。割り当ての増加をリクエストするには、デベロッパー向けドキュメントの手順に沿って操作してください。

d3e5629af92bc88d.png

ccd9841590dc0b99.png

5. デバッグ ステップ 3: 状態の精度を向上させる

ステップ 3: 概要

ステップ 1 とステップ 2 の両方のデバッグが完了したら、ステップ 3 では Report State の精度について説明します。これは、ユーザーのクエリの処理に使用される Google システムに保存されているデバイスのステータスです。トレイトとデバイスタイプ別の内訳は以下のとおりです。ステップ 3a と 3b では、Report State の 2 つの一般的なエラー（Missing Field エラーと Inaccurate エラー）について説明します。

9b37adcb554944f3.png

ステップ 3a: 「Missing Field」エラー

「Missing Field」エラーは、特定のデバイスの QUERY レスポンスと報告された状態リクエストの間でペイロード フィールドのセットが異なる場合に発生します。各デバイスのペイロード内のフィールドのセットは同じである必要があります。これは、ペイロードを計算するロジックが QUERY とレポート状態のレスポンスで異なる場合に発生することがあります。以下のグラフを使用して、QUERY とレポートの状態レスポンスが一致しないデバイスタイプとトレイトを特定します。

a25f04014cc3c7bc.png

316b294e168e8bc9.png

ステップ 3b: 「不正確」エラー

不正確なエラーは、特定のデバイスの QUERY レスポンスと報告された状態リクエストの間でペイロード フィールドのセットが同じであるにもかかわらず、状態の値が異なる場合に発生します。これは、状態レポートが欠落している場合や、状態を計算するロジックが QUERY と状態レポートで異なる場合に発生する可能性があります。以下のグラフを使用して、QUERY とレポートの状態レスポンスが一致しないデバイスタイプとトレイトを特定します。

b6fd9f6ee31a7bb7.png

d84829cca22b1b20.png

6. その他のドキュメントとリソース

  • このダッシュボードに関するフィードバックを送信したり、問題を報告したりするには、公開の Issue Tracker で問題を報告してください。
  • 再審査請求を送信するには、品質スコアの再審査請求フォームを使用して問題を送信します。
  • 統合の品質を定期的に把握するには、指標が許容可能なしきい値を下回ったときに通知を受け取るように Google Cloud Platform アラートを構成します。これにより、問題が発生したときにいち早く通知を受け取ることができます。
  • その他の情報については、デベロッパー向けドキュメント（https://developers.home.google.com/tools/analytics/home-vitals）をご覧ください。