Efecto novedad y p-hacking

Descripción

Las últimas dos trampas del módulo comparten un mismo villano: el momento en el que decides mirar, o cómo decides analizar, después de que los datos ya existen. El efecto novedad (novelty effect) es el fenómeno donde el lift de un cambio nuevo aparece inflado justo después del lanzamiento —porque los usuarios lo notan, lo prueban, sienten curiosidad— y después se desinfla, a veces por completo, a medida que el cambio se vuelve parte de la rutina normal del producto. El p-hacking es la práctica —casi siempre no deliberada— de ajustar cómo analizas los datos después de verlos, probando distintas definiciones de métrica, distintas ventanas de fecha, o distintos cortes, hasta encontrar alguno que cruce el umbral de significancia.

Los dos fenómenos son distintos en su origen —uno es sobre el comportamiento real de los usuarios en el tiempo, el otro sobre las decisiones del analista—, pero comparten el mismo peligro práctico: ambos pueden hacer que un número que reportas como "el resultado del experimento" sea, en realidad, uno entre varios números posibles que los mismos datos podrían haber producido, elegido —consciente o inconscientemente— porque es el que mejor se ve.

Conexión con el módulo. El efecto novedad conecta directamente con el peeking de la lección 4: si miras el experimento temprano —durante el período de novedad— y ese es el momento en el que decides parar, el lift que reportas está doblemente contaminado, por el peeking y por la novedad juntos. El p-hacking, por su parte, es la versión "en un solo análisis" de las comparaciones múltiples de la lección 5 — en vez de probar diez métricas distintas, pruebas diez formas distintas de analizar la misma métrica, hasta que una da el resultado que buscabas.

Dos analogías: el restaurante nuevo, y el tirador que dibuja el blanco después de disparar

El efecto novedad — el restaurante que abre en la cuadra. Cuando un restaurante nuevo abre, las primeras semanas suele estar lleno: la gente del barrio quiere probarlo, hay curiosidad, hasta hace fila. Si midieras la popularidad del restaurante solo en esas primeras semanas, concluirías que es un éxito extraordinario, con una demanda que va a sostenerse indefinidamente. Pero un mes después, cuando la novedad se agota, la asistencia se asienta en un nivel más bajo y más estable — el nivel real que refleja cuánto le gusta el restaurante a la gente una vez que dejó de ser "lo nuevo de la cuadra". Ese nivel estable, no el pico inicial de curiosidad, es el número que de verdad importa para decidir si el restaurante es sostenible a largo plazo.

El p-hacking — el tirador que dibuja el blanco después de disparar. Imagina a alguien que dispara una ráfaga de balas contra la pared de un granero, sin apuntar a nada en particular, y después camina hasta la pared, encuentra el grupo de agujeros más apretado, y pinta un blanco alrededor de ese grupo — declarándose, con el blanco recién pintado, un tirador de precisión excepcional. La trampa no está en las balas ni en la pared: está en dibujar el objetivo después de ver dónde cayeron los disparos, en vez de fijarlo antes de disparar. El p-hacking hace exactamente esto con el análisis de datos: en vez de fijar de antemano cómo vas a medir el resultado (la métrica primaria, la ventana de fechas, el corte de datos), pruebas varias formas distintas hasta que una "acierta" en el blanco de la significancia — y solo entonces la presentas como si siempre hubiera sido el plan.

Ejemplo trabajado: el lift semanal ilustrativo de recommendations

Con datos fijos y declarados —no medidos, un caso pedagógico construido para mostrar el patrón con claridad—, así se hubiera visto el lift de recommendations, semana a semana, si se hubiera medido de forma no acumulada en vez de esperar las 6 semanas completas del protocolo del módulo 5:

// weeklyLift: valores ILUSTRATIVOS y fijos (no medidos) de como se hubiera
// visto, semana a semana, el lift de recommendations si se midiera de forma
// no acumulada -- para ilustrar el efecto novedad. El valor de la semana 6
// coincide, a proposito, con el lift real y estable que ya conoces de los
// modulos 5 y 6 (+18.75%): 6 semanas completas fue tiempo suficiente para
// que el efecto novedad se disipara antes de medir el resultado final.
const weeklyLift = [
  { week: 1, lift: 0.350 },
  { week: 2, lift: 0.280 },
  { week: 3, lift: 0.230 },
  { week: 4, lift: 0.200 },
  { week: 5, lift: 0.190 },
  { week: 6, lift: 0.1875 },
];

console.log('=== Efecto novedad: lift semanal ilustrativo de recommendations ===\n');
weeklyLift.forEach((row, i) => {
  const prev = i > 0 ? weeklyLift[i - 1].lift : null;
  const change = prev !== null ? ((row.lift - prev) * 100).toFixed(2) + ' pts' : '--';
  console.log('semana ' + row.week + ':  lift=' + (row.lift * 100).toFixed(2) +
    '%   cambio vs semana anterior: ' + change);
});
console.log('\nEl lift se ESTABILIZA en la semana 6 (+18.75%) -- exactamente el numero');
console.log('real que calculaste en los modulos 5 y 6, midiendo sobre las 6 semanas completas.');

// La MISMA tabla, para ilustrar p-hacking: que hubiera pasado si alguien,
// DESPUES de ver los datos, "eligiera" reportar la semana mas conveniente
// en vez de la ventana completa pre-registrada en el protocolo del modulo 5.
console.log('\n=== p-hacking: que hubiera pasado si "elegias" la semana mas conveniente ===\n');
console.log('Metrica y ventana pre-registradas (protocolo del modulo 5): 6 semanas completas.');
console.log('lift reportado con el protocolo correcto: +' + (weeklyLift[5].lift * 100).toFixed(2) + '%\n');
console.log('Si en cambio alguien eligiera que semana reportar DESPUES de ver los datos:');
weeklyLift.forEach((row) => {
  const line = '  reportando solo semana ' + row.week + ':  lift = +' + (row.lift * 100).toFixed(2) + '%';
  console.log(row.week === 1 ? line + '  <- el numero mas favorable, y el mas enganoso' : line);
});

Qué esperar. Al correr el archivo con Node, la salida es exactamente esta:

=== Efecto novedad: lift semanal ilustrativo de recommendations ===

semana 1:  lift=35.00%   cambio vs semana anterior: --
semana 2:  lift=28.00%   cambio vs semana anterior: -7.00 pts
semana 3:  lift=23.00%   cambio vs semana anterior: -5.00 pts
semana 4:  lift=20.00%   cambio vs semana anterior: -3.00 pts
semana 5:  lift=19.00%   cambio vs semana anterior: -1.00 pts
semana 6:  lift=18.75%   cambio vs semana anterior: -0.25 pts

El lift se ESTABILIZA en la semana 6 (+18.75%) -- exactamente el numero
real que calculaste en los modulos 5 y 6, midiendo sobre las 6 semanas completas.

=== p-hacking: que hubiera pasado si "elegias" la semana mas conveniente ===

Metrica y ventana pre-registradas (protocolo del modulo 5): 6 semanas completas.
lift reportado con el protocolo correcto: +18.75%

Si en cambio alguien eligiera que semana reportar DESPUES de ver los datos:
  reportando solo semana 1:  lift = +35.00%  <- el numero mas favorable, y el mas enganoso
  reportando solo semana 2:  lift = +28.00%
  reportando solo semana 3:  lift = +23.00%
  reportando solo semana 4:  lift = +20.00%
  reportando solo semana 5:  lift = +19.00%
  reportando solo semana 6:  lift = +18.75%

Fíjate en dos cosas a la vez en esta salida. Primero, el efecto novedad: el lift cae de 35.00% en la primera semana a 18.75% en la sexta, una caída de casi la mitad, estabilizándose recién hacia el final — si el equipo hubiera hecho peeking (lección 4) en la semana 1 y hubiera parado ahí, habría reportado un lift casi el doble del real, sostenible, de largo plazo. Segundo, el p-hacking: la misma tabla de datos, mirada con "libertad" para elegir qué semana reportar, ofrece seis números distintos —de 18.75% a 35.00%—, y quien buscara el resultado más impresionante, sin ningún compromiso previo con la ventana de 6 semanas, tendría toda la tentación de "elegir" la semana 1. El protocolo del módulo 5 —comprometerse con la ventana completa antes de ver un solo dato— es exactamente lo que impide esa elección después del hecho.

Por qué el efecto novedad es peligroso incluso sin mala intención

Vale la pena aclarar algo importante: el efecto novedad no es una trampa que alguien "hace" — es un fenómeno real del comportamiento humano frente a cualquier cambio visible en un producto. Un carrusel nuevo de recomendaciones genuinamente atrae más clics en sus primeros días, simplemente porque es nuevo y llama la atención, sin que eso implique que vaya a seguir generando ese mismo nivel de interés para siempre. El peligro no está en que el efecto novedad exista —existe, y es esperable—, sino en confundir el número inflado del arranque con el efecto permanente que vas a tener una vez que el producto ya es parte de la rutina. La única forma confiable de separar un efecto real y sostenido de un efecto novedad pasajero es exactamente lo que hizo el protocolo del módulo 5: correr el experimento el tiempo suficiente —6 semanas, no unos días— para que la curiosidad inicial tenga tiempo de disiparse antes de medir el resultado que de verdad vas a usar para decidir.

Errores comunes

Medir el resultado de un lanzamiento en sus primeros días y reportarlo como el efecto permanente. Qué pasa: alguien mira el desempeño de recommendations en su primera semana, ve un lift de 35% (según la tabla ilustrativa de hoy), y lo comunica como "el impacto de recommendations", sin esperar a que la curiosidad inicial se asiente. Por qué pasa: un número alto y temprano es emocionante de compartir, y esperar semanas adicionales para confirmarlo se siente como una demora innecesaria cuando el resultado "ya se ve" bien. Cómo detectarlo: el número reportado proviene de una ventana mucho más corta que la que el protocolo original había definido (en este caso, 6 semanas). Cómo corregirlo: como muestra la tabla de hoy, el lift de la primera semana puede ser casi el doble del valor estable de largo plazo — respeta siempre la ventana completa pre-registrada en el protocolo (módulo 5), precisamente para dejar que el efecto novedad se disipe antes de medir.

Ajustar la definición de la métrica, el corte de fechas, o el segmento de usuarios después de ver que el resultado inicial no era significativo. Qué pasa: el análisis original de recommendations sobre la ventana completa no muestra el resultado que el equipo esperaba, y alguien prueba, uno tras otro, distintos recortes —solo usuarios que compraron antes, solo la segunda mitad del periodo, una definición alternativa de "conversión"— hasta encontrar uno que sí cruza p<0.05. Por qué pasa: cada uno de esos recortes, aislado, suena razonable —"tiene sentido excluir a los usuarios nuevos", "tiene sentido mirar solo el estado estable"—, y es fácil no notar que se están probando muchas variantes del mismo análisis hasta encontrar la que "funciona". Cómo detectarlo: el análisis final usa una definición de métrica, ventana o segmento que no coincide con la que el protocolo había fijado antes de correr el experimento, y nadie puede explicar por qué cambió. Cómo corregirlo: como en la analogía del tirador de hoy, el blanco —la métrica, la ventana, el segmento de análisis— se dibuja antes de disparar, en el protocolo (módulo 5), no después de ver dónde cayeron los datos. Cualquier análisis adicional después del hecho se declara explícitamente como exploratorio, nunca como confirmación.

Confundir "el efecto se desvaneció" con "el efecto nunca fue real". Qué pasa: al ver que el lift bajó de 35% en la semana 1 a 18.75% en la semana 6, alguien concluye que recommendations "dejó de funcionar" o que el resultado original "era falso". Por qué pasa: una caída tan pronunciada se siente, a primera vista, como evidencia de que algo estaba mal desde el principio, en vez de un patrón esperado y bien documentado. Cómo detectarlo: la conclusión trata el número de la semana 1 como "la verdad" y el de la semana 6 como una "pérdida", en vez de reconocer que 18.75% es el número estable y confiable, mientras que 35% fue temporal desde el principio. Cómo corregirlo: como explica esta lección, un lift que se estabiliza en un valor más bajo después de las primeras semanas no es un fracaso — es exactamente lo que un efecto novedad bien entendido predice. El número que importa para decidir si recommendations se queda en producción es el estable (18.75%, el mismo de los módulos 5 y 6), no el pico inicial de curiosidad.

Ejercicios

Ejercicio 1 — Identifica el efecto novedad en un escenario nuevo. Mercado lanza un rediseño de la página de inicio, y mide un lift de checkoutConversionRate de +40% en la primera semana. Un mes después, el lift estable es de +6%. ¿Qué le dirías al equipo que quiere reportar el +40% como "el impacto del rediseño"?

Ver solución

El +40% de la primera semana es casi con seguridad un efecto novedad —la curiosidad inicial de los usuarios frente a una página que se ve distinta—, no el impacto sostenible del rediseño. El número que de verdad importa para decidir si el rediseño vale el costo de mantenerlo es el +6% estable, medido después de que la novedad se disipó, exactamente como el lift de recommendations se estabilizó en +18.75% después de la semana 1 en la tabla de esta lección. Reportar el +40% sería repetir el primer error común de esta lección: confundir el pico inicial con el efecto permanente.

Ejercicio 2 — Detecta el p-hacking en un reporte. Un reporte dice: "Probamos el efecto de recommendations sobre checkoutConversionRate usando tres ventanas distintas —2 semanas, 4 semanas y 6 semanas— y reportamos la de 2 semanas porque fue la única que dio p<0.05." ¿Qué está mal en este reporte, usando el vocabulario de esta lección?

Ver solución

Este es un caso de p-hacking: el reporte prueba tres ventanas de análisis distintas y elige reportar la que "funcionó", en vez de comprometerse de antemano con una sola ventana (el protocolo del módulo 5 ya había fijado 6 semanas). Es exactamente la analogía del tirador que dibuja el blanco después de disparar: probar tres opciones y reportar solo la ganadora no es un análisis honesto de una hipótesis pre-registrada, es una búsqueda de cuál de varias opciones, por azar o por efecto novedad, cruzó el umbral de significancia. Además, la ventana de 2 semanas es particularmente sospechosa porque, según la tabla de hoy, es exactamente la ventana más contaminada por el efecto novedad.

Ejercicio 3 — Diseña la regla que hubiera evitado ambos errores. En 2-3 frases, redacta la regla de protocolo que el equipo de Mercado debería seguir para evitar, a la vez, el efecto novedad y el p-hacking en cualquier experimento futuro.

Ver solución

Una regla razonable: "Antes de lanzar cualquier experimento, el protocolo debe fijar por escrito la ventana de análisis completa (suficientemente larga para que cualquier efecto novedad se disipe, como las 6 semanas del protocolo del módulo 5) y la definición exacta de la métrica primaria. El resultado que se reporta como oficial es siempre el de esa ventana y esa métrica, tal como se pre-registraron — cualquier análisis adicional con otras ventanas, cortes o definiciones se etiqueta explícitamente como exploratorio y nunca reemplaza al resultado pre-registrado." Esta regla ataca las dos trampas con el mismo mecanismo: comprometerse de antemano con el diseño del análisis, exactamente como el protocolo completo del módulo 5 ya hacía con control, variant, H0 y la métrica primaria.

Resumen y siguiente paso

En esta lección cerraste el catálogo de trampas del módulo con dos más, ambas relacionadas con el momento y la forma en que analizas los datos. El efecto novedad, ilustrado con la tabla semanal de recommendations, mostró cómo un lift puede caer de 35% en la primera semana a un valor estable de 18.75% —el mismo número real de los módulos 5 y 6— a medida que la curiosidad inicial de los usuarios se disipa. El p-hacking, ilustrado con la misma tabla, mostró cómo "elegir" qué ventana o definición reportar después de ver los datos puede producir prácticamente cualquier número que quieras, entre 18.75% y 35%, sin que ninguno sea más "verdadero" que el que el protocolo original había pre-registrado.

Antes de avanzar deberías poder: explicar por qué el lift de los primeros días de un lanzamiento suele estar inflado por el efecto novedad; reconocer un caso de p-hacking cuando un reporte prueba varias definiciones o ventanas y reporta solo la ganadora; y explicar por qué comprometerse de antemano con la ventana de análisis y la definición de la métrica evita ambas trampas a la vez.

Con esto completas las siete lecciones conceptuales del módulo: sabes calcular cuánta muestra necesitas antes de correr un experimento (lecciones 2-3), y conoces las cinco trampas que pueden hacerte creer que un efecto es real cuando no lo es, o esconder uno que sí lo es (lecciones 4-7). La lección 8, el mini-proyecto, te pone a aplicar todo esto de punta a punta: dimensionar el A/B test de recommendations desde cero, y auditar el resultado real de los módulos 5 y 6 en busca de cada una de estas cinco trampas.

Recursos

• Ron Kohavi y Stefan Thomke, "The Surprising Power of Online Experiments" (Harvard Business Review, sept-oct 2017) — hbr.org/2017/09/the-surprising-power-of-online-experiments. Los mismos autores de referencia de esta guía discuten el efecto novedad (y el efecto primacía, su contraparte) como uno de los riesgos más comunes al interpretar resultados de experimentos recién lanzados. En inglés.
• Wikipedia, "Data dredging" — en.wikipedia.org/wiki/Data_dredging. El nombre técnico completo del p-hacking: probar muchas formas de analizar los mismos datos y reportar solo la que produce un resultado significativo, ignorando el problema de comparaciones múltiples que eso implica (lección 5). En inglés.
• Statsig, "Confused about p-values and hypothesis testing? Let's play a game..." — statsig.com/blog/p-values-and-hypothesis-testing. Explica con ejemplos accesibles por qué ajustar el análisis después de ver los datos —incluso con buenas intenciones— produce resultados que no se pueden interpretar con el mismo rigor que un análisis pre-registrado. En inglés.