Analítica de producto: medir para decidir, no para acumular

Hay un patrón que se repite con una regularidad casi cómica en equipos de producto. Alguien propone empezar a medir, se integra una biblioteca de analítica, se instrumenta lo que resulta fácil de instrumentar, y en dieciocho meses el proyecto tiene ochocientos eventos de los que cuarenta se consultan alguna vez y ninguno responde a la pregunta que motivó todo aquello. El diagnóstico habitual es que faltaba disciplina. El diagnóstico real es que el orden estaba invertido: se empezó por la instrumentación, que es la parte técnica y por tanto la cómoda, en lugar de por la decisión, que es la parte incómoda porque obliga a admitir que nadie sabe qué se haría con el dato. Esta lección propone recorrer el camino en el sentido correcto y aceptar la consecuencia más contraintuitiva de hacerlo: un plan de medición bueno es notablemente pequeño.

Primero la decisión, después la métrica

La prueba que filtra cualquier propuesta de medición cabe en una frase: qué harías distinto según el resultado. Si la respuesta es nada, o es un vago mirarlo para entender mejor, la métrica no debe existir todavía. No porque la curiosidad esté mal, sino porque cada evento tiene un coste real que se paga durante años: código que mantener, esquema que versionar, almacenamiento, revisión de privacidad, y sobre todo atención humana, que es el recurso genuinamente escaso. Un panel con cuarenta gráficas no informa más que uno con cuatro, informa menos, porque nadie sostiene la atención sobre cuarenta señales y todo el mundo la sostiene sobre cuatro.

De ahí se sigue una jerarquía que conviene explicitar. Arriba, la decisión: mantener o retirar una funcionalidad, invertir o no en un rediseño, elegir entre dos caminos de incorporación. Debajo, la pregunta que la desbloquea: cuántas personas llegan a usar la funcionalidad más de una vez, en qué paso se pierde la gente. Debajo, la métrica que responde esa pregunta con un número comparable. Y solo al fondo, los eventos que hacen falta para calcularla. Recorrer la jerarquía de abajo arriba es lo que produce los ochocientos eventos inútiles; recorrerla de arriba abajo produce un plan pequeño y defendible.

flowchart TD
a[Decision pendiente] --> b[Pregunta que la desbloquea]
b --> c[Metrica comparable en el tiempo]
c --> d[Eventos minimos necesarios]
d --> e[Instrumentacion]
e --> f[Lectura y decision tomada]
f --> g[Retirar el evento si ya no decide nada]

Hay además una distinción de tipos de métrica que evita discusiones estériles. Las métricas de resultado miden lo que de verdad importa —retención a treinta días, ingresos, tareas completadas— pero se mueven despacio y con mucho ruido, de modo que sirven para juzgar una estrategia y no para evaluar un cambio de la semana pasada. Las métricas indicadoras se mueven rápido y correlacionan con las anteriores —activación en el primer día, uso de la funcionalidad clave— y son las que permiten iterar. Y las métricas de contrapeso existen para detectar que estás mejorando una a costa de otra: si la tasa de clics sube mientras la retención baja, has optimizado un titular sensacionalista. Un cuadro de mando honesto lleva siempre las tres categorías.

Un evento con sentido

Un evento bien diseñado responde tres preguntas sin ambigüedad: qué ocurrió, en qué contexto y con qué resultado. Todo lo demás sobra. El nombre describe un hecho consumado en el pasado y en un vocabulario estable, no una intención ni una pantalla: nota_guardada es un hecho, usuario_pulsa_boton_azul es una descripción de la interfaz que dejará de tener sentido en el siguiente rediseño. Esa diferencia parece cosmética y no lo es: los eventos atados a la implementación mueren con cada refactorización y arrastran consigo el histórico, mientras que los eventos atados al dominio sobreviven años y permiten comparar.

Las propiedades son donde se concentra tanto el valor como el riesgo. El valor porque una propiedad bien elegida convierte un evento en diez segmentaciones; el riesgo porque es el lugar donde acaba colándose información personal por acumulación de pequeñas comodidades. La regla que funciona es que las propiedades describen categorías y magnitudes, nunca contenido: el origen de la acción, el tipo de elemento, si había conexión, cuántos elementos había, cuánto tardó. Nunca el texto de la nota, el nombre del archivo ni la consulta de búsqueda.

enum EventoDeProducto {
    case notaGuardada(origen: Origen, longitud: TramoDeLongitud, adjuntos: Int)
    case sincronizacionCompletada(duracion: TramoDeDuracion, resultado: Resultado)
    case suscripcionIniciada(plan: Plan, pantallaDeOrigen: Origen)

    var nombre: String {
        switch self {
        case .notaGuardada: "nota_guardada"
        case .sincronizacionCompletada: "sincronizacion_completada"
        case .suscripcionIniciada: "suscripcion_iniciada"
        }
    }
}

enum TramoDeLongitud: String {
    case corta, media, larga   // tramos, no el valor exacto ni el texto
}

Modelar los eventos como un tipo enumerado en lugar de como cadenas sueltas cambia la naturaleza del problema. Deja de ser posible escribir un nombre con una errata, deja de ser posible enviar una propiedad con el tipo equivocado, y añadir un caso obliga a decidir explícitamente su nombre y sus propiedades en un único lugar que se puede revisar. Es el mismo argumento que se usa para tipar rutas de navegación o identificadores, aplicado al lugar donde nadie lo aplica porque la biblioteca de turno acepta cadenas y diccionarios.

// Una sola puerta de salida: aqui se filtra, se enriquece y se decide
struct Analitica {
    func registrar(_ evento: EventoDeProducto) {
        guard consentimiento.analiticaPermitida else { return }
        let propiedades = evento.propiedades
            .merging(contextoComun) { propia, _ in propia }
        cliente.enviar(nombre: evento.nombre, propiedades: propiedades)
    }
}

El contexto común merece una mención aparte porque es donde se ahorran cientos de líneas. Versión de la aplicación, versión del sistema, familia de dispositivo, idioma, si hay suscripción activa y en qué variante de experimento cae la persona son propiedades que interesan en casi todos los eventos y que deben añadirse en un único punto, jamás en cada llamada. Una única puerta de salida también es lo que hace posible cumplir la promesa de la lección siguiente: si el consentimiento se comprueba en un solo sitio, se puede auditar.

Embudos y cohortes

Dos estructuras de análisis resuelven la mayoría de las preguntas de producto, y se confunden con frecuencia porque ambas se dibujan con barras. El embudo mide conversión: de quienes empezaron un recorrido, qué proporción llegó a cada paso siguiente, dentro de una ventana temporal definida. La cohorte mide permanencia: de quienes hicieron algo por primera vez en una semana determinada, qué proporción seguía haciéndolo una, cuatro y doce semanas después. El embudo diagnostica fricción; la cohorte diagnostica valor. Una funcionalidad puede tener un embudo excelente y una cohorte plana, y eso significa que es fácil de usar y que no le sirve a nadie.

La construcción del embudo tiene una decisión que se toma mal por omisión: la ventana. Si no se declara, las herramientas suelen asumir la sesión, y entonces cualquier recorrido que la gente complete en dos sesiones —comparar precios hoy, comprar mañana— aparece como abandono masivo. Declarar una ventana coherente con la naturaleza de la decisión, que para una compra reflexiva puede ser de siete días, cambia por completo la lectura y a menudo desmonta un pánico injustificado.

En las cohortes el error simétrico es elegir mal el evento de anclaje. Anclar en la instalación mide la eficacia del canal de adquisición; anclar en la primera acción con valor mide la calidad del producto. Son preguntas distintas y la segunda es casi siempre la que el equipo cree estar respondiendo cuando mira la primera. Definir explícitamente qué significa activación en tu producto —la acción mínima tras la cual alguien ha entendido para qué sirve— es probablemente el ejercicio de mayor rendimiento de todo el plan de medición.

Contra la entropía

Un plan de medición no se degrada por una decisión mala sino por doscientas decisiones razonables tomadas sin coordinación. Cada persona añade el evento que necesita, con el nombre que le parece natural y las propiedades que su caso requiere, y al cabo de un año hay tres eventos para el mismo hecho con nombres distintos y una propiedad llamada tipo que en un sitio contiene el tipo de contenido y en otro el tipo de suscripción. La solución no es un comité, que nadie soporta, sino tres mecanismos baratos y automáticos.

El primero es un catálogo único y versionado que es a la vez documentación y fuente de verdad: si el evento no está en el archivo de definiciones, no se puede enviar porque el tipo no compila. El segundo es una convención de nombres escrita en una sola línea, sustantivo del dominio más verbo en participio, y verificada en revisión de código. El tercero es una revisión de retirada periódica, con la misma lógica con la que se retiran indicadores de funcionalidad: cada trimestre se listan los eventos sin ninguna consulta en noventa días y se eliminan salvo justificación explícita.

// Prueba que convierte la convencion en un invariante verificable
func testTodosLosEventosSiguenLaConvencion() {
    for evento in EventoDeProducto.todosLosCasosDeMuestra {
        XCTAssertTrue(evento.nombre.allSatisfy { $0.isLowercase || $0 == "_" || $0.isNumber })
        XCTAssertLessThanOrEqual(evento.propiedades.count, 6)
        XCTAssertFalse(evento.propiedades.keys.contains("nombre"))
    }
}

Queda una fuente de error que ninguna convención resuelve y que produce decisiones equivocadas con más frecuencia que todas las anteriores juntas: la instrumentación silenciosamente rota. Un evento deja de dispararse tras un refactorizado, la métrica cae, y el equipo interpreta la caída como un problema de producto en lugar de como un defecto de medición. La defensa es tratar la propia telemetría como un sistema con salud observable, con alertas sobre variaciones bruscas del volumen de cada evento clave y con una prueba de interfaz que verifique que el recorrido crítico emite lo que debe emitir.