Medir lo que importa con Time-to-Interact

Contexto

Teníamos un Tech OKR de excelencia operativa y un problema bastante incómodo. No podíamos decir cuánto tardaba la app en arrancar ni cuánto tardaba cada pantalla en estar lista para usarse.

Había métricas de producto (qué pantallas ven los usuarios, qué botones tocan). Había métricas de desarrollo (errores de red, excepciones). Pero tiempo hasta que la pantalla responde, nada.

Problema

No se puede mejorar lo que no se mide. Y no se puede discutir con un equipo de producto si “la pantalla va lenta” es una sensación tuya o un dato.

Había una complicación más. La app era mitad nativa, mitad React Native. Si cada plataforma medía a su manera, los números no se podían comparar. Y sin comparar, no hay prioridades.

Qué decidimos (y qué descartamos)

Decidimos que el Time-to-Interact es una métrica de ingeniería, no de producto. Por eso no lo metimos en el componente de analítica de producto, que sirve para otra cosa. Lo pusimos en el componente que ya recogía métricas de desarrollo y lo extendimos con una idea sencilla, una traza con tres operaciones, empezar, terminar y abandonar.

Descartamos:

• Medir solo con herramientas de terceros. Útiles, pero no nos daban el control de qué es “interactivo” para cada pantalla.
• Una implementación distinta por plataforma. Mismo vocabulario en Android, iOS y React Native o no sirve.
• Atarnos a un proveedor. El tracker define el contrato; Datadog es un cliente más, intercambiable.

Cómo lo hicimos

El diseño tenía tres capas:

1. El componente base. Expone el contrato de la traza. Una máquina de estados simple (sin iniciar, en curso, terminada, abandonada) para que sea imposible dejar una medición a medias sin darte cuenta.
2. El cliente de Datadog. Traduce las trazas a la integración de Real User Monitoring del proveedor.
3. El puente de React Native. Para que una feature escrita en React Native use exactamente la misma API.

Después vino la parte que no sale en el diagrama. Integrarlo en las pantallas importantes (feed, listados, checkout, perfil), escribir la documentación para que cualquier equipo pudiera medir su pantalla, y ajustar el muestreo. Medir al 100% de los usuarios es caro y casi nunca hace falta.

Escribí el tech spec antes que el código. Parece lento y es lo contrario. Discutir el diseño en un documento es mucho más barato que discutirlo en la revisión de un PR enorme.

Resultado

Por primera vez, equipos distintos hablaban de rendimiento con los mismos números y el mismo vocabulario. Las mediciones alimentaron iniciativas concretas de rendimiento y ayudaron a poner umbrales de go/no-go en lanzamientos grandes. Y la integración con el proveedor de observabilidad se volvió bastante más barata al ajustar el muestreo, algo que se nota cuando pagás por volumen.

Qué haría distinto

Definiría con producto, desde el principio, qué significa “interactivo” en cada pantalla clave. Lo hicimos, pero se discutió más tarde de lo necesario, y una métrica sin definición compartida genera discusiones sobre la métrica en lugar de sobre la app.

Y publicaría antes un tablero simple para ingenieros. Los datos que nadie mira son solo costo.