Diese Suite aus Dashboards und Benachrichtigungen hilft Ihnen, proaktiv eine hochwertige Integration in das Google Home-Ökosystem aufrechtzuerhalten. Google möchte Partner dabei unterstützen, ein hochwertiges Ökosystem für alle Kunden zu entwickeln.
Das Dashboard besteht aus drei Abschnitten, die jeweils einen wichtigen Teil abdecken, der zur Qualität einer Gesamtintegration beiträgt.
Messwerte von Google an Partner : Misst den Status von Aufrufen von Google an Ihr Cloud-Backend.
Systemstatus – Messwerte von Partner an Google : Misst den Status von Aufrufen von Ihrem System an Google.
Gerätestatus – Statusgenauigkeit : Misst die Genauigkeit von Status, die in Google-Systemen gespeichert sind und zum Beantworten von Nutzeranfragen verwendet werden.
Wenn Messwerte ihre Zielwerte nicht erreichen, werden sie rot hervorgehoben, um auf ein Problem hinzuweisen, das sich auf die Nutzerfreundlichkeit auswirken könnte. Im Folgenden finden Sie Details zu den einzelnen Zielen und warum sie für Ihre Nutzer wichtig sind.
Wenn Sie über die folgende Schaltfläche nicht direkt zum Dashboard gelangen, können Sie es aufrufen, indem Sie die Seite Übersicht auswählen, Dashboards und dann in der Liste Meine Dashboards die Option Google Home Vitals Dashboard (Cloud) auswählen.
Messwerte von Google an Partner
Mit dem Messwert Erfolgsrate für Abfragen/Ausführungen >= 99,5% wird gemessen, wie oft Nutzerbefehle korrekt ausgeführt werden.So können Assistant-Antworten wie „Ich kann das Gerät nicht erreichen“ oder die falsche Bestätigung eines nicht ausgeführten Befehls vermieden werden.
Was ist ein „Erfolg“?
Eine Transaktion wird als Erfolg gewertet, wenn die Google Home-Plattform eine gültige Antwort erhält, die angibt, dass die beabsichtigte Aktion ausgeführt oder der angeforderte Status abgerufen wurde.
Antworten, die nicht blockierende Ausnahmen enthalten (z. B. ein SUCCESS-Status mit einer lowBattery-Ausnahme), werden als erfolgreiche Transaktionen gezählt.
Der Befehl hat das Gerät erreicht und der Intent wurde trotz der Warnung erfüllt.
Was ist ein „Fehler“?
Die Fehler, die unter Häufige Plattformfehlercodes aufgeführt und als Partner Actionable gekennzeichnet sind, werden bei der Berechnung der Erfolgsraten für QUERY und EXECUTE als „Fehler“ gewertet. Außerdem sind die Fehler unter Fehler und Ausnahmen ebenfalls „Fehler“, mit den folgenden Ausnahmen:
| Ausnahmen bei Fehlern | ||
|---|---|---|
| aboveMaximumLightEffectsDuration | armLevelNeeded | inOffMode |
| alreadyArmed | bagFull | lockedToRange |
| alreadyAtMax | belowMinimumLightEffectsDuration | lowBattery |
| alreadyAtMin | binFull | maxSpeedReached |
| alreadyClosed | cancelArmingRestricted | minSpeedReached |
| alreadyDisarmed | deadBattery | notSupported |
| alreadyDocked | degreesOutOfRange | offline |
| alreadyInState | deviceJammingDetected | percentOutOfRange |
| alreadyLocked | deviceNotMounted | rangeTooClose |
| alreadyOff | deviceNotReady | remoteSetDisabled |
| alreadyOn | deviceOffline | safetyShutOff |
| alreadyOpen | deviceTurnedOff | targetAlreadyReached |
| alreadyPaused | discreteOnlyOpenClose | tooManyFailedAttempts |
| alreadyStarted | functionNotSupported | valueOutOfRange |
| alreadyStopped | inAutoMode | |
| alreadyUnlocked | inEcoMode |
Mit dem Messwert Latenz für Abfragen/Ausführungen (90. Perzentil) <= 1.000 ms wird die Wartezeit für angeforderte Aktionen gemessen. So wird sichergestellt, dass Nutzer nicht zu lange warten müssen, z. B. einige Sekunden, bis das Licht ausgeschaltet wird.
Latenzmesswerte
Die Latenz ist ein wichtiger Indikator dafür, wie schnell Ihre Integration für den Endnutzer reagiert. Im Dashboard wird die Latenz des 90. Perzentils (P90) erfasst, die die Erfahrung Ihrer „langsamsten“ Nutzer darstellt. Ein P90 von 800 ms bedeutet beispielsweise, dass 90% der Anfragen in 800 ms oder weniger bestätigt werden.
Google misst die Latenz für Statusprüfungen und Gerätebefehle unterschiedlich, um die technische Genauigkeit zu gewährleisten.
1. QUERY-Latenz (Abfrage)
Hier wird die Cloud-to-cloud Round-Trip-Zeit gemessen, wenn Google den aktuellen Status eines Geräts abfragt.
- Start: Google sendet eine
action.devices.QUERY-Anfrage an Ihre Fulfillment-URL. - Messzeitraum: Die Zeit, die Ihre Cloud benötigt, um die vollständige HTTP-Antwort zu empfangen, zu verarbeiten und an Google zurückzusenden.
- Ende: Google empfängt und bestätigt die endgültige Antwortnutzlast von Ihrem Dienst.
2. EXECUTE-Latenz (Aktion)
Hier wird die Zeit für die Befehlsbestätigung gemessen, wenn Google eine Steuerungsanfrage an ein Gerät sendet.
- Start: Google sendet eine
action.devices.EXECUTE-Anfrage an Ihre Fulfillment-URL. - Messzeitraum: Die Zeit, die Ihre Cloud benötigt, um den Befehl zu empfangen und eine Bestätigungsantwort zurückzugeben.
- Ende: Google empfängt die Statusantwort
SUCCESS,PENDINGoderOFFLINE. - Technischer Umfang: Mit diesem Messwert wird die Zeit für die Bestätigung der Antwort zwischen der Google-Cloud und Ihrer Cloud gemessen. Die Zeit, die die physische Hardware (z. B. eine Glühbirne) benötigt, um die physische Statusänderung abzuschließen, wird nicht gemessen, da dies oft die Latenz des lokalen Mesh-Netzwerks außerhalb des Cloud-to-Cloud-Pfads beinhaltet.
Optionen zur Reduzierung der Latenz
Architektonische Empfehlungen für das geografische Routing
Wenn die Anycast-IP-Implementierung nicht möglich ist, empfehlen wir die folgenden kostengünstigen Alternativen, um sicherzustellen, dass Nutzer vom nächstgelegenen regionalen Rechenzentrum bedient werden.
Globales Load-Balancing (GLB)
Verwenden Sie anstelle des statischen Routings einen globalen Application Load Balancer (verfügbar bei den meisten großen Cloud-Anbietern).
Funktionsweise:Sie konfigurieren einen einzelnen globalen Einstiegspunkt (URL), der sich am Netzwerkrand befindet. Der Load Balancer erkennt automatisch den geografischen Ursprung der Anfrage von den Fulfillment-Clustern von Google und leitet den Traffic an Ihr nächstgelegenes regionales fehlerfreies Backend weiter.
Vorteil:Dies bietet die Leistung von Anycast mit deutlich geringerer Konfigurationskomplexität und niedrigeren Kosten.
Standortbezogenes DNS (GeoDNS)
Funktionsweise:Konfigurieren Sie Ihren DNS-Anbieter so, dass Ihre Fulfillment-URL je nach geografischem Standort der DNS-Abfrage in verschiedene IP-Adressen aufgelöst wird.
Implementierung:Achten Sie darauf, dass Ihr DNS-Anbieter für die Egress-Punkte von Google optimiert ist. Wenn die regionalen Fulfillment-Dienste von Google (z. B. in den USA, der EU oder Asien) Ihre Domain auflösen, erhalten sie die IP-Adresse für das Rechenzentrum in dieser Region.
Optimierungsstrategien auf der Anwendungsebene
Neben dem Routing auf Infrastrukturebene können Sie die folgenden Strategien auf der Anwendungsebene implementieren, um die Latenz bei der Anfrageverarbeitung zu reduzieren.
Die „Trampoline“-Proxy-Methode
Wenn Sie ein primäres Rechenzentrum beibehalten müssen, verwenden Sie regionale Lightweight-Proxy-Server (Trampoline), um den ersten Handshake zu verarbeiten.
Google ruft Ihre globale URL auf.
Ein regionaler Proxy (z. B. eine Lightweight-Nginx- oder Lambda-Funktion) empfängt die Anfrage.
Der Proxy leitet die Nutzlast über Ihr internes Hochgeschwindigkeits-Backbone an die primäre Datenbank weiter.
Vorteil:Dadurch wird die Zeit für den TCP-Handshake reduziert, die oft den größten Beitrag zur Latenz bei Anfragen über große Entfernungen leistet.
Regionshinweise für Zugriffstoken
Während der Kontoverknüpfung (OAuth) kann Ihr System die Heimatregion des Nutzers ermitteln.
Implementierung:Codieren Sie eine Regions-ID in das
access_token, das an Google ausgegeben wird. Wenn Google eine Fulfillment-Anfrage sendet, kann Ihr Gateway das Token sofort prüfen und die Anfrage an den richtigen regionalen Cluster weiterleiten, ohne dass eine Datenbanksuche erforderlich ist.
Systemstatus – Messwerte von Partner an Google
Wenn Sie eine Erfolgsrate von mindestens 99,5% beibehalten, können Sie sicherstellen, dass die Gerätestatus in Google Home korrekt sind, Geräte hinzugefügt und entfernt werden, Automatisierungen ausgelöst werden und Verlaufsereignisse auf dem Tab „Aktivität“ der Google Home app (GHA)angezeigt werden.
Die Erfolgsrate wird anhand der HTTP-Antwortcodes berechnet, die von Google zurückgegeben werden, wenn Ihre Cloud Statusaktualisierungen sendet. Damit Partner nicht für Infrastrukturprobleme auf Google-Seite bestraft werden, werden interne Google-Fehler bei der Berechnung der Fehleranzahl ausgeschlossen. Die in der Berechnung enthaltenen API-Aufrufe finden Sie in der HomeGraph API-Referenz.
Was ist ein „Erfolg“?
- 2xx (Erfolg): Die Statusaktualisierung wurde von Home Graph erfolgreich empfangen und verarbeitet.
Was ist ein „Fehler“?
- 4xx (Partnerfehler): Diese Fehler stellen Fehler dar und weisen auf ein Problem mit der Anfrage hin, die von Ihrer Cloud gesendet wurde. Häufige Codes sind:
- 400: Ungültige Anfrage. Der Server konnte die Anfrage aufgrund einer ungültigen Syntax nicht verarbeiten. Häufige Ursachen sind fehlerhaftes JSON oder die Verwendung von „null“ anstelle von „“ für einen Stringwert.
- 404: Nicht gefunden. Die angeforderte Ressource konnte nicht gefunden werden. In der Regel bedeutet dies, dass Google das angeforderte Gerät nicht finden kann. Es kann auch bedeuten, dass das Nutzerkonto nicht verknüpft ist oder eine ungültige
agentUserIdempfangen wurde. Achten Sie darauf, dass dieagentUserIdmit dem in Ihrer SYNC-Antwort angegebenen Wert übereinstimmt und dass SieDISCONNECT-Intents ordnungsgemäß verarbeiten. - 429: Ressource erschöpft. Ihre Integration hat das zugewiesene Kontingent überschritten. Eine Anleitung zur Kontingentverwaltung finden Sie weiter oben im Dashboard im Abschnitt „Schritt 1“.
Gerätestatus – Statusgenauigkeit
Wenn Sie eine Statusgenauigkeit von mindestens 99,5% erreichen oder übertreffen, werden Nutzern korrekte Ergebnisse angezeigt, wenn sie Gerätestatus ansehen oder KI-Funktionen wie „Frag Google“ verwenden. Bei einer niedrigen Statusgenauigkeit werden Automatisierungen möglicherweise nicht ausgelöst und Verlaufseinträge werden möglicherweise nicht rechtzeitig auf dem Tab „Aktivität“ der GHAangezeigt. Weitere Informationen finden Sie unter Status melden.
Das Qualitäts-Dashboard erfasst diese Daten stündlich anhand von zwei verschiedenen Messwerten: Gesamtgenauigkeit und Niedrigste Kombination aus Typ und Merkmal.
1. Komponenten der Genauigkeit
Der Messwert wird aus „Beispielen“ abgeleitet, bei denen Google den gemeldeten Status mit einem bekannten Intent-Ergebnis vergleichen kann.
2. Dashboardmesswerte (stündliche Berechnung)
Das Dashboard berechnet die Genauigkeit basierend auf einem 1-Stunden-Intervall. Wenn in einer Stunde weniger als 100 Gesamtbeispiele vorhanden sind (S_Total < 100), wird die Genauigkeit für diese Stunde auf N/A festgelegt.
Ansicht 1: Gesamtgenauigkeit (globaler Durchschnitt)
Dies ist die Gesamtgenauigkeit Ihrer Integration für alle Gerätetypen und Merkmale zusammen. Sie bietet einen gewichteten Durchschnitt des Status Ihres gesamten Ökosystems.
- Berechnung: Gesamtgenauigkeit des Status für alle Geräte / Gesamtstatus für alle Geräte.
Ansicht 2: Niedrigste Kombination aus Typ und Merkmal
Hier wird die unzuverlässigste spezifische Kategorie in Ihrer Integration ermittelt. So wird verhindert, dass Geräte mit hohem Volumen und hoher Qualität Geräte mit niedrigem Volumen und niedriger Qualität verbergen. Wenn Sie beispielsweise eine große Anzahl von Lichtern mit einer Statusgenauigkeit von über 99,5% haben, aber nur wenige Schalter mit einer niedrigen Statusgenauigkeit, wird hier die Verbesserung hervorgehoben, die bei Schaltern erforderlich ist und die bei einem Durchschnittswert möglicherweise nicht sichtbar ist.
- Berechnung: Minimum der Statusgenauigkeit / Gesamtstatus für alle Kombinationen aus Merkmal und Gerät.