Conversiones y revenue
Registrar compras sin contarlas dos veces.
Una conversión es el objetivo que decide si una variante gana. Registrarla mal invalida el experimento entero, así que estos detalles importan.
Registrar una conversión
GrowthLab.conversion('purchase', {
value: 129900,
currency: 'MXN',
orderId: '1042',
});
value en unidades mínimas
129900 = $1,299.00 MXN.
El importe viaja como entero en centavos por dos razones:
- Precisión. Los flotantes acumulan error. Sumar
29.99un millón de veces no da29990000.00. - Ambigüedad.
1299podría ser $12.99 o $1,299.129900con la convención declarada no admite duda.
El error más común es enviar decimales:
// MAL: reporta 30 centavos
GrowthLab.conversion('purchase', { value: 29.99, currency: 'MXN' });
// BIEN
GrowthLab.conversion('purchase', { value: 2999, currency: 'MXN' });
Si tu fuente da decimales, convierte con Math.round(valor * 100).
orderId evita duplicados
Dos conversiones con el mismo orderId se colapsan en una.
Sin él, cada uno de estos casos infla tu revenue:
- El visitante recarga la página de agradecimiento.
- Vuelve atrás y adelante en el historial.
- Un gestor de etiquetas dispara la etiqueta dos veces.
- El SDK reintenta el envío tras un fallo de red.
Usa el identificador real del pedido. Si no lo tienes, cualquier valor estable por transacción sirve.
Objetivos
Un experimento puede tener varios objetivos. Uno es primario y decide el resultado; el resto son secundarios o guardrails.
| Tipo | Qué mide |
|---|---|
conversion |
Un evento de conversión con nombre |
revenue |
Revenue por visitante |
click |
Clic en un selector |
pageview |
Llegada a una URL |
custom |
Un evento personalizado |
engagement |
Tiempo de interacción |
Guardrails
Un guardrail bloquea el envío aunque el objetivo primario gane.
El caso típico: una variante sube la tasa de conversión un 8% pero baja el revenue por visitante un 12%, porque atrae compras más pequeñas. Enviarla sería una pérdida real de dinero presentada como una victoria.
Growth Lab evalúa automáticamente un guardrail sobre revenue por visitante con umbral del −2%. Si se incumple, el resultado es inconclusive con guardrail_breach entre los bloqueadores, nunca winner.
Cómo se cuentan
- El denominador son visitantes únicos expuestos, no vistas de página. Un visitante que vio la variante en cinco páginas es un visitante.
- El numerador son visitantes que convirtieron, no conversiones. Alguien que compra dos veces cuenta una vez para la tasa de conversión.
- El revenue sí suma todas las conversiones, porque ahí el total es lo relevante.
Esta distinción evita que un cliente muy activo distorsione la tasa.
Análisis
Conversión: Beta-Binomial
Se calcula una posterior Beta por variante y se comparan por Monte Carlo con semilla fija. Los resultados:
- Probabilidad de superar al control.
- Probabilidad de ser la mejor de todas.
- Intervalo creíble al 95% sobre la tasa.
- Uplift relativo esperado y su intervalo.
- Pérdida esperada: cuánto arriesgas si eliges esa variante y te equivocas.
Se usa un enfoque bayesiano y no un p-valor porque estas herramientas se consultan constantemente, y un p-valor solo es válido a un tamaño de muestra comprometido de antemano. Las probabilidades posteriores siguen siendo interpretables bajo monitorización continua.
La semilla es fija para que el mismo dato dé siempre el mismo número. Un panel que muestra 94.8% y al recargar 95.1% destruye la confianza en la cifra, aunque ambas estén dentro del error de simulación.
Revenue: bootstrap
El revenue por visitante es una distribución con muchos ceros y cola larga: casi nadie compra y unos pocos gastan mucho. Un t-test sobre eso tiene una cobertura muy incorrecta a tamaños reales, así que se remuestrea.
El bootstrap resamplea visitantes, no pedidos. Remuestrear solo pedidos estimaría la varianza del ticket medio e ignoraría por completo la componente de tasa de conversión.
Sample Ratio Mismatch
Si un experimento 50/50 entrega 52/48 a escala, la asignación o el registro de exposición está roto, y toda métrica derivada es sospechosa por muy significativa que parezca.
El SRM es un bloqueo, no un aviso. Se usa un chi-cuadrado con α = 0.001 en lugar de 0.05 porque el test corre continuamente sobre cada experimento: a 0.05, uno de cada veinte experimentos sanos daría una falsa alarma y la señal dejaría de tomarse en serio.