Ex-iAdvize (2018–2024). Independiente desde marzo de 2024. Diseñé el framework de testing del book de push porque nadie en la oficina se había parado a preguntar si el creativo 'ganador' se había declarado ganador con n=180 o con n=8.000. La respuesta, deprimentemente a menudo, era la primera. Escribo aquí para publicar las tablas como se debe: con sample size e intervalo de confianza, no con el titular redondeado.
Autor
Diego Morales
Consultor de testing de push notifications (ex-iAdvize)
Soy Diego. Pasé seis años dentro de iAdvize (2018–2024) corriendo programas de creative-testing para anunciantes tier-1 en iGaming, finanzas y utility, en EU y LATAM. Me fui en marzo de 2024 para publicar las tablas que nadie más publica: las reales, con tamaño de muestra y intervalo de confianza, no los titulares redondeados.
Entre 2019 y 2024 corrí 4.322 tests A/B/n en anuncios push. La base de datos es mía y la sigo consultando cada semana. Probamos 1.847 creativos solo en 2025. Si te digo que un creativo ganó, te puedo enseñar la curva diaria, el sample size por arm y el p-valor exacto del corte final.
Un test de CTR en push exige n≥1,200 por arm para detectar un lift del 15% con CI 95% sobre un baseline del 2%. Eso es mínimo. Cuando leas en este sitio que algo 'ganó', vas a encontrar siempre cuatro datos: GEO+vertical, ventana del test, sample size por arm, y el p-valor. Si falta uno, no es un resultado — es una anécdota con tabla.
Es la frase que más uso. Un creativo puede ganarle a otro con p<0.05 y, aun así, no mover el revenue del partner ni un peso porque el lift en CR es del 0.4% sobre un volumen mínimo. Marcar esos casos es la mitad del trabajo. La otra mitad es matar tests que se ven 'bonitos' a n=200 antes de que un media buyer los escale a presupuesto serio.
Honestidad estadística antes que prisa comercial. Nombrar a los competidores cuando aplique, con datos al lado. Anti-peeking — no se mira el test hasta que llega al sample size pre-registrado. Y reconocer en público cuando un test que diseñé yo salió mal.
Un resultado de push no es 'ganó' o 'perdió'. Es un lift con un sample size, un intervalo de confianza y un p-valor, en un GEO y un vertical, durante una ventana concreta. Estos son los cuatro pasos que aplico antes de llamar ganador a un creativo — los mismos que aplicaba dentro y que casi nadie aplicaba.
Un test de CTR en push exige n≥1.200 por arm para detectar un lift del 15% con CI 95% sobre un baseline del 2%. El número se calcula antes de empezar y se pre-registra. Lo que la mayoría llama 'best practice' es una anécdota con tabla: un creativo que 'ganó' a n=200 y perdió a n=5.000.
Parar un test cuando los datos 'se ven bien' es p-hacking, y se ve en cuanto repites el experimento. No se mira el resultado hasta que llega al sample size pre-registrado. Tuve clientes que me pidieron parar un test ganador 'demasiado pronto' — esa es justo la decisión que invalida el dato.
El CTR de push varía 5x por GEO y 3x por navegador: Chrome desktop puede convertir al triple de Chrome mobile con el mismo creativo. "CTR estándar del sector" no significa nada. Cada tabla que publico lleva GEO+vertical, navegador y dispositivo, porque la media agregada esconde justo la información que sirve.
Un creativo puede ganar con p<0.05 y no mover el revenue del partner ni un euro porque el lift en CR es del 0,4% sobre un volumen mínimo. Marco esos casos explícitamente. Y vigilo la curva de fatiga: el CTR de push cae alrededor de un 6,4% por día a partir del día 7, algo que casi nadie grafica porque casi nadie corre tests tan largos.
Cada resultado lleva n y CI. "El CTR subió un 18% (n=2.400 por arm, CI 95%, p=0,012)" no "el CTR subió". Una ronda de 'creativos ganadores' construida sobre tests con n<500 por arm no se publica — es ruido estadístico con diseño bonito.
Adsterra, PropellerAds, RichAds, Adcash, Monetag. Cuando el panel de CTR de una red reporta cifras infladas frente a lo que ve Voluum en la misma campaña, lo digo con el número. Nunca [Red A], nunca evasivas.
El test corre entre dos fechas fijadas de antemano, sobre un sample size calculado de antemano. No se mira antes. El p-hacking por peeking es la forma más común de declarar ganador a un creativo que no lo es.
Honestidad estadística antes que prisa comercial. Si diseñé un test mal, lo digo. La credibilidad de una tabla viene de que su autor admita las que no funcionaron, no de que las esconda.
Start today
Sigo consultando para anunciantes que necesitan revisar sus conclusiones de significancia, y sigo corriendo mis propios tests de push para mantener la base de datos al día. Si tienes un test que no cuadra, un panel que reporta CTR sin decir si es pre o post frequency-cap, o crees que me equivoqué en un número, escríbeme a [email protected].