Contar inicios de sesión o clics puede indicar que alguien interactúa con un producto, pero no demuestra que una capacidad resuelva un problema. Para priorizar mejoras, las métricas de uso en SaaS deben vincular comportamientos observables con preguntas de producto: quién utiliza una función, con qué frecuencia, en qué contexto y dónde abandona un flujo.
La instrumentación útil empieza antes de escribir código. Si un evento no puede orientar una decisión, probablemente sea ruido. El objetivo no es registrar cada acción disponible, sino construir señales consistentes que permitan entender adopción, detectar fricción y comprobar si una intervención cambia el comportamiento esperado.
Empezar por la decisión, no por el evento
Formulad primero la pregunta que queréis responder. Por ejemplo: “¿Qué proporción de cuentas configura una integración durante sus primeros 14 días?” es más accionable que “¿Cuántas veces se pulsó el botón de integración?”. La primera define una población, una acción y una ventana temporal; la segunda solo describe actividad.
Para cada métrica, documentad:
- Decisión: qué podría cambiar el equipo si la señal sube, baja o se mantiene.
- Población: qué usuarios, cuentas o planes se incluyen y cuáles se excluyen.
- Comportamiento: qué acción observable cuenta como uso significativo.
- Periodo: cuándo comienza y termina la ventana de observación.
- Limitaciones: qué no permite concluir la métrica.
Si la respuesta no alteraría una prioridad, una hipótesis o una investigación, no hace falta instrumentarla todavía. En cambio, una pregunta sobre abandono puede requerir eventos de inicio y finalización de un flujo, no un contador general de actividad.
Definir eventos con un esquema estable
Un evento debe tener un nombre comprensible y una definición compartida entre producto y desarrollo. Una estructura práctica incluye el nombre, el actor, la cuenta asociada, el momento de emisión y un contexto mínimo. Por ejemplo, report_export_completed debería significar que la exportación terminó correctamente, no que se mostró el botón ni que comenzó una petición.
Documentad también las propiedades permitidas y sus tipos: identificador interno de cuenta, tipo de exportación o resultado. Evitad nombres ambiguos como action y valores libres que mezclen conceptos. Si el significado de un evento cambia, registrad la modificación o introducid una versión del esquema; de lo contrario, una serie histórica puede combinar comportamientos distintos sin que los informes lo adviertan.
Definid con precisión el momento de emisión. Para medir finalización, enviad el evento tras confirmar el resultado, no antes de ejecutar la operación. En procesos asíncronos, separad inicio, éxito y fallo si esas etapas responden preguntas diferentes. No llaméis “completado” a un proceso que solo se ha puesto en cola.
Separar usuarios, cuentas y flujos
En SaaS B2B, una persona y una cuenta empresarial no son la misma unidad de análisis. Un usuario puede pertenecer a una organización; varios usuarios pueden utilizar una capacidad desde esa cuenta. La adopción por cuenta responde cuántas organizaciones han incorporado una función. La actividad individual muestra quién la utiliza y con qué regularidad. Ambas perspectivas son válidas, pero no deben mezclarse en un mismo denominador.
Por ejemplo, para evaluar una función colaborativa, podéis medir la proporción de cuentas elegibles con al menos una acción válida y, por separado, cuántos usuarios distintos participan en cada cuenta. Definid qué significa “elegible”: una cuenta sin acceso a la función no debería aparecer como no adoptante. Acordad también cómo se trata una cuenta con varios espacios de trabajo o usuarios que cambian de organización.
Para entender un flujo, estableced pasos observables, como inicio, validación y finalización. Comparad el número de entidades que llegan a cada etapa usando una identidad coherente. La tasa de abandono solo es interpretable si se conoce qué población entró al flujo, durante cuánto tiempo se espera su finalización y cómo se tratan reintentos o procesos aún abiertos.
Prevenir duplicados y actividad que no representa uso
Un mismo comportamiento puede registrarse dos veces si el navegador reintenta una petición, una cola vuelve a procesar un mensaje o una llamada termina sin que el cliente reciba confirmación. Usad una clave de idempotencia o un identificador único de operación cuando corresponda, y definid en el sistema analítico qué evento representa la acción de negocio contabilizable.
Separad las acciones de personas de tareas automáticas. Una sincronización programada, un trabajo de mantenimiento o una llamada interna no debería inflar el uso atribuible a un usuario. Si interesa medir actividad automática, etiquetadla con un actor o tipo de origen distinto y excluidla de los indicadores de adopción humana.
También hay que resolver cambios de identidad: invitaciones, bajas, usuarios fusionados y cuentas migradas. Estableced una regla consistente para la identidad analítica, evitando utilizar el correo electrónico como identificador permanente. Un identificador interno seudónimo suele ser más estable y reduce la exposición de datos personales.
Instrumentar en PHP sin acoplar analítica al negocio
La lógica de negocio debe determinar si una operación se permite y cuál es su resultado. La analítica registra ese resultado, pero no debería decidirlo. Si una llamada al proveedor de analítica falla, normalmente no debe impedir que el usuario complete una exportación o guarde un cambio.
En una aplicación PHP, podéis emitir eventos desde un servicio de aplicación después de confirmar la operación relevante y enviarlos mediante una cola o un mecanismo desacoplado cuando la fiabilidad lo exija. Si la consistencia entre la transacción de negocio y el registro es crítica, evaluad un patrón de outbox: guardar el evento pendiente junto con el cambio y publicarlo después. La elección depende del riesgo de pérdida, el volumen y la arquitectura; no todos los productos necesitan la misma complejidad.
Centralizad el esquema y las convenciones, en vez de construir eventos dispersos con propiedades distintas en cada controlador. Aplicad límites y validaciones, registrad errores de entrega sin volcar cargas sensibles y evitad que las reglas de negocio dependan de una respuesta de analítica.
Minimizar datos y validar la instrumentación
Recoged únicamente los datos necesarios para responder la pregunta definida. No enviéis contraseñas, contenido de documentos, tokens, datos de pago ni texto libre a la analítica. Revisad identificadores y propiedades que puedan revelar información personal, restringid el acceso por función y estableced una política de conservación acorde con la finalidad y las obligaciones aplicables.
Antes de confiar en un indicador, probad los eventos con escenarios concretos: operación exitosa, fallo de validación, reintento, doble envío, usuario sin permisos y proceso automático. Comprobad que el evento aparece una sola vez, que contiene el actor y la cuenta esperados, y que se emite en el momento correcto. Añadid comprobaciones operativas para detectar caídas bruscas de volumen, propiedades ausentes o cambios en la proporción de errores.
La validación no termina al desplegar código. Comparad registros de muestra con la acción real, verificad filtros y denominadores de los informes y revisad cambios de esquema. Un aumento repentino puede deberse a una nueva integración, un error de duplicación o una alteración en la identidad, no a una mejora de adopción.
Interpretar señales y convertirlas en pruebas
Las tendencias y cohortes ayudan a comparar grupos definidos por una condición común, como la fecha de alta o el uso inicial de una capacidad. Indicad siempre el periodo, el tamaño del grupo y los criterios de inclusión. Una mejora de conversión después de un cambio es una señal para investigar, no una prueba automática de que el cambio la causó: pueden haber influido estacionalidad, composición de clientes, campañas o modificaciones simultáneas.
Convertid la observación en una hipótesis verificable. Por ejemplo: “Las cuentas que no completan la conexión se detienen durante la autorización; mostrar instrucciones específicas debería aumentar las conexiones válidas”. Definid de antemano la métrica principal, las métricas de protección —como errores o solicitudes de soporte— y el periodo de evaluación. Cuando sea viable, utilizad una comparación controlada; si no, combinad la tendencia con entrevistas, revisión de sesiones o análisis de incidencias, sin presentar evidencia correlacional como causal.
Una métrica útil permite decidir qué hacer a continuación, no solo informar de lo ocurrido. Revisad periódicamente si cada evento conserva una definición clara y si sigue respondiendo a una decisión real. Así, la analítica acompaña al producto: ofrece señales fiables, mantiene visibles sus límites y orienta pruebas que pueden confirmar o refutar una hipótesis.
