12 — Analytics y métricas — SURCO
1. Propósito
Definir qué medir para validar el cuaderno multi-rol.
v1 implementa stats de dominio (GET /api/tasks/stats/summary) y deja el plan de producto analytics listo; no requiere un vendor concreto (Plausible/GA/etc.) para cerrar el L2.
No se inventan tasas de conversión reales: instrumentar en post-MVP; las cifras de producto son objetivos de modelo, no resultados medidos de campo.
2. North Star y métricas de producto
| Nivel | Métrica | Definición | Fuente |
|---|
| North Star | Tareas DONE / semana (por explotación activa) | Cierres reales de trabajo de campo | DB status + fecha updatedAt (futuro) |
| Activación | % logins FARMER que crean ≥1 tarea en 24 h | Funnel auth → create | eventos + API |
| Asignación | % creates con technicianEmail válido | Delegación | POST body / status ACTIVE |
| Adopción técnico | % técnicos con ≥1 patch status / semana | Engagement campo | PATCH logs |
| Operativa | Mediana horas PENDING→DONE | Velocidad de cierre | timestamps |
| Fiabilidad | Tasa error 5xx / 4xx en tasks | Salud API | logs server |
3. Funnel UX (modelo)
Home view → Login submit → Login success → List view → Create start → Create success → Status DONE
| Paso | Evento sugerido | Props |
|---|
| home_view | page | path=/ |
| login_submit | form | — |
| login_success | auth | role |
| login_fail | auth | reason=401 |
| tasks_list_view | page | role, total |
| task_create_open | nav | — |
| task_create_submit / success | api | has_technician |
| task_create_fail | api | code |
| task_open | page | id, status |
| task_status_change | api | from, to, role |
| task_status_done | api | subset cuando to=DONE |
| week_active | derived | ≥1 login en 7d (retención) |
4. Stats in-product (implementado)
GET /api/tasks/stats/summary devuelve:
| Campo | Significado |
|---|
total | Tareas visibles al rol |
open | PENDING + ACTIVE |
byStatus.* | Conteos por enum |
UI: tiles TOTAL / ABIERTAS / ACTIVAS / HECHAS en lista.
Limitación: no es serie temporal; es snapshot del scope del usuario.
5. Segmentos
| Segmento | Clave |
|---|
| Rol | FARMER / TECHNICIAN |
| Con/sin técnico | technicianId null vs set |
| Parcela | parcelId / name |
| Antigüedad tarea | dueAt vs now (overdue futuro) |
6. Privacidad en medición
| Regla | Detalle |
|---|
| No enviar password ni token a analytics | |
| Preferir id interno opaco a email en eventos | |
| Notas de tarea: no como propiedad de evento | pueden contener info sensible de finca |
| IP: minimización / retención corta si hay vendor | |
| Demo: analytics opcional desactivable | |
7. Tablero ops (hipótesis de lectura)
- Operación semanal: DONE, open, ACTIVE.
- Funnel activación FARMER.
- % con técnico asignado.
- Salud API: latencia p95 login/list/create.
- Empty rate post-login (usuarios sin tareas).
8. Alertas (modelo)
| Condición | Severidad |
|---|
| Error rate create > 5% 15m | Alta |
| Login fail spike | Media (posible ataque o seed mal) |
| 0 DONE en 7 días con ACTIVE>0 | Baja producto |
9. Lo que no medimos en v1
- Heatmaps
- Session replay
- A/B testing
- Attribution marketing multi-canal
- Tasas de conversión inventadas presentadas como reales
10. Enlace a hipótesis (doc 02)
| Hipótesis | Métrica de esta doc |
|---|
| H1 lista compartida reduce fricción | ↓ llamadas (cualitativo) + DONE/semana |
| H2 asignar tech acelera ACTIVE | % creates con technician |
| H3 códigos SU- útiles oralmente | (cualitativo futuro) |
11. Criterios de aceptación
- Stats summary coherente con conteo de lista del mismo usuario.
- Documentado el North Star y funnel aunque el vendor no esté cableado.
- Ningún evento planeado incluye contenido libre de
notes.
- Hipótesis H1–H3 enlazan a métricas de esta doc.
- Sin stats de mercado falsas en el case.
