Google Home Vitals (Cloud)

Rangkaian dasbor dan pemberitahuan ini membantu Anda secara proaktif mempertahankan integrasi berkualitas tinggi dengan ekosistem Google Home. 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. System Health - Partner to Google Metrics - Mengukur kondisi panggilan dari sistem Anda ke Google.

3. Kesehatan Perangkat - Akurasi Status - Mengukur akurasi status yang disimpan dalam sistem Google, yang digunakan untuk menyajikan 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 pentingnya bagi pengguna Anda.

Jika tombol berikut tidak mengarahkan Anda langsung ke dasbor, Anda dapat mengaksesnya dengan memilih halaman Overview, memilih Dashboards, lalu dari daftar My Dashboards, pilih Google Home Vitals Dashboard (Cloud) untuk melihat dasbor Anda.

Buka Dasbor

Metrik Google untuk Partner

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

Metrik Rasio Keberhasilan Sinkronisasi >= 99,5% mengukur seberapa sering permintaan sinkronisasi dipenuhi dengan benar, yang memastikan bahwa perangkat yang ditampilkan di Google Home disinkronkan dengan perangkat yang terhubung ke infrastruktur cloud Anda.

Apa yang menentukan "Keberhasilan"?

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

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

Apa yang dimaksud dengan "Kegagalan"?

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

Paritas Status Respons Eksekusi

Saat menampilkan status SUCCESS dalam respons EXECUTE, objek states payload respons Anda harus berisi semua kolom status aktif dan yang diperbarui yang ditentukan oleh karakteristik yang Anda jalankan. Menghilangkan kolom status yang diperlukan, atau menampilkan objek states kosong untuk karakteristik kompleks, akan menyebabkan Google Home Platform gagal mengurai hasil eksekusi, mendaftarkannya sebagai kegagalan AGENT_ISSUE atau INVALID_RESPONSE yang menurunkan Rasio Keberhasilan Kueri dan Eksekusi Anda.

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 hingga lampu mati.

Metrik latensi

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

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

1. Latensi KUERI (Interogatif)

Metrik ini mengukur waktu round-trip Cloud-to-cloud saat Google meminta status perangkat saat ini.

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

2. Latensi EXECUTE (Tindakan)

Metrik ini mengukur waktu konfirmasi perintah saat Google mengirim permintaan kontrol ke perangkat.

• Mulai: Google mengirimkan permintaan action.devices.EXECUTE ke URL fulfillment Anda.
• Jendela Pengukuran: Waktu yang diperlukan cloud Anda untuk menerima perintah dan menampilkan respons konfirmasi.
• Akhir: Google menerima respons status SUCCESS, PENDING, atau OFFLINE.
• Cakupan Teknis: Metrik ini mengukur waktu "Konfirmasi Respons" antara cloud Google dan cloud Anda. Metrik ini tidak mengukur waktu yang diperlukan hardware fisik (misalnya, bohlam) untuk menyelesaikan perubahan status fisik, karena hal itu 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 round-trip dapat diuraikan menjadi alur berurutan berikut:

Karena perincian ini membandingkan stempel waktu sisi Google dan sisi Partner, server Partner harus disinkronkan dengan Protokol Waktu Jaringan (NTP). Penyimpangan jam yang kecil sekalipun (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 Outbound): Google memulai permintaan intent. Karena t1 tidak ditampilkan secara langsung, nilai ini dihitung secara perkiraan dengan mengurangi total latensi dari stempel waktu masuk akhir.

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

Permintaan [t2] Diterima (Ingress Partner): Stempel waktu yang tepat saat permintaan tiba di gateway API atau server ingress lingkungan Anda.

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

[t3] Respons Terkirim (Egress Partner): Stempel waktu saat layanan Anda mengirimkan respons fulfillment kembali ke Google.

Transit Pengembalian (t3 ke t4): Waktu penyelesaian koneksi dan pemilihan rute jaringan pengembalian kembali ke Google.

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

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

Opsi pengurangan latensi

Rekomendasi arsitektur untuk pemilihan rute 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)

   Alih-alih pemilihan rute 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 edge jaringan. Load balancer secara otomatis mendeteksi asal geografis permintaan dari cluster fulfillment Google dan merutekan traffic ke backend responsif regional terdekat.

   • Manfaat: Memberikan performa Anycast dengan kompleksitas konfigurasi dan biaya yang jauh lebih rendah.

2. DNS yang Memperhitungkan Geolokasi (GeoDNS)

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

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

Strategi pengoptimalan di lapisan aplikasi

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

1. Metode Proxy "Trampoline"

   Jika Anda harus mengelola pusat data utama, gunakan server proxy ringan regional (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 terhadap 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 wilayah ke dalam access_token yang diterbitkan ke Google. Saat Google mengirimkan permintaan fulfillment, gateway Anda dapat segera memeriksa token dan merutekan permintaan ke cluster regional yang benar tanpa perlu melakukan pencarian database.

Kesehatan Sistem - Metrik Partner ke Google

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

Rasio Keberhasilan dihitung berdasarkan kode respons HTTP yang ditampilkan oleh Google saat cloud Anda mengirimkan update status. Untuk memastikan partner tidak dihukum karena masalah infrastruktur di 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): Pembaruan status berhasil diterima dan diproses oleh Home Graph.

Apa yang dimaksud dengan "Kegagalan"?

4xx (Error Partner) menunjukkan kegagalan dan 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 umumnya 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 verifikasi bahwa agentUserId cocok dengan nilai dari respons SYNC.

404 Tidak Ditemukan

Penyebab: deviceId atau agentUserId tidak ditemukan di HomeGraph (belum disinkronkan, sudah dibatalkan tautannya, 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 penambahan, penghapusan, penggantian nama, atau pembaruan perangkat atau akun untuk memastikan statusnya tetap terbaru.
4. Tangani intent DISCONNECT dengan benar untuk berhenti melaporkan perangkat yang tidak berlaku. Setelah menerima intent DISCONNECT, layanan cloud Anda harus berhenti memublikasikan perubahan ke Google dengan Minta Sinkronisasi dan Laporkan Status.

429 Resource Exhausted

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.

Kesehatan 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 Tanya Home. Jika akurasi status rendah, otomatisasi mungkin tidak diaktifkan dan entri histori mungkin tidak muncul di tab Aktivitas GHA pada waktu yang tepat. Untuk mengetahui informasi selengkapnya, lihat Melaporkan Status. Harap diperhatikan: Target Akurasi Status harus dipenuhi di SEMUA karakteristik yang didukung.

1. Komponen Akurasi

Metrik ini berasal dari "sampel" yang memungkinkan Google memverifikasi status yang dilaporkan terhadap hasil niat yang diketahui. Untuk presisi teknis, akurasi dievaluasi melalui dua jalur yang berbeda:

• Akurasi berbasis KUERI: 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 keyakinan statistik dan menghindari penalti integrasi pada derau sinyal rendah, Google menerapkan minimum traffic volume threshold. Jika kombinasi karakteristik dan perangkat tertentu mengumpulkan kurang dari 100 total sampel selama periode 5 hari, akurasinya dianggap tidak signifikan secara statistik dan ditetapkan ke T/A.

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

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

Dengan setiap jalur didefinisikan sebagai:

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

Skor Akurasi Karakteristik (dihitung per karakteristik) = SUM(Query Accurate Samples + Execution Accurate Samples) / SUM(Query Total Samples + Execution Total Samples)

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

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

3. Meningkatkan Akurasi Status & Kesehatan Perangkat

Perbedaan terjadi jika 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 sama di kedua jalur. Jika suatu trait 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 Status Laporan 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 menjaga 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 agar 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 Status Laporan yang diterima untuk perangkat ini (statusnya 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 menjangkau HomeGraph, atau perangkat tidak berhasil melaporkan transisi dalam status konektivitas atau operasionalnya.

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 menyinkronkan statusnya secara konsisten untuk menjaga antarmuka pengguna dan mesin otomatisasi tetap akurat.