Una lista de comprobación de analítica para MVP debe cubrir cuatro aspectos antes del lanzamiento: un flujo de trabajo principal, su evento de activación, sus estados de error y el comportamiento de retorno que justifica otro ciclo de desarrollo. Cada evento debe respaldar una decisión de mantener, corregir o detener durante los primeros 30 días.
Las páginas vistas dejan sin medir la promesa principal del producto.
Los fundadores tienen poco tráfico y aún menos tiempo, así que el primer plan de eventos debe ser breve. Esta guía le ofrece una lista que puede copiar, nombres de eventos reales del sitio en producción de webvise y un registro de decisiones para 30 días. El servicio de desarrollo de MVP de webvise incluye analítica de usuarios desde el primer día para que la primera cohorte pueda influir en la siguiente decisión de desarrollo.
- Instrumente un flujo de trabajo crítico. Registre su inicio, finalización correcta, fallo y posterior repetición antes de añadir embudos secundarios.
- Defina la activación como valor entregado. La creación de una cuenta registra el acceso. El evento que demuestra que el producto cumplió su función debe formar parte de la definición de activación.
- Registre el éxito después de que el servidor lo confirme. Los clics en botones y los estados optimistas de la interfaz pueden inflar el trabajo que consta como completado.
- Escriba la regla de decisión antes del lanzamiento. Cada métrica necesita una persona responsable, una fecha de revisión y una acción acordada de mantener, corregir o detener.
Empiece por la decisión que el MVP debe respaldar
Un MVP se gana otro ciclo de desarrollo cuando el uso real responde a una pregunta comercial. El plan de eventos parte de esa pregunta y retrocede hasta encontrar el conjunto mínimo de acciones capaz de responderla.
La plantilla de documento de requisitos para un MVP ya pide un usuario, un flujo de trabajo y una métrica de éxito. La analítica asigna a esa métrica un nombre de evento, un punto de captura, un plazo y una persona responsable de la decisión.
| Pregunta de producto | Evidencia que debe registrar | Decisión que respalda |
|---|---|---|
| ¿Puede un usuario nuevo alcanzar el valor prometido? | Inicio, éxito, error y tiempo de finalización del flujo de trabajo principal | Mantener el flujo de trabajo o corregir el paso que bloquea al usuario |
| ¿Merece el valor una nueva visita? | Un segundo flujo de trabajo completado con éxito en un día posterior | Invertir en retención o revisar la promesa del producto |
| ¿Entregará el comprador dinero o asumirá un compromiso? | Pago, piloto firmado, solicitud cualificada u otro evento comercial declarado | Continuar con el modelo de negocio o cambiar la oferta |
| ¿Dónde falla el flujo de trabajo? | Código de error con nombre, paso, duración y versión de la aplicación | Corregir el fallo que más afecta a los usuarios |
Una métrica sin una decisión concreta se convierte en adorno para el dashboard. Escriba la decisión junto al evento mientras el equipo aún recuerde para qué existe.
Copie esta lista de comprobación de analítica para MVP
Use la lista durante la definición del alcance del producto y guarde el catálogo final de eventos junto al documento del MVP. Sustituya `core_workflow` por la acción que genera valor, como `report_generated`, `booking_confirmed` o `certificate_issued`.
| Elemento de la lista | Evento o campo de ejemplo | Criterio de aceptación |
|---|---|---|
| Entrada | `account_created` o primera sesión identificada | Un ID estable de usuario o espacio de trabajo se vincula a los eventos posteriores |
| Intención | `core_workflow_started` | Registrar cuando el usuario empiece la tarea relevante |
| Valor entregado | `core_workflow_completed` | Registrar después de que el backend confirme el resultado |
| Fallo | `core_workflow_failed` con `error_code` y `step` | El evento identifica un fallo que se puede corregir sin almacenar datos sensibles introducidos por el usuario |
| Activación | Flujo de trabajo completado dentro del plazo declarado | La definición indica el número de eventos y el límite de tiempo |
| Valor de retorno | Otro flujo de trabajo completado en un día posterior | La consulta excluye reintentos y entregas duplicadas |
| Resultado comercial | `payment_completed`, `pilot_signed` o `qualified_request_sent` | Usar solo el evento que corresponda a la hipótesis comercial |
| Contexto | `source`, `plan`, `workspace_id`, `duration_ms`, `app_version` | Cada propiedad tiene un uso para la toma de decisiones y un tipo de dato definido |
| Privacidad | Lista aprobada de propiedades y periodo de retención | Los correos electrónicos, cuerpos de mensajes, tokens de acceso y archivos privados quedan fuera de las propiedades de los eventos |
| Verificación | Prueba en staging, prueba en producción y consulta del dashboard | Una persona responsable comprueba cada evento crítico antes del lanzamiento |
El catálogo se mantiene breve a propósito. Un fundador puede revisar diez eventos después de cada sesión de usuario; un catálogo de 80 eventos crea divergencias en los nombres antes de que exista la primera cohorte útil.
Un flujo de trabajo necesita eventos de inicio, éxito y error
El formulario de contacto de webvise empezó con `contact_form_submitted` el 2026-03-13. Ese evento contabilizaba los intentos. `contact_form_started` llegó el 2026-04-30, seguido de `contact_form_success` y `contact_form_error` el 2026-05-01.
Cuatro eventos separan ahora tres problemas: personas que empiezan y abandonan, envíos que llegan al servidor y fallos de entrega posteriores al envío. Cada problema exige un trabajo distinto. El texto del formulario influye en los inicios, el diseño de los campos afecta a la finalización y los errores del servidor corresponden a ingeniería.
| Evento de producción | Pregunta que responde | Acción probable |
|---|---|---|
| `contact_form_started` | ¿Generó la página suficiente intención para empezar? | Revisar la oferta, el CTA y la ubicación del formulario |
| `contact_form_submitted` | ¿Terminó el visitante de rellenar los campos? | Revisar la fricción de los campos y la validación |
| `contact_form_success` | ¿Aceptó el backend la solicitud? | Contabilizar las consultas entregadas |
| `contact_form_error` | ¿Falló el flujo de trabajo después de que la intención quedara clara? | Revisar la ruta del servidor y avisar a la persona responsable |
El informe de salud de WordPress sigue la misma estructura en un embudo más largo. `analyzer_submitted` se lanzó el 2026-03-13, `analyzer_unlocked` el 2026-03-30 y los eventos independientes de éxito y error el 2026-05-01. El evento de éxito también almacena las puntuaciones para móvil, escritorio y proyectadas, lo que permite que un solo flujo de trabajo responda a preguntas de producto y cualificación sin copiar en la analítica el informe enviado.
Estos ejemplos funcionan en la aplicación actual de webvise. También explican por qué el desarrollo de MVP para producción incluye despliegue, supervisión y analítica de usuarios en el alcance inicial. El plan de eventos debe resistir las mismas rutas de fallo que el producto.
Defina la activación como valor entregado
La activación registra la primera entrega creíble del valor del producto. Un producto documental puede activarse cuando finaliza un documento válido. Un producto de reservas puede activarse cuando ambas partes reciben la confirmación. La definición depende de la promesa del producto.
PostHog publicó su método de activación el 2025-02-06. Sus equipos prueban grupos de 3 a 5 eventos, comparan 5 a 10 grupos candidatos y comprueban si las cuentas activadas mantienen la retención al cabo de tres meses. Product analytics usa una ventana de activación de 30 días; Experimentation y Feature flags usan 14 días.
| Producto de PostHog | Definición de activación publicada | Plazo |
|---|---|---|
| Experimentation | 1 experimento lanzado | 14 días |
| Feature flags | 2 flags creadas y 2 flags actualizadas con filtros de propiedades | 14 días |
| Product analytics | Primer evento del equipo ingerido, 1 dashboard creado y 3 insights guardados | 30 días |
| Session replay | 5 grabaciones analizadas y 1 filtro de lista de grabaciones modificado | 14 días |
La guía de activación de PostHog también documenta un fallo útil. El evento `recording analyzed` se activaba de forma incorrecta, por lo que la métrica de activación contabilizaba menos equipos con éxito de los que había. PostHog recomienda registrar los eventos críticos de activación en el servidor porque los bloqueadores del navegador pueden impedir que lleguen los eventos del cliente.
Un MVP nuevo rara vez cuenta con suficientes usuarios para demostrar una correlación de retención durante el primer mes. Empiece por el evento más cercano al valor entregado, revise sesiones reales y registre la definición como provisional. Sustitúyala solo cuando una cohorte mayor muestre qué comportamiento predice el uso recurrente.
Use un registro de decisiones de 30 días
Fije la fecha de revisión antes del lanzamiento. Una fecha fija evita que una única sesión llamativa cambie la hoja de ruta de un día para otro, mientras el registro de decisiones impide que un uso escaso derive en otro mes de trabajo en funcionalidades.
| Métrica | Objetivo fijado antes del lanzamiento | Resultado real al día 7 | Resultado real al día 30 | Regla de decisión | Responsable |
|---|---|---|---|---|---|
| Tasa de inicio del flujo de trabajo principal | ___% de los usuarios invitados | ___% | ___% | Corregir la entrada o la incorporación cuando los usuarios invitados nunca empiezan | ___ |
| Tasa de éxito del flujo de trabajo | ___% de los inicios | ___% | ___% | Corregir el paso que bloquea al usuario cuando la intención no llega a convertirse en valor | ___ |
| Tasa de activación | ___% en un plazo de ___ días | ___% | ___% | Mantener o revisar la ruta de activación | ___ |
| Uso recurrente | ___% completa de nuevo el flujo de trabajo | ___% | ___% | Revisar la frecuencia del valor cuando los usuarios que tienen éxito nunca regresan | ___ |
| Resultado comercial | ___ pagos, pilotos o solicitudes cualificadas | ___ | ___ | Continuar, cambiar la oferta o detener | ___ |
Fije los objetivos a partir de la promesa comercial del producto, el acuerdo del piloto o el punto de referencia manual. Los valores de referencia genéricos de activación comparan productos con distintos momentos de valor, fuentes de tráfico, precios y plazos.
Pocos inicios apuntan a la invitación o la incorporación. Los inicios seguidos de errores apuntan a ingeniería. Un uso satisfactorio seguido de silencio plantea una pregunta sobre la frecuencia del valor. El uso repetido sin resultado comercial dirige la revisión hacia el precio, el comprador o la oferta.
Entregue el plan de eventos a quien desarrolla el producto
Incluya el catálogo de eventos en el documento de desarrollo y trate los eventos críticos como criterios de aceptación. Una captura de pantalla del dashboard demuestra poco si no se han probado el momento de los eventos, la identidad y las rutas de fallo.
- Indique el punto de captura. Especifique si el navegador, la ruta de la API, la tarea en segundo plano o el webhook registra cada evento.
- Pruebe el éxito después de la confirmación. El evento de finalización del flujo de trabajo se activa una vez que existe un resultado persistente, nunca al hacer clic por primera vez en el botón.
- Pruebe el fallo de forma deliberada. Fuerce un error de validación, un error del servidor y un tiempo de espera agotado de un servicio externo antes del lanzamiento.
- Verifique la identidad. Los eventos de entrada anónimos deben vincularse al mismo usuario o espacio de trabajo después del registro, sin crear una segunda persona.
- Restrinja las propiedades. Mantenga una lista escrita de ID, categorías, duraciones, versiones y contexto de adquisición aprobado.
- Asigne la revisión. Nombre a la persona que comprobará el estado de los eventos durante el lanzamiento y leerá el registro del día 30.
webvise define el alcance del flujo de trabajo crítico, el catálogo de eventos, la configuración de PostHog, el despliegue y la supervisión dentro de un desarrollo de MVP bien delimitado. Si su primera versión tiene una lista de funcionalidades y carece de un plan de medición, envíe el documento a webvise antes de que los nombres de los eventos queden fijados en el código de producción.