Questa suite di dashboard e avvisi ti aiuta a mantenere in modo proattivo un'integrazione di alta qualità con l'ecosistema Google Home. Google si impegna a supportare i partner nello sviluppo di un ecosistema di alta qualità per tutti i clienti
La dashboard è suddivisa in tre sezioni, ognuna delle quali copre una parte fondamentale che contribuisce alla qualità di un'integrazione complessiva.
Metriche da Google a Partner : misura l'integrità delle chiamate da Google a tuo backend cloud.
Integrità del sistema - Metriche da Partner a Google : misura l'integrità delle chiamate dal tuo sistema a Google.
Integrità del dispositivo - Precisione dello stato : misura la precisione degli stati archiviati nei sistemi Google, utilizzati per rispondere alle query degli utenti.
Quando le metriche non raggiungono i valori target, vengono evidenziate in rosso per indicare un problema che potrebbe influire sull'esperienza utente. Le seguenti informazioni forniscono dettagli su ogni target e sul motivo per cui è importante per i tuoi utenti.
Se il pulsante seguente non ti porta direttamente alla dashboard, puoi accedervi selezionando la pagina Panoramica, poi Dashboard e infine Dashboard Google Home Vitals (Cloud) dall'elenco Le mie dashboard per visualizzare la dashboard.
Metriche da Google a Partner
La metrica Percentuale di successo di query/esecuzione >= 99,5% misura la frequenza con cui i comandi degli utenti vengono eseguiti correttamente, il che aiuta a evitare risposte dell'Assistente come "Non riesco a raggiungere il dispositivo" o a confermare in modo errato un comando che non è stato eseguito.
Che cosa definisce un "successo"?
Una transazione viene contrassegnata come riuscita se la piattaforma Google Home riceve una risposta valida che indica che l'azione prevista è stata eseguita o che lo stato richiesto è stato recuperato.
Le risposte che includono eccezioni non bloccanti (ad esempio, uno stato SUCCESS accompagnato da un'eccezione lowBattery) vengono conteggiate come transazioni riuscite.
Il comando ha raggiunto il dispositivo e l'intent è stato soddisfatto nonostante l'avviso.
Che cosa definisce un "errore"?
Gli errori rilevati in Codici di errore comuni della piattaforma contrassegnati come Azione partner vengono considerati "errori" nel calcolo delle percentuali di successo di QUERY ed EXECUTE. Inoltre, gli errori rilevati in Errori ed eccezioni sono considerati "errori", con le seguenti eccezioni:
| Eccezioni di errore | ||
|---|---|---|
| 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 |
La metrica Latenza di query/esecuzione (p90) <= 1000 ms misura il tempo di attesa dell'azione richiesta e aiuta a garantire che gli utenti non debbano attendere troppo a lungo, ad esempio qualche secondo per lo spegnimento della luce.
Metriche di latenza
La latenza è un indicatore fondamentale della reattività dell'integrazione per l'utente finale. La dashboard monitora la latenza del 90° percentile (P90), che rappresenta l'esperienza degli utenti "più lenti" (ad esempio, un P90 di 800 ms significa che il 90% delle richieste viene riconosciuto in 800 ms o meno).
Per garantire la precisione tecnica, Google misura la latenza in modo diverso per i controlli di stato rispetto ai comandi del dispositivo.
1. Latenza QUERY (interrogativa)
Misura il tempo di andata e ritorno Cloud-to-cloud quando Google chiede lo stato attuale di un dispositivo.
- Inizio: Google invia una richiesta
action.devices.QUERYall'URL di fulfillment. - Finestra di misurazione: il tempo impiegato dal tuo cloud per ricevere, elaborare e ritrasmettere la risposta HTTP completa a Google.
- Fine: Google riceve e riconosce il payload della risposta finale dal tuo servizio.
2. Latenza EXECUTE (azione)
Misura il tempo di riconoscimento del comando quando Google invia una richiesta di controllo a un dispositivo.
- Inizio: Google invia una richiesta
action.devices.EXECUTEall'URL di fulfillment. - Finestra di misurazione: il tempo impiegato dal tuo cloud per ricevere il comando e restituire una risposta di riconoscimento.
- Fine: Google riceve la risposta di stato
SUCCESS,PENDINGoOFFLINE. - Ambito tecnico: questa metrica misura il tempo di "riconoscimento della risposta" tra il cloud di Google e il tuo cloud. Non misura il tempo impiegato dall'hardware fisico (ad esempio, una lampadina) per completare la modifica dello stato fisico, poiché spesso comporta la latenza della rete mesh locale al di fuori del percorso da cloud a cloud.
Opzioni di riduzione della latenza
Consigli sull'architettura per il geo-routing
Se l'implementazione dell'IP Anycast non è fattibile, ti consigliamo le seguenti alternative economiche per garantire che gli utenti vengano serviti dal data center regionale più vicino.
Global Load Balancing (GLB)
Anziché il routing statico, utilizza un bilanciatore del carico delle applicazioni globale (disponibile dalla maggior parte dei principali provider di servizi cloud).
Come funziona:configuri un singolo punto di contatto globale (URL) che si trova all'edge della rete. Il bilanciatore del carico rileva automaticamente l'origine geografica della richiesta dai cluster di fulfillment di Google e instrada il traffico al backend regionale integro più vicino.
Vantaggio:offre le prestazioni di Anycast con costi e complessità di configurazione notevolmente inferiori.
DNS con riconoscimento della posizione geografica (GeoDNS)
Come funziona:configura il tuo provider DNS in modo che risolva l'URL di fulfillment in indirizzi IP diversi in base alla posizione geografica della query DNS.
Implementazione:assicurati che il tuo provider DNS sia ottimizzato per i punti di uscita di Google. Quando i servizi di fulfillment regionali di Google (ad esempio, negli Stati Uniti, nell'UE o in Asia) risolvono il tuo dominio, ricevono l'indirizzo IP del data center nella regione specifica.
Strategie di ottimizzazione a livello di applicazione
Oltre al routing a livello di infrastruttura, puoi implementare le seguenti strategie a livello di applicazione per ridurre la latenza nell'elaborazione delle richieste.
Metodo proxy "Trampoline"
Se devi mantenere un data center principale, utilizza server proxy regionali leggeri (Trampoline) per gestire l'handshake iniziale.
Google accede al tuo URL globale.
Un proxy regionale (ad esempio, una funzione Nginx o Lambda leggera) riceve la richiesta.
Il proxy inoltra il payload tramite la dorsale interna ad alta velocità al database principale.
Vantaggio:riduce il tempo di "handshake TCP", che spesso è il principale fattore che contribuisce alla latenza per le richieste a lunga distanza.
Suggerimenti sulla regione del token di accesso
Durante la procedura di collegamento dell'account (OAuth), il tuo sistema può identificare la regione di residenza dell'utente.
Implementazione:codifica un identificatore di regione nel
access_tokenrilasciato a Google. Quando Google invia una richiesta di fulfillment, il gateway può ispezionare immediatamente il token e instradare la richiesta al cluster regionale corretto senza dover eseguire una ricerca nel database.
Integrità del sistema - Metriche da Partner a Google
Mantenere una percentuale di successo >= 99, 5% aiuta a garantire che gli stati dei dispositivi siano corretti in Google Home, che i dispositivi vengano aggiunti e rimossi, che le automazioni vengano attivate e che gli eventi della cronologia vengano visualizzati nella scheda Attività di Google Home app (GHA).
La percentuale di successo viene calcolata in base ai codici di risposta HTTP restituiti da Google quando il tuo cloud esegue il push degli aggiornamenti di stato. Per garantire che i partner non vengano penalizzati per i problemi dell'infrastruttura lato Google, la metrica esclude gli errori interni di Google dal conteggio degli errori. Le chiamate API incluse nel calcolo sono disponibili nel riferimento dell'API HomeGraph.
Che cosa definisce un "successo"?
- 2xx (successo): l'aggiornamento di stato è stato ricevuto ed elaborato correttamente da Home Graph.
Che cosa definisce un "errore"?
- 4xx (errore del partner): rappresentano gli errori e indicano un problema con la richiesta inviata dal tuo cloud. I codici comuni includono:
- 400 Richiesta non valida: il server non è riuscito a elaborare la richiesta a causa di una sintassi non valida. Le cause comuni includono JSON non valido o l'utilizzo di null anziché "" per un valore stringa.
- 404 Non trovato: non è stato possibile trovare la risorsa richiesta. In genere, significa che Google non riesce a trovare il dispositivo richiesto. Potrebbe anche significare che l'account utente non è collegato o che è stato ricevuto un
agentUserIdnon valido. Assicurati cheagentUserIdcorrisponda al valore fornito nella risposta SYNC e che tu stia gestendo correttamente gli intentDISCONNECT. - 429 Risorsa esaurita: la tua integrazione ha superato la quota assegnata. Per la gestione delle quote, consulta le istruzioni nella sezione "Passaggio 1" più in alto nella dashboard.
Integrità del dispositivo - Precisione dello stato
Raggiungere o superare una precisione dello stato >= 99,5% aiuta a garantire che gli utenti vedano risultati corretti quando visualizzano gli stati dei dispositivi o utilizzano funzionalità di AI come Chiedi a Home. Se la precisione dello stato è bassa, le automazioni potrebbero non attivarsi e le voci della cronologia potrebbero non essere visualizzate nella scheda Attività di GHAal momento giusto. Per ulteriori informazioni, consulta la sezione Segnala stato.
La dashboard sulla qualità monitora questa metrica ogni ora utilizzando due metriche distinte: Precisione complessiva e Combinazione tipo/caratteristica più bassa.
1. Componenti di precisione
La metrica deriva da "campioni" in cui Google può verificare lo stato segnalato rispetto a un risultato di intent noto.
2. Metriche della dashboard (calcolo orario)
La dashboard calcola la precisione in base a un intervallo di 1 ora. Se un'ora ha meno di 100 campioni totali (S_Total < 100), l'accuratezza per quell'ora viene impostata su N/A.
Visualizzazione 1: accuratezza complessiva (media globale)
Rappresenta l'accuratezza totale della tua integrazione per tutti i tipi di dispositivi e i trait combinati. Fornisce una media ponderata dell'integrità dell'intero ecosistema.
- Calcolo: accuratezza totale dello stato su tutti i dispositivi / stato totale su tutti i dispositivi.
Visualizzazione 2: combinazione tipo/caratteristica più bassa
Identifica la categoria specifica meno affidabile nella tua integrazione. Impedisce ai dispositivi ad alto volume di alta qualità di nascondere i dispositivi a basso volume di bassa qualità. Ad esempio, se hai un volume elevato di luci con una precisione dello stato superiore al 99,5%, ma un volume basso di interruttori con una precisione dello stato bassa, questa metrica evidenzia il miglioramento necessario per gli interruttori che potrebbero essere persi in un valore medio.
- Calcolo: minimo di accuratezza dello stato / stato totale per tutte le combinazioni di trait/dispositivi.