Este conjunto de paneles y alertas te ayuda a mantener de forma proactiva una integración de alta calidad con el ecosistema de Google Home. Google se compromete a ayudar a los socios a desarrollar un ecosistema de alta calidad para todos los clientes.
El panel tiene tres secciones, cada una de las cuales abarca una parte clave que contribuye a la calidad de una integración general.
Métricas de Google al socio : Mide el estado de las llamadas de Google a tu backend de la nube.
Estado del sistema: Métricas del socio a Google : Mide el estado de las llamadas de tu sistema a Google.
Estado del dispositivo: Exactitud del estado : Mide la exactitud de los estados almacenados en los sistemas de Google, que se usan para atender las consultas de los usuarios.
Cuando las métricas no cumplen con sus valores objetivo, se destacan en rojo para indicar un problema que podría afectar la experiencia del usuario. La siguiente información proporciona detalles sobre cada objetivo y por qué es importante para tus usuarios.
Si el siguiente botón no te lleva directamente al panel, puedes acceder a él seleccionando la página Descripción general , luego Paneles y, en la lista Mis paneles , selecciona Panel de estadísticas vitales de Google Home (Cloud) para ver tu panel.
Métricas de Google al socio
La métrica Tasa de éxito de la consulta/ejecución >= 99.5% mide la frecuencia con la que se cumplen correctamente los comandos de los usuarios, lo que ayuda a evitar respuestas del Asistente como "No puedo acceder al dispositivo" o confirmar de forma incorrecta un comando que no se cumplió.
¿Qué define un "éxito"?
Una transacción se marca como exitosa si la plataforma de Google Home recibe una respuesta válida que indica que se cumplió la acción deseada o que se recuperó el estado solicitado.
Las respuestas que incluyen excepciones que no generan un bloqueo (por ejemplo, un estado SUCCESS acompañado de una excepción lowBattery) se consideran transacciones exitosas.
El comando llegó al dispositivo y el intent se satisfizo a pesar de la advertencia.
¿Qué define una "falla"?
Los errores que se encuentran en Códigos de error comunes de la plataforma y que están marcados como Acción del socio se consideran "fallas" cuando se calculan las tasas de éxito de QUERY y EXECUTE. Además, los errores que se encuentran en Errores y excepciones también son "fallas", con las siguientes excepciones:
| Excepciones de fallas | ||
|---|---|---|
| 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 métrica Latencia de la consulta/ejecución (p90) <= 1000 ms mide el tiempo de espera de la acción solicitada y ayuda a garantizar que los usuarios no tengan que esperar demasiado tiempo, por ejemplo, esperar unos segundos para que se apague la luz.
Métricas de latencia
La latencia es un indicador fundamental de la capacidad de respuesta de tu integración para el usuario final. El panel hace un seguimiento de la latencia del percentil 90 (P90), que representa la experiencia de tus usuarios "más lentos" (por ejemplo, un P90 de 800 ms significa que el 90% de las solicitudes se reconocen en 800 ms o menos).
Google mide la latencia de manera diferente para las verificaciones de estado en comparación con los comandos del dispositivo para garantizar la exactitud técnica.
1. Latencia de QUERY (interrogativa)
Mide el tiempo de ida y vuelta de Cloud-to-cloud cuando Google solicita el estado actual de un dispositivo.
- Inicio: Google envía una solicitud
action.devices.QUERYa tu URL de entrega. - Ventana de medición: Es el tiempo que tarda tu nube en recibir, procesar y transmitir la respuesta HTTP completa a Google.
- Fin: Google recibe y reconoce la carga útil de la respuesta final de tu servicio.
2. Latencia de EXECUTE (acción)
Mide el tiempo de reconocimiento del comando cuando Google envía una solicitud de control a un dispositivo.
- Inicio: Google envía una solicitud
action.devices.EXECUTEa tu URL de entrega. - Ventana de medición: Es el tiempo que tarda tu nube en recibir el comando y mostrar una respuesta de reconocimiento.
- Fin: Google recibe la respuesta de estado
SUCCESS,PENDINGoOFFLINE. - Alcance técnico: Esta métrica mide el tiempo de "reconocimiento de respuesta" entre la nube de Google y tu nube. No mide el tiempo que tarda el hardware físico (por ejemplo, una bombilla) en completar el cambio de estado físico, ya que, a menudo, implica una latencia de red de malla local fuera de la ruta de acceso de nube a nube.
Opciones de reducción de latencia
Recomendaciones de arquitectura para el enrutamiento geográfico
Si la implementación de IP de Anycast no es factible, te recomendamos las siguientes alternativas rentables para garantizar que los usuarios reciban servicio del centro de datos regional más cercano.
Balanceo de cargas global (GLB)
En lugar del enrutamiento estático, usa un balanceador de cargas de aplicaciones global (disponible en la mayoría de los proveedores de servicios en la nube principales).
Cómo funciona: Configuras un solo punto de entrada global (URL) que se encuentra en el perímetro de la red. El balanceador de cargas detecta automáticamente el origen geográfico de la solicitud de los clústeres de entrega de Google y enruta el tráfico a tu backend regional en buen estado más cercano.
Beneficio: Proporciona el rendimiento de Anycast con una complejidad y un costo de configuración significativamente más bajos.
DNS con reconocimiento de ubicación geográfica (GeoDNS)
Cómo funciona: Configura tu proveedor de DNS para que resuelva tu URL de entrega en diferentes direcciones IP según la ubicación geográfica de la consulta de DNS.
Implementación: Asegúrate de que tu proveedor de DNS esté optimizado para los puntos de salida de Google. Cuando los servicios de entrega regionales de Google (por ejemplo, en EE.UU., la UE o Asia) resuelvan tu dominio, recibirán la dirección IP del centro de datos en esa región específica.
Estrategias de optimización en la capa de aplicación
Además del enrutamiento a nivel de la infraestructura, puedes implementar las siguientes estrategias en la capa de aplicación para reducir la latencia en el procesamiento de solicitudes.
Método de proxy "Trampoline"
Si debes mantener un centro de datos principal, usa servidores proxy regionales ligeros (Trampolines) para controlar el protocolo de enlace inicial.
Google accede a tu URL global.
Un proxy regional (por ejemplo, una función ligera de Nginx o Lambda) recibe la solicitud.
El proxy reenvía la carga útil a través de tu red troncal interna de alta velocidad a la base de datos principal.
Beneficio: Esto reduce el tiempo de "protocolo de enlace TCP", que suele ser el factor que más contribuye a la latencia de las solicitudes de larga distancia.
Sugerencias de región del token de acceso
Durante el proceso de vinculación de cuentas (OAuth), tu sistema puede identificar la región de origen del usuario.
Implementación: Codifica un identificador de región en el
access_tokenemitido a Google. Cuando Google envía una solicitud de entrega, tu puerta de enlace puede inspeccionar el token de inmediato y enrutar la solicitud al clúster regional correcto sin necesidad de buscar en la base de datos.
Estado del sistema: Métricas del socio a Google
Mantener una tasa de éxito >= 99.5% ayuda a garantizar que los estados del dispositivo sean correctos en Google Home, que los dispositivos se agreguen y quiten, que se activen las automatizaciones y que los eventos del historial aparezcan en la pestaña Actividad de Google Home app (GHA).
La tasa de éxito se calcula en función de los códigos de respuesta HTTP que muestra Google cuando tu nube envía actualizaciones de estado. Para garantizar que los socios no sean penalizados por problemas de infraestructura del lado de Google, la métrica excluye los errores internos de Google del recuento de fallas. Las llamadas a la API incluidas en el cálculo se encuentran en la referencia de la API de HomeGraph.
¿Qué define un "éxito"?
- 2xx (éxito): Home Graph recibió y procesó correctamente la actualización de estado.
¿Qué define una "falla"?
- 4xx (error del socio): Representan fallas e indican un problema con la solicitud enviada desde tu nube. Entre los códigos comunes, se incluyen los siguientes:
- 400 Solicitud incorrecta: El servidor no pudo procesar la solicitud debido a una sintaxis no válida. Entre las causas comunes, se incluyen el uso de JSON con formato incorrecto o el uso de un valor nulo en lugar de "" para un valor de cadena.
- 404 No encontrado: No se pudo encontrar el recurso solicitado. Por lo general, esto significa que Google no puede encontrar el dispositivo solicitado. También puede significar que la cuenta de usuario no está vinculada o que se recibió un
agentUserIdno válido. Asegúrate de que elagentUserIdcoincida con el valor proporcionado en tu respuesta SYNC y de que estés controlando correctamente los intentsDISCONNECT. - 429 Se agotó el recurso: Tu integración excedió la cuota asignada. Consulta las instrucciones en la sección "Paso 1" más arriba en el panel para administrar la cuota.
Estado del dispositivo: Exactitud del estado
Cumplir o superar una exactitud del estado >= 99.5% ayuda a garantizar que los usuarios vean resultados correctos cuando consultan los estados del dispositivo o usan funciones de IA como Preguntar a Home. Si la exactitud del estado es baja, es posible que las automatizaciones no se activen y que las entradas del historial no aparezcan en la pestaña Actividad de GHAen el momento adecuado. Para obtener más información, consulta Informar el estado.
El panel de calidad realiza un seguimiento de esto por hora con dos métricas distintas: Exactitud general y la combinación de tipo/atributo más baja.
1. Componentes de exactitud
La métrica se deriva de "muestras" en las que Google puede verificar el estado informado en función de un resultado de intent conocido.
2. Métricas del panel (cálculo por hora)
El panel calcula la exactitud en función de un intervalo de 1 hora. Si una hora tiene menos de 100 muestras totales (S_Total < 100), la exactitud para esa hora se establece en N/A.
Vista 1: Exactitud general (promedio global)
Representa la exactitud total de tu integración en todos los tipos y atributos de dispositivos combinados. Proporciona un promedio ponderado del estado de todo tu ecosistema.
- Cálculo: Exactitud total del estado en todos los dispositivos / Total del estado total en todos los dispositivos.
Vista 2: Combinación de tipo/atributo más baja
Identifica la categoría específica menos confiable de tu integración. Evita que los dispositivos de alto volumen que son de alta calidad oculten los dispositivos de bajo volumen que son de baja calidad. Por ejemplo, si tienes un gran volumen de luces con una exactitud del estado superior al 99.5%, pero un volumen bajo de interruptores con una exactitud del estado baja, esto destaca la mejora necesaria en los interruptores que pueden perderse en un valor promedio.
- Cálculo: Mínimo de la exactitud del estado / Total del estado para todas las combinaciones de atributo/dispositivo.