Para analizar el impacto del pago biométrico en la conversión, es necesario realizar una prueba A/B con aleatorización a nivel de usuario. Las métricas clave son: la principal — la tasa de conversión en compras (conversion rate), y las secundarias — el ticket medio, la profundidad del embudo (initiate checkout → payment success), y la retención en el séptimo día. Además, se requiere segmentación por dispositivos (iOS/Android) y cohortes de usuarios nuevos/retornados para identificar el efecto de novedad.
Diseño mínimo del experimento: separación 50/50, duración de al menos 2 ciclos de negocios completos (14 días), potencia del test (power) ≥ 80% y nivel de significancia (alpha) = 5%. Adicionalmente, se construye un análisis de cohortes utilizando SQL para validar la estabilidad del efecto en el tiempo y Python (SciPy, Pandas) para la verificación estadística de la hipótesis de igualdad de proporciones.
Problema:
Una startup fintech planeaba implementar pagos a través de Apple Face ID en su aplicación iOS. El equipo de producto esperaba un aumento del 15% en la conversión, pero la empresa temía los costos de tiempo de desarrollo (2 sprints). La tarea del analista es justificar o refutar la viabilidad de la funcionalidad, excluyendo explicaciones alternativas para el aumento de métricas (estacionalidad, actividades de marketing, actualización de iOS).
Soluciones consideradas:
La primera solución — análisis “antes y después” (pre-post analysis) comparando la conversión en la semana anterior y posterior al lanzamiento. Pros: costos de tiempo mínimos, no requiere aislamiento de usuarios. Contras: no es posible separar el efecto de la funcionalidad de factores externos (por ejemplo, el lanzamiento simultáneo de una campaña publicitaria), alto riesgo de conclusiones falsas positivas.
La segunda solución — un cuasi-experimento utilizando el método Difference-in-Differences (DiD). Se planeaba comparar usuarios de iOS (donde aparecerá Face ID) con usuarios de Android (grupo de control), teniendo en cuenta las tendencias antes de la implementación. Pros: no requiere implementación técnica de división en la aplicación, funciona con datos observables. Contras: la suposición crítica de tendencias paralelas entre plataformas a menudo se rompe debido a las diferentes audiencias de iOS y Android, complejidad en la interpretación cuando hay confusores.
La tercera solución (elegida) — una prueba A/B completa utilizando banderas de características (LaunchDarkly). El 50% de los usuarios de iOS tuvo acceso a Face ID (grupo de prueba), el 50% continuó con el método de pago anterior (control). El cálculo del tamaño de la muestra se realizó en R utilizando la biblioteca pwr: con una conversión base del 8%, un MDE (Minimum Detectable Effect) esperable del 12%, power=0.8 y alpha=0.05, se requerían ≥ 12,000 usuarios por grupo. El experimento duró 3 semanas para cubrir diferentes días de la semana.
Resultado:
La conversión en el grupo de prueba aumentó un 11,3% (de 8,1% a 9,0%), p-value = 0.002 (prueba z bilateral). Sin embargo, el análisis de cohortes mostró que el efecto es estadísticamente significativo solo para nuevos usuarios (+18%), mientras que para los usuarios actuales no se registraron cambios en la base. Como resultado, se decidió implementar la funcionalidad para el 100% de la audiencia, pero los materiales de marketing se reorientaron hacia la atracción de nuevos usuarios, lo que aumentó el ROI del proyecto en un 40% en comparación con el modelo inicial.
¿Cómo diferenciar el efecto de novedad (novelty effect) de la mejora sostenida de las métricas?
Los candidatos a menudo concluyen la prueba A/B al alcanzar la significancia estadística, sin verificar la sostenibilidad del efecto. Para identificar el efecto de novedad, es necesario construir curvas acumulativas de métricas por días y realizar un análisis de heterogeneidad: comparar el efecto en los primeros 3 días con el efecto en la última semana. Utilice análisis de cohortes en SQL: divida el tráfico por días de ingreso al experimento (cohort_date) y verifique si se mantiene el uplift para las cohortes “viejas”. Si el efecto disminuye con el tiempo, esto es un efecto de novedad clásico: los usuarios inicialmente prueban la funcionalidad por curiosidad, pero no cambian su comportamiento a largo plazo.
¿Cuál es la diferencia entre la significancia estadística (statistical significance) y la significancia práctica (practical significance) en el análisis de productos?
Con muestras grandes, incluso un aumento del 0,5% en la conversión puede ser estadísticamente significativo (p < 0,05), pero irrelevante para el negocio si el costo de mantener la funcionalidad supera los ingresos de las compras adicionales. Antes de lanzar un experimento, es necesario definir el MDE (Minimum Detectable Effect) — el tamaño mínimo del efecto que tiene valor comercial. Se calcula como (Expected Revenue per Conversion × Additional Conversions) — Cost of Feature. Si el uplift real es inferior al MDE, incluso con p-value = 0,01, no se debe implementar la funcionalidad. Para el cálculo, utilice Python (statsmodels.stats.power) o calculadoras en línea de Evan Miller.
¿Cómo manejar la situación cuando un usuario ve la funcionalidad, pero no puede usarla (efecto de red o fallo técnico en uno de los grupos)?
Este es un problema de contaminación o efecto de derrame. Un ejemplo clásico: en el grupo de prueba se habilitó el pago en criptomonedas, pero el proveedor de servicios estuvo indisponible el 30% del tiempo. El análisis de “intención de tratar” (intent-to-treat, ITT) evalúa el efecto sobre todos a quienes se les mostró el botón, independientemente del hecho de uso. Para mantener la pureza de la evaluación, aplique el método CACE (Complier Average Causal Effect) o instrumental variables (variables instrumentales), donde “asignación en grupo” sirve como instrumento para el uso real de la funcionalidad. En SQL se implementa a través de regresión de dos etapas o a través de JOIN con registros de operaciones reales, excluyendo a los usuarios con errores del servidor del análisis de efectividad, pero manteniéndolos en la aleatorización original para verificar el balance de grupos.