Google Home Vitals (Cloud)

Serangkaian dasbor dan pemberitahuan ini membantu Anda mempertahankan integrasi berkualitas tinggi dengan ekosistem Google Home secara proaktif. Google berkomitmen untuk mendukung partner dalam mengembangkan ekosistem berkualitas tinggi bagi semua pelanggan.

Dasbor ini memiliki tiga bagian, yang masing-masing mencakup bagian penting yang berkontribusi pada kualitas integrasi secara keseluruhan.

1. Metrik Google ke Partner - Mengukur kondisi panggilan dari Google ke backend cloud Anda.

2. Kondisi Sistem - Metrik Partner ke Google - Mengukur kondisi panggilan dari sistem Anda ke Google.

3. Kondisi Perangkat - Akurasi Status - Mengukur akurasi status yang disimpan dalam sistem Google, yang digunakan untuk menayangkan kueri pengguna.

Jika metrik tidak memenuhi nilai targetnya, metrik tersebut akan ditandai dengan warna merah untuk menunjukkan masalah yang dapat memengaruhi pengalaman pengguna. Informasi berikut memberikan detail tentang setiap target dan alasan target tersebut penting bagi pengguna Anda.

Jika tombol berikut tidak mengarahkan Anda langsung ke dasbor, Anda dapat mengaksesnya dengan memilih halaman Ringkasan , memilih Dasbor , lalu dari daftar Dasbor Saya , pilih Dasbor Vitalitas Google Home (Cloud) untuk melihat dasbor Anda.

Buka Dasbor

Metrik Google ke Partner

Metrik Tingkat Keberhasilan Kueri/Eksekusi >= 99,5% mengukur frekuensi perintah pengguna dipenuhi dengan benar, yang membantu menghindari respons Asisten seperti "Saya tidak dapat menghubungi perangkat" atau mengonfirmasi perintah yang belum dipenuhi dengan tidak benar.

Apa yang menentukan "Keberhasilan"?

Transaksi ditandai sebagai berhasil jika platform Google Home menerima respons yang valid yang menunjukkan bahwa tindakan yang dimaksud telah dipenuhi atau status yang diminta telah diambil.

Respons yang menyertakan pengecualian non-pemblokiran (misalnya, status SUCCESS yang disertai dengan pengecualian lowBattery) dihitung sebagai transaksi yang berhasil. Perintah berhasil mencapai perangkat dan intent terpenuhi meskipun ada peringatan.

Apa yang menentukan "Kegagalan"?

Error yang ditemukan di Kode error platform umum yang ditandai sebagai Tindakan yang Dapat Dilakukan Partner dianggap sebagai "Kegagalan" saat menghitung Tingkat Keberhasilan QUERY dan EXECUTE. Selain itu, error yang ditemukan di Error dan pengecualian juga merupakan "Kegagalan", dengan pengecualian berikut:

Metrik Latensi Kueri/Eksekusi (p90) <= 1000 md mengukur waktu tunggu tindakan yang diminta dan membantu memastikan pengguna tidak perlu menunggu terlalu lama, misalnya, menunggu beberapa detik agar lampu mereka mati.

Metrik latensi

Latensi adalah indikator penting tentang seberapa responsif integrasi Anda bagi pengguna akhir. Dasbor melacak Latensi Persentil ke-90 (P90), yang mewakili pengalaman pengguna "paling lambat" (misalnya, P90 sebesar 800 md berarti 90% permintaan diakui dalam waktu 800 md atau kurang).

Google mengukur latensi secara berbeda untuk pemeriksaan status dan perintah perangkat guna memastikan akurasi teknis.

1. Latensi QUERY (Interogatif)

Metrik ini mengukur waktu pulang pergi Cloud-to-cloud saat Google meminta status perangkat saat ini.

• Mulai: Google mengirimkan permintaan action.devices.QUERY ke URL pemenuhan Anda.
• Jendela Pengukuran: Waktu yang diperlukan cloud Anda untuk menerima, memproses, dan mengirimkan respons HTTP lengkap kembali ke Google.
• Akhir: Google menerima dan mengakui payload respons akhir dari layanan Anda.

2. Latensi EXECUTE (Tindakan)

Metrik ini mengukur waktu pengakuan perintah saat Google mengirimkan permintaan kontrol ke perangkat.

• Mulai: Google mengirimkan permintaan action.devices.EXECUTE ke URL pemenuhan Anda.
• Jendela Pengukuran: Waktu yang diperlukan cloud Anda untuk menerima perintah dan menampilkan respons pengakuan.
• Akhir: Google menerima respons status SUCCESS, PENDING, atau OFFLINE.
• Cakupan Teknis: Metrik ini mengukur waktu "Pengakuan Respons" antara cloud Google dan cloud Anda. Metrik ini tidak mengukur waktu yang diperlukan hardware fisik (misalnya, bola lampu) untuk menyelesaikan perubahan status fisik, karena sering kali melibatkan latensi jaringan mesh lokal di luar jalur cloud-to-cloud.

Perincian linimasa latensi EXECUTE/QUERY

Saat menganalisis stempel waktu untuk latensi EXECUTE atau QUERY, total waktu pulang pergi dapat dipecah menjadi alur berurutan berikut:

Karena perincian ini membandingkan stempel waktu sisi Google dan sisi Partner, server Partner harus disinkronkan dengan NTP (Network Time Protocol). Bahkan, penyimpangan jam kecil (50-100 md) akan mendistorsi waktu transit yang dihitung (t2 - t1 dan t4 - t3), yang berpotensi menyebabkan metrik yang secara logis tidak mungkin seperti latensi transit negatif.

[t1] Permintaan Dikirim (Google Keluar): Google memulai permintaan intent. Karena t1 tidak diekspos secara langsung, t1 diperkirakan dihitung dengan mengurangi total latensi dari stempel waktu masuk akhir.

Transit Jaringan (t1 ke t2): Perkiraan waktu transit dan antrean jaringan sebelum mencapai endpoint pemenuhan Anda.

[t2] Permintaan Diterima (Google Masuk): Stempel waktu yang tepat saat permintaan tiba di gateway API atau server masuk lingkungan Anda.

Pemrosesan Partner (t2 ke t3): Latensi eksekusi, perutean, dan penanganan perangkat internal sepenuhnya dalam lingkungan cloud Anda.

[t3] Respons Dikirim (Google Keluar): Stempel waktu saat layanan Anda mengirimkan respons pemenuhan kembali ke Google.

Transit Kembali (t3 ke t4): Waktu perutean jaringan kembali dan penyelesaian koneksi kembali ke Google.

[t4] Permintaan Diselesaikan (Google Masuk): Google menerima dan memproses respons akhir. Stempel waktu ini dicatat secara eksplisit dalam log Anda sebagai receiveTimestamp.Google Cloud

Untuk mengilustrasikan cara metrik ini terhubung, pertimbangkan contoh EXECUTE permintaan dengan total latensi yang dicatat (latencyMsec) sebesar 1700 md dan Google Cloud receiveTimestamp (t4) sebesar 2026-05-25T15:25:00.550Z.

Opsi pengurangan latensi

Rekomendasi arsitektur untuk perutean geografis

Jika penerapan IP Anycast tidak memungkinkan, sebaiknya gunakan alternatif hemat biaya berikut untuk memastikan pengguna dilayani oleh pusat data regional terdekat.

1. Load Balancing Global (GLB)

   Daripada perutean statis, gunakan Load Balancer Aplikasi Global (tersedia dari sebagian besar penyedia cloud utama).

   • Cara kerjanya: Anda mengonfigurasi satu titik entri global (URL) yang berada di tepi jaringan. Load balancer otomatis mendeteksi asal geografis permintaan dari cluster pemenuhan Google dan merutekan traffic ke backend responsif regional terdekat.

   • Manfaat: Hal ini memberikan performa Anycast dengan kompleksitas dan biaya konfigurasi yang jauh lebih rendah.

2. DNS yang Mendeteksi Lokasi Geografis (GeoDNS)

   • Cara kerjanya: Konfigurasikan penyedia DNS Anda untuk me-resolve URL pemenuhan Anda ke alamat IP yang berbeda berdasarkan lokasi geografis kueri DNS.

   • Implementasi: Pastikan penyedia DNS Anda dioptimalkan untuk titik keluar Google. Saat layanan pemenuhan regional Google (misalnya, di AS, Uni Eropa, atau Asia) me-resolve domain Anda, layanan tersebut akan menerima alamat IP untuk pusat data di wilayah tertentu.

Strategi pengoptimalan di lapisan aplikasi

Selain perutean tingkat infrastruktur, Anda dapat menerapkan strategi berikut di lapisan aplikasi untuk mengurangi latensi dalam pemrosesan permintaan.

1. Metode Proxy "Trampoline"

   Jika Anda harus mempertahankan pusat data utama, gunakan server proxy regional ringan (Trampoline) untuk menangani handshake awal.

   1. Google mengakses URL global Anda.

   2. Proxy regional (misalnya, fungsi Nginx atau Lambda ringan) menerima permintaan.

   3. Proxy meneruskan payload melalui backbone internal berkecepatan tinggi ke database utama.

   Manfaat: Hal ini mengurangi waktu "TCP Handshake", yang sering kali menjadi kontributor terbesar latensi untuk permintaan jarak jauh.

2. Petunjuk Region Token Akses

   Selama proses Penautan Akun (OAuth), sistem Anda dapat mengidentifikasi wilayah asal pengguna.

   Implementasi: Enkode ID region ke dalam access_token yang dikeluarkan ke Google. Saat Google mengirimkan permintaan pemenuhan, gateway Anda dapat langsung memeriksa token dan merutekan permintaan ke cluster regional yang benar tanpa memerlukan pencarian database.

Kondisi Sistem - Metrik Partner ke Google

Mempertahankan Tingkat Keberhasilan >= 99,5% membantu memastikan status perangkat benar di Google Home, perangkat ditambahkan dan dihapus, otomatisasi dipicu, dan peristiwa histori muncul di tab Aktivitas Google Home app (GHA).

Tingkat Keberhasilan dihitung berdasarkan kode respons HTTP yang ditampilkan oleh Google saat cloud Anda mengirimkan update status. Untuk memastikan partner tidak dihukum karena masalah infrastruktur sisi Google, metrik ini mengecualikan error internal Google dari jumlah kegagalan. Panggilan API yang disertakan dalam penghitungan dapat ditemukan di referensi HomeGraph API.

Apa yang menentukan "Keberhasilan"?

2xx (Berhasil): Update status berhasil diterima dan diproses oleh Home Graph.

Apa yang menentukan "Kegagalan"?

4xx (Error Partner) menunjukkan kegagalan dan menunjukkan masalah pada permintaan yang dikirim dari cloud Anda. Kode umum mencakup:

400 Bad Request (400 Permintaan Tidak Valid)

Penyebab: Server tidak dapat memproses permintaan karena sintaksis tidak valid. Penyebab umum mencakup JSON yang salah format atau menggunakan null, bukan "" untuk nilai string.

Solusi: Pastikan isi permintaan adalah JSON yang valid (tidak ada struktur yang salah format atau nilai null untuk kolom string), dan pastikan agentUserId cocok dengan nilai dari respons SYNC.

404 Not Found (404 Tidak Ditemukan)

Penyebab: deviceId atau agentUserId tidak ditemukan di HomeGraph (belum disinkronkan, sudah tidak ditautkan, atau ID tidak cocok).

Solusi:

1. Pastikan agentUserId cocok dengan nilai yang diberikan dalam respons SYNC Anda.
2. Gunakan Home Graph SYNC API untuk menentukan apakah error 404 Not Found disebabkan oleh perangkat atau pengguna yang tidak ada di HomeGraph.
3. Pastikan untuk memicu requestSync setelah perangkat atau akun ditambahkan, dihapus, diganti namanya, atau diperbarui untuk memastikan status tetap terbaru.
4. Tangani intent DISCONNECT dengan benar untuk berhenti melaporkan perangkat yang tidak aktif. Setelah menerima intent DISCONNECT, layanan cloud Anda harus berhenti memublikasikan perubahan ke Google dengan Request Sync dan Report State.

429 Resource Exhausted (429 Resource Habis)

Penyebab: Integrasi Anda telah melampaui kuota yang dialokasikan.

Solusi: Lihat petunjuk di bagian "Langkah 2a: Men-debug Masalah Kuota" di dasbor untuk pengelolaan kuota. Anda juga dapat melihat Kuota dan batas Smart Home untuk mengetahui informasi selengkapnya.

Kondisi Perangkat - Akurasi status

Memenuhi atau melampaui Akurasi Status >= 99,5% membantu memastikan pengguna melihat hasil yang benar saat mereka melihat status perangkat atau menggunakan fitur AI seperti Ask Home. Jika akurasi status rendah, otomatisasi mungkin tidak akan dipicu dan entri histori mungkin tidak akan muncul di tab Aktivitas GHA pada waktu yang tepat. Untuk mengetahui informasi selengkapnya, lihat Report State. Perhatikan: Target Akurasi Status harus dipenuhi di SEMUA kemampuan yang didukung.

1. Komponen Akurasi

Metrik ini berasal dari "contoh" tempat Google dapat memverifikasi status yang dilaporkan terhadap hasil intent yang diketahui. Untuk presisi teknis, akurasi dievaluasi di dua jalur yang berbeda:

• Akurasi berbasis QUERY: Diverifikasi saat pengguna atau sistem secara aktif menginterogasi status perangkat saat ini.
• Akurasi berbasis EXECUTE: Diverifikasi dengan mengevaluasi status perangkat pasca-perintah yang dilaporkan kembali setelah permintaan kontrol.

2. Metrik Dasbor (Penghitungan Per Jam)

Dasbor menghitung akurasi berdasarkan interval 1 jam. Untuk memastikan kepercayaan statistik dan menghindari integrasi yang dihukum karena noise sinyal rendah, Google menerapkan nilai minimum volume traffic. Jika kombinasi kemampuan dan perangkat tertentu mengumpulkan kurang dari 100 total contoh selama periode 5 hari, akurasinya dianggap tidak signifikan secara statistik dan ditetapkan ke T/A.

Jika satu jam memiliki volume contoh yang cukup di kedua jalur, akurasi per jam dasar untuk status tertentu dihitung sebagai rata-rata dari dua persentase independen:

Akurasi Status Per Jam = (Akurasi Kueri % + Akurasi Eksekusi %) / 2

Dengan setiap jalur ditentukan sebagai:

• Akurasi Kueri % = (Contoh Akurat Kueri Per Jam) / (Total Contoh Kueri Per Jam)
• Akurasi Eksekusi % = (Contoh Akurat Eksekusi Per Jam) / (Total Contoh Eksekusi Per Jam)

Skor Akurasi Kemampuan (dihitung per kemampuan) = SUM(Contoh Akurat Kueri + Contoh Akurat Eksekusi) / SUM(Total Contoh Kueri + Total Contoh Eksekusi)

Karena Skor Kualitas mengevaluasi performa minimum yang ketat di seluruh ekosistem Anda, setiap kemampuan yang didukung dan memenuhi syarat harus memenuhi target Akurasi Status >= 99,5% secara individual (ini bukan rata-rata di seluruh kemampuan).

Tampilan ini mencegah perangkat bervolume tinggi dengan akurasi yang sangat baik menutupi masalah akurasi pada perangkat bervolume rendah. Partner yang khawatir kemampuan yang kurang dimanfaatkan akan menurunkan skor mereka dapat yakin bahwa kemampuan yang jarang digunakan akan otomatis dilindungi oleh pemeriksaan volume traffic minimum dan tidak akan diperhitungkan ke dalam skor Jenis dan Kemampuan Terendah kecuali jika memenuhi nilai minimum contoh yang diperlukan.

3. Meningkatkan Kondisi Perangkat &Akurasi Status

Perbedaan terjadi saat status yang disimpan di Home Graph tidak cocok dengan hasil QUERY real time.

Error "Kolom Tidak Ada"

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD"
    deviceId: "curtain"
    deviceType: "action.devices.types.CURTAIN"
    isMissingField: true
    isOffline: false
    queriedTime: "2026-04-13T12:20:26Z"
    queryReportStateDifferences: {
      queryState: "open_close    {
        open_percent: 0.0
        missing open_direction
      }"
      reportState: "open_close   {
        open_state {
          open_percent: 100.0
          open_direction: "LEFT"
        }
      }"
    }
    reportedTime: "2022-05-13T07:14:35Z"
    requestId: "123"
    result: "INACCURATE"
    snapshotTime: "2026-04-13T12:20:26Z"
    stateName: "open_state"
    traitName: "TRAIT_OPEN_CLOSE"
  }
  

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD"
    deviceId: "sensor"
    deviceType: "action.devices.types.SENSOR"
    isMissingField: true
    isOffline: false
    queriedTime: "2026-04-28T10:40:33Z"
    queryReportStateDifferences: {
      queryState: "temperature_setting {
         thermostat_mode: "off"
         thermostat_temperature_ambient: 20.0
         active_thermostat_mode: "none"
      }"
      reportState: "temperature_setting {
         thermostat_mode: "off"
         active_thermostat_mode: "none"
      }"
    }
    reportedTime: "2024-09-20T15:00:00Z"
    requestId: "123"
    result: "INACCURATE"
    snapshotTime: "2026-04-28T10:40:33Z"
    stateName: "thermostat_temperature_ambient"
    traitName: "TRAIT_TEMPERATURE_SETTING"
  }
  

Penyebab: Dengan error DETAILED_ACCURACY_RESULT_QUERY_STATE_MISSING_FIELD atau DETAILED_ACCURACY_RESULT_REPORT_STATE_MISSING_FIELD, kumpulan kolom payload berbeda antara respons QUERY dan permintaan Report State untuk perangkat yang sama.

Solusi: Pastikan struktur data identik di kedua jalur. Jika kemampuan disertakan dalam SYNC, kolom yang sesuai harus ada dan konsisten dalam laporan proaktif dan kueri reaktif.

Error "Tidak Akurat"

reportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_INACCURATE"
    deviceId: "outlet"
    deviceType: "action.devices.types.OUTLET"
    isMissingField: false
    isOffline: false
    queriedTime: "2026-04-12T16:02:58Z"
    queryReportStateDifferences: {
      queryState: "on_off    {
        on: false
      }"
      reportState: "on_off   {
        on: true
      }"
    }
    reportedTime: "2025-03-10T01:56:44Z"
    requestId: "abc"
    result: "INACCURATE"
    snapshotTime: "2026-04-12T16:02:58Z"
    stateName: "on"
    traitName: "TRAIT_ON_OFF"
  }
  

Penyebab: Untuk error DETAILED_ACCURACY_RESULT_INACCURATE, ada perbedaan antara nilai yang ditampilkan dalam respons QUERY dan nilai Report State terakhir.

Solusi: Pastikan Report State dipicu setiap kali status perangkat berubah dan Report State serta QUERY selalu memberikan nilai yang sama persis dan terbaru serta semua kolom yang diperlukan untuk mempertahankan konsistensi data.

"reportStateLog": {
   "isMissingField": false,
   "snapshotTime": "2026-04-13T07:56:21Z",
   "traitName": "TRAIT_ON_OFF",
   "detailedAccuracyResult": "DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE",
   "executionReportStateDifferences": {
      "expectedPostExecutionDeviceState": {
         "onOff": {
         "on": false
         }
      },
      "preExecutionDeviceState": {
         "onOff": {
         "on": true
         }
      },
      "executionCommand": {
         "requestId": "test001",
         "beginTimestamp": "2026-04-13T07:56:20Z",
         "action": {
         "trait": "TRAIT_ON_OFF",
         "actionType": "ONOFF_OFF"
         },
         "status": {
         "statusType": "SUCCESS_STATUS"
         },
         "endTimestamp": "2026-04-13T07:56:21Z",
         "executionType": "PARTNER_CLOUD"
      },
      "reportState": {}
   },
   "accuracy": "MISSING_REPORT_STATE",
   "deviceType": "action.devices.types.LIGHT",
   "agentId": "abc",
   "stateName": "on",
   "result": "MISSING_REPORT_STATE"
   }
  

Penyebab: Dengan error DETAILED_ACCURACY_RESULT_MISSING_REPORT_STATE, partner berhasil menjalankan perintah, tetapi tidak melaporkan status perangkat yang diperbarui kembali ke Google.

Solusi: Selalu kirim update Report State setelah eksekusi perintah sehingga Home Graph menerima status perangkat baru.

eportStateLog: {
    accuracy: "INACCURATE"
    agentId: "abc"
    detailedAccuracyResult: "DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED"
    deviceId: "switch"
    deviceType: "action.devices.types.SWITCH"
    isMissingField: false
    isOffline: true
    queriedTime: "2026-04-13T13:53:26Z"
    queryReportStateDifferences: {
      queryState: "online    {
        online: false
      }
      "
      reportState: ""
    }
    reportedTime: "1970-01-01T00:00:00Z"
    requestId: "test001"
    result: "INACCURATE"
    snapshotTime: "2026-04-13T13:53:26Z"
    stateName: "online"
    traitName: "TRAIT_ONLINE"
   }
  

Penyebab: Untuk error DETAILED_ACCURACY_RESULT_NO_STATE_REPORTED, tidak ada Report State yang diterima untuk perangkat ini (status kosong dan stempel waktu yang dilaporkan berada di epoch), meskipun hasil QUERY memberikan status saat ini. Hal ini menunjukkan bahwa update status tidak dipicu, gagal mencapai HomeGraph, atau perangkat tidak berhasil melaporkan transisi dalam konektivitas atau status operasinya.

Solusi: Pastikan Report State dipicu dan berhasil dikirim untuk semua perubahan status. Pastikan logika backend menangani update status dengan benar, mengonfirmasi keberhasilan pengiriman ke Google HomeGraph, dan memastikan perangkat secara konsisten menyinkronkan statusnya untuk menjaga akurasi antarmuka pengguna dan mesin otomatisasi.