Comprar tráfico publicitario: 50K USD/mes sin sorpresas

1. El contexto del caso — y por qué te lo cuento con números

Soy Diego. He corrido 4.322 tests A/B/n en push notification ads. Lo que sigue no son opiniones — son datos.

Entre enero y marzo de 2026 gestioné un budget mensual de aproximadamente 50.000 USD para un cliente tier-2 de iGaming con foco en LATAM (México, Colombia, Chile) y dos países EU (España, Italia). El cliente no es público — firmé NDA — pero los números que sigo son los míos: las hojas de cálculo de allocation, los resultados por sub-ID, los postbacks reconciliados contra Voluum. Todo lo que verás en este post es reproducible con tu propia data si trabajás en el mismo rango de spend.

Te cuento esto porque “comprar tráfico publicitario” como búsqueda en Google devuelve dos tipos de contenido: tutoriales para principiantes que jamás manejaron más de 200 USD/día, y posts de agencias que prometen “+47% lift” sin sample size adjunto. Ninguno de los dos sirve cuando estás manejando spend real. El gap es lo que voy a llenar acá.

El caso tiene cinco capas que vale la pena enumerar antes de meternos en la operación:

Capa 1 — el budget. 50.000 USD/mes promediados sobre 90 días Q1 2026. La variancia diaria está entre 1.200 y 2.400 USD/día dependiendo de fines de semana iGaming (los sábados pesan más en LATAM, los domingos en EU). El spend total Q1 fue 152.840 USD, ligeramente por encima del target porque febrero tuvo dos torneos de fútbol que justificaron un push de 8.000 USD adicional sobre baseline.

Capa 2 — los verticals. Cuatro: iGaming sportsbook (52% del spend), iGaming casino slots (24%), finanzas (préstamos personales LATAM, 16%), y utility/VPN install (8%). Los pesos no son aleatorios. Vienen de un análisis de payback period del cliente — sportsbook paga back en día 4–7 promedio, casino en día 12–18, finanzas en día 21–30, utility install en día 1 pero con LTV bajo. El allocation refleja velocidad-de-recupero más que márgenes brutos.

Capa 3 — los networks. Tres: PropellerAds, RichAds y adsy.tech. La elección de los tres networks tiene una razón específica que vamos a desarrollar — no es porque sean “los mejores” sino porque son los tres que en mi auditoría Q1 2025 de panel-to-Voluum reconciliation entregaron gaps manejables (PropellerAds 8–18%, RichAds 12–28%, adsy.tech 4–8%). Ningún network reporta CTR exactamente igual a Voluum. Lo que importa es que el gap sea estable y predecible, no que sea cero.

Capa 4 — los sub-IDs. 12 sub-IDs distribuidos entre los 3 networks. Cada sub-ID es una combinación específica de GEO + browser + device + creative-family + bid-strategy. No son 12 campañas — son 12 unidades de análisis. La diferencia importa: una campaña puede tener 6 sub-IDs adentro, pero cada sub-ID se evalúa de manera independiente para decisiones de scaling o kill.

Capa 5 — el reporting cadence. Day-1 reads para alertas de catástrofe (spend runaway, postback drop a cero, CTR colapso), day-3 reads para evaluación preliminar, day-7 reads para decisiones de scaling, y day-14 reconciliation contra LTV cohorts. Las cuatro lecturas miden cosas diferentes y se contaminan si las mezclás. La mayoría de los media buyers que veo cometen el error de tomar decisiones de scaling con data day-1. Vamos a ver por qué eso es estructuralmente erróneo.

Una nota sobre la honestidad del reporte: este post documenta lo que funcionó y lo que no. Tuve un sub-ID que sangró 4.200 USD en febrero antes de matarlo. Tuve un test smartlink-vs-LP donde el smartlink ganó pero el delta cayó al re-correr el test con sample size adecuado. Esos dos episodios están adentro. Si querés el highlight reel, hay 2.000 posts en LinkedIn que te lo cuentan. Si querés saber cómo se gestiona spend real sin sorpresas, seguí leyendo.

La tesis del post es esta: comprar tráfico publicitario a 50K USD/mes no es 50x más difícil que a 1K USD/mes — es categóricamente diferente. Los errores que en 1K USD/mes te cuestan 30 USD, en 50K USD/mes te cuestan 1.500 USD. Y los errores que en 1K USD/mes no existen porque la data nunca llega a sample size suficiente para verlos, en 50K USD/mes son los que te diferencian de un media buyer que sobrevive del que cierra cuenta.

Una aclaración para que no haya malentendidos: la metodología que voy a describir no es la única forma de hacer esto. Conozco media buyers que prefieren modelos más automatizados (todo auto-bid, todo smartlink, decisiones algorítmicas en lugar de manuales) y manejan budgets similares con buenos resultados. Lo que ofrezco es una metodología basada en mi background — años en push-notification testing, 4.322 tests acumulados, formación en sample size discipline. Si tu background es diferente — performance marketer ex-Google Ads, growth en startup, founder con pasta puesta — tu approach probablemente debería diferir. La regla común es esta: cualquier metodología que apliques debería pasar el filtro de “¿esta decisión es defendible si me la cuestionan con la data?”. Si la respuesta es “yes, porque tengo n y CI”, está bien. Si la respuesta es “yes, porque me siento bien con ella”, probablemente no escala.

2. La estructura de la cuenta: 4 verticals, 3 networks, 12 sub-IDs

La estructura de cuenta es lo primero que se diseña cuando recibís un budget nuevo. La mayoría de los media buyers junior diseñan la estructura como un árbol top-down: empieza por network, después campaign, después ad-set, después creative. Esa estructura sirve para ejecutar — no para analizar. Y cuando estás manejando 50K USD/mes, la diferencia entre una estructura ejecutable y una estructura analizable es la diferencia entre ganar dinero y perderlo.

Mi estructura es bottom-up. Empieza por la unidad de análisis — el sub-ID — y construye hacia arriba. Cada sub-ID es una intersección única de cinco dimensiones: vertical, GEO, browser, device, y creative-family. Si dos sub-IDs comparten las cinco dimensiones, son redundantes y se consolidan. Si difieren en al menos una, son unidades de análisis independientes y se evalúan por separado.

Acá está la matriz completa del caso Q1 2026:

Sub-ID 1 — iGaming sportsbook, MX, Chrome desktop, hombres 25–45, creative family “match-day”: spend mensual ~6.800 USD, CTR baseline 2.1%, CR día 7 ~3.4%, network PropellerAds. Es el sub-ID más grande del portfolio.

Sub-ID 2 — iGaming sportsbook, MX, Chrome mobile, hombres 25–45, creative family “match-day”: spend mensual ~4.200 USD, CTR baseline 0.9%, CR día 7 ~2.1%, network PropellerAds. Mismo target, mismo creative family, distinto device. La separación es necesaria porque el delta de CTR Chrome desktop vs Chrome mobile típicamente está entre 2x y 3x para iGaming EU según mi base de datos, y LATAM se comporta similar. Mezclar los dos en un solo sub-ID te da CTR blended ~1.4% que no refleja a ninguna de las dos audiencias reales.

Sub-ID 3 — iGaming sportsbook, CO, Chrome desktop, hombres 25–45, creative family “match-day”: spend ~3.400 USD, CTR ~1.8%, CR día 7 ~3.0%, network adsy.tech. La separación por GEO (vs sub-ID 1) es necesaria porque aunque el creative family es el mismo, los modismos del copy difieren (México usa “apuesta”, Colombia usa “parley”) y el rendimiento es sensible a esa diferencia.

Sub-ID 4 — iGaming sportsbook, CL, Chrome desktop, hombres 25–45, creative family “match-day”: spend ~1.800 USD, CTR ~1.6%, CR día 7 ~2.7%, network adsy.tech. Chile es el de menor volumen del LATAM pillar pero el de mejor CR-to-CTR ratio en el portfolio.

Sub-ID 5 — iGaming sportsbook, ES, Chrome desktop, hombres 25–45, creative family “premier-league”: spend ~4.600 USD, CTR ~2.8%, CR día 7 ~4.1%, network RichAds. España es el sub-ID más rentable del portfolio en términos de CR. La razón es que la regulación española (DGOJ) reduce competition push porque elimina operadores no-regulados del mercado, lo que sube CTR e iguala CR.

Sub-ID 6 — iGaming casino slots, MX, Chrome desktop, hombres+mujeres 30–55, creative family “jackpot-tease”: spend ~3.600 USD, CTR ~1.9%, CR día 7 ~2.6%, network PropellerAds. Slots tiene CR menor que sportsbook pero LTV mayor por la frecuencia de juego.

Sub-ID 7 — iGaming casino slots, ES, Chrome desktop, mismo target, creative family “jackpot-tease”: spend ~2.800 USD, CTR ~2.4%, CR día 7 ~3.2%, network RichAds.

Sub-ID 8 — iGaming casino slots, IT, Chrome desktop, mismo target, creative family “jackpot-tease”: spend ~1.600 USD, CTR ~2.0%, CR día 7 ~2.9%, network RichAds. Italia es el sub-ID donde tuve más rotación de creative durante Q1 porque la audiencia se fatigaba más rápido — la curva de fatiga italiana es 1.4x más empinada que la española según mi tracking semanal.

Sub-ID 9 — finanzas préstamos personales, MX, Chrome desktop, 30–55, creative family “aprobación-rápida”: spend ~3.200 USD, CTR ~1.4%, CR día 7 ~1.8% (CR aquí significa lead submitted con email verificado, no aprobación final). Network PropellerAds.

Sub-ID 10 — finanzas préstamos personales, CO, Chrome mobile, 30–55, creative family “sin-buró”: spend ~2.400 USD, CTR ~0.8%, CR día 7 ~2.2% (mobile lead form, CR mayor por menor fricción del formulario). Network adsy.tech.

Sub-ID 11 — finanzas préstamos personales, CL, mixto Chrome desktop+mobile, creative family “préstamo-rápido”: spend ~2.400 USD, CTR ~1.1% blended, CR día 7 ~2.0%. Network adsy.tech. Este es el único sub-ID donde mezclo dos devices, y solo porque el volumen total chileno es bajo y separar mata el sample size por arm.

Sub-ID 12 — utility VPN install, multi-GEO (MX+CO+CL+ES+IT), Chrome desktop+mobile, 25–55, creative family “privacidad-streaming”: spend ~4.200 USD, CTR ~2.6% blended, CR día 1 ~3.8% (install rate, no LTV — utility paga en día 1). Network PropellerAds. Este es el sub-ID más “blended” del portfolio porque utility se evalúa a corto plazo y la fragmentación reduciría sample size sin mejorar la decisión.

Esa estructura suma a 41.000 USD/mes en base. Los ~9.000 USD restantes los reservo para tests — variantes de creative nuevas, expansion GEOs (Perú, Argentina cuando el cambio de moneda lo permite), nuevos creative families. Sin un budget reservado para tests, el portfolio se vuelve estático y la curva de fatiga te alcanza.

El número de sub-IDs (12) no es arbitrario. Surge de la regla de sample size: cada sub-ID necesita generar al menos n=4.000 impresiones por semana para que las decisiones day-7 tengan poder estadístico decente. A 50K USD/mes con CPM promedio del portfolio ~1.80 USD, el total de impresiones es ~27.7M/mes o ~6.4M/semana. Dividido entre 12 sub-IDs da ~533K impresiones/sub-ID/semana — muy por encima del umbral. Si tuviera 30 sub-IDs, el promedio caería a ~213K, lo que seguiría siendo aceptable para CTR pero empezaría a sufrir para CR (CR baseline ~3% requiere n más grande que CTR ~2% para detección de lift).

La regla operativa que aplico: el número máximo de sub-IDs es (impresiones-totales-semanales / 4.000). Por debajo de ese límite, las decisiones por sub-ID tienen poder. Por encima, estás generando ruido con etiquetas. La tentación de “segmentar más” siempre existe — siempre podés dividir por hora del día, por OS-version, por carrier mobile. La pregunta correcta no es “¿puedo segmentar más?” sino “¿este nivel de segmentación tiene n suficiente para decidir?”. Si la respuesta es no, la segmentación adicional es ilusión de control.

Una nota sobre redundancia con propósito. Tengo dos sub-IDs (1 y 3) que comparten vertical, creative family y browser, pero difieren en GEO. Esa redundancia es intencional: me permite hacer comparaciones GEO-pareadas con creative-family constante. Si el sub-ID 3 (CO) bajara CTR y el sub-ID 1 (MX) lo mantuviera, la causa probable es algo en Colombia específicamente — regulación, competition local, evento macro. Si los dos caen al mismo tiempo, la causa probable es el creative family. Esa diagnóstica vale más que el ahorro de complejidad de fusionar los dos en uno.

La estructura completa vive en una hoja Google Sheets que mi cliente y yo revisamos semanalmente. Cada sub-ID tiene su propia columna con métricas day-1, day-3, day-7, day-14. La hoja tiene 12 columnas por 30 días = 360 celdas vivas. Suena mucho, pero gestionado con condicionales de color (verde >baseline, rojo <baseline-15%, amarillo entre los dos), el escaneo visual toma 4 minutos por semana. La estructura analítica paga por sí misma en la velocidad con la que detectás problemas.

Lo que la estructura NO incluye: variants de creative al nivel del sub-ID. Cada sub-ID corre 3–5 variants en rotación weighted por performance (algoritmo simple: el creative con mejor CR día-7 recibe 60% del tráfico, los otros se reparten el 40% para mantener exploration). Las variants no son sub-IDs porque comparten todas las otras dimensiones, lo que las hace consolidables. Si quisiera analizar performance entre variants, hago un drill-down dentro del sub-ID, no agrego una capa.

Esa es la estructura. Pasamos al allocation.

3. Allocation budget Q1 2026: cómo asigné 50K USD — Sankey logic

La asignación de budget se hace en tres niveles secuenciales: total → verticals → networks → sub-IDs. El método que uso es lo que llamo “Sankey logic” — pensar el flujo de dinero como un diagrama Sankey donde cada nivel recibe la totalidad del anterior y la fracciona según una regla específica. La virtud del método es que cada decisión de asignación se documenta y se puede recalcular si una variable de entrada cambia.

Nivel 1 — total a verticals. El total es 50K USD/mes. La asignación entre los cuatro verticals la hice usando un score compuesto: 0.5 × payback-velocity-score + 0.3 × LTV-score + 0.2 × variance-score. Payback velocity favorece verticals que recuperan capital rápido (sportsbook ~4–7 días). LTV favorece verticals con valor por cliente alto (casino slots, finanzas). Variance penaliza verticals con resultados erráticos (utility install tiene variance alta porque depende de promociones de los advertisers).

Los scores Q1 2026 quedaron así (escala 0–10):

• iGaming sportsbook: payback 9, LTV 7, variance 8 → score compuesto 8.0. Asignación 52%.
• iGaming casino slots: payback 5, LTV 9, variance 7 → score compuesto 6.6. Asignación 24%.
• Finanzas préstamos: payback 3, LTV 6, variance 6 → score compuesto 4.5. Asignación 16%.
• Utility VPN install: payback 10, LTV 3, variance 4 → score compuesto 6.7. Asignación 8%.

El score compuesto de utility (6.7) es similar al de casino slots (6.6), pero la asignación es muy diferente (8% vs 24%). La razón: aplico un cap mínimo y máximo a cada vertical para evitar concentración. Cap mínimo: 5% (para mantener visibilidad en el vertical y conservar la opción de scaling). Cap máximo: 55% (para diversificar riesgo de cambios regulatorios o de plataforma). Utility hit el cap mínimo cerca; sportsbook hit el cap máximo casi.

Una decisión deliberada de Q1: no asigné nada a sweepstakes ni a dating. Sweepstakes porque la curva de fatiga es brutal (día 21 a ~18% de CTR día 1 según mi tracking 2023) y requiere rotación de creative que no podía mantener con el ancho de banda de Q1. Dating porque el cliente no quiso por motivos de brand alignment. Esas dos exclusiones liberaron capacidad mental para los cuatro verticals que quedaron.

Nivel 2 — verticals a networks. Cada vertical se asigna a uno o varios networks. Mi regla: un vertical va a un solo network primario salvo que el volumen exceda lo que el network puede absorber sin degradar quality score. La excepción Q1 fue sportsbook, que se asignó a dos networks (PropellerAds para MX, adsy.tech para CO y CL, RichAds para ES) porque ningún network individual maneja bien tres GEOs LATAM con creatives localizados.

Para casino slots: RichAds maneja los tres GEOs (MX, ES, IT). Razón: RichAds tiene mejor inventory casino en EU que PropellerAds, y MX no genera suficiente volumen para justificar split de network. Para finanzas: split entre PropellerAds (MX) y adsy.tech (CO+CL). Para utility: PropellerAds maneja los cinco GEOs porque el budget es chico y el creative blended no necesita inventory premium.

La asignación final por network:

• PropellerAds: 22.000 USD/mes (sub-IDs 1, 2, 6, 9, 12). 44% del total.
• RichAds: 12.000 USD/mes (sub-IDs 5, 7, 8). 24% del total.
• adsy.tech: 11.000 USD/mes (sub-IDs 3, 4, 10, 11). 22% del total.
• Reserva para tests: 5.000 USD/mes. 10% del total.

Una nota sobre adsy.tech específicamente. adsy.tech entró al portfolio en Q4 2025 después de mi auditoría de panel-to-Voluum reconciliation. El gap medido (4–8% en mi parallel-buy test 2025, n=18.400 impresiones por arm) lo posicionó mid-pack entre los networks principales — mejor que RichAds (12–28%) y mejor que PropellerAds para campañas EU (8–18%). El CPM mínimo de 0.50 USD también ayudó para el sub-ID 4 (Chile) donde el volumen es bajo y testing con CPM altos consume budget rápido. La elección no fue por loyalty, fue por data.

Nivel 3 — networks a sub-IDs. Acá el método cambia: la asignación dentro de un network no se hace ex-ante sino que se ajusta semanalmente basándose en performance. Cada lunes, miro CR día-7 de la semana cerrada y ajusto el budget para la semana siguiente con la regla: el sub-ID con mejor CR ajustado-por-volumen recibe +10%, el peor recibe -10%, los del medio mantienen.

“CR ajustado por volumen” es importante. Si el sub-ID 4 (CL, bajo volumen) tiene CR 3.5% con n=180 conversiones, y el sub-ID 1 (MX, alto volumen) tiene CR 3.2% con n=1.420 conversiones, no es claro que el CL gane. La CI 95% de un CR 3.5% con n=180 va de aproximadamente 2.0% a 5.4%. La CI 95% de un CR 3.2% con n=1.420 va de 2.7% a 3.7%. Las dos CI se solapan completamente — no hay evidencia de que el CL sea mejor que el MX. Lo que hago es comparar la CI inferior: CL 2.0% vs MX 2.7%. El MX es mejor en escenario pesimista. Eso desempata la decisión a favor del MX para scaling.

Esa regla del “CI inferior” es lo que me protege de tomar decisiones basadas en lucky weeks. Una semana puede ser ruido. La CI inferior incorpora el ruido y te dice cuál es el piso defensible. Decisiones tomadas sobre el piso defensible se sostienen; decisiones tomadas sobre el point estimate caen cuando el ruido se revierte.

El budget de tests. Los 5.000 USD/mes de reserve para tests se distribuyen en cuatro pools típicamente: 1.500 USD para variants de creative en sub-IDs existentes, 1.500 USD para expansion GEO (un GEO nuevo a baby-budget para evaluar viability), 1.000 USD para nuevo creative-family en un vertical existente, y 1.000 USD libre para oportunidades reactivas (un evento deportivo grande, un cambio regulatorio que abre un GEO).

El pool de expansion GEO Q1 lo usé para Perú (sportsbook). Resultado: CR día-7 1.4%, muy por debajo del piso de 2.0% del portfolio. La conclusión fue clara — Perú no entra al portfolio Q2 con la creative actual. Necesitaría un creative family específico-Perú para reintentar, y eso es trabajo para Q3.

La regla de re-allocation entre verticals. Mensualmente revisamos si los scores compuestos por vertical cambian lo suficiente para justificar mover budget entre verticals. El umbral es 1.0 puntos de score (en escala 0–10). Si el score de un vertical sube/baja 1.0 punto, ajustamos la asignación en 5 puntos porcentuales. Si baja 2.0 puntos, ajustamos 10 puntos. Por debajo de 1.0 punto, ni tocamos.

Esa regla es lenta deliberadamente. Re-allocations frecuentes erosionan el aprendizaje por sub-ID porque cada sub-ID necesita 2–3 semanas para estabilizar después de un cambio de budget significativo (smart bidding tiene un período de warm-up, vamos a tocar eso en la sección 5). Re-allocations cada 4 semanas como mucho mantienen el aprendizaje intacto.

Documentación del allocation. Toda la lógica vive en una hoja con cuatro tabs: scores compuestos por vertical, asignación vertical→network, asignación network→sub-ID con histórico semanal, y log de decisiones de re-allocation con justificación. Si te suena overkill, hacé el cálculo: una mala decisión de allocation a 50K USD/mes te cuesta entre 500 y 2.500 USD/mes en spend desperdiciado. La documentación cuesta 2 horas/mes. Es el mejor return de cualquier hora que ponga en el portfolio.

La sankey logic en resumen: 50K total → 4 verticals (cap 5%–55%, score compuesto) → 3 networks (alineados a quality del inventory por GEO) → 12 sub-IDs (ajuste semanal por CI inferior de CR día-7). Cada flecha del Sankey tiene una regla. Ninguna flecha es “gut feel”. Cuando el cliente me pregunta por qué el sub-ID 6 recibe más budget que el sub-ID 7, le muestro el log de la semana 9 donde el CI inferior del sub-ID 6 superó al del 7 después de tres semanas de empate.

4. Sample size por arm: cuándo n=2.000 es suficiente y cuándo no

Lo que la mayoría de los media buyers llama “test” es una observación sin diseño. Para que un test sirva, necesita tres elementos: una hipótesis específica con dirección y magnitud, un sample size pre-registrado, y una stopping rule definida antes de empezar. Sin esos tres, lo que tenés es una hoja de cálculo con números — no un experimento.

El sample size es donde más errores veo. Vamos a desmenuzar cuándo n=2.000 alcanza y cuándo no, usando la fórmula estándar para detección de diferencia de proporciones:

n ≈ 16 · p · (1-p) / d²

donde p es el baseline CTR en proporción y d es la diferencia mínima detectable absoluta también en proporción. Esta aproximación funciona bien para CTR entre 0.5% y 8%, que es donde vive el 95% del push real. Power asumido 80%, α=0.05, two-tailed.

Aplico la fórmula a los baselines reales de los 12 sub-IDs del caso:

Sub-ID 1 (MX sportsbook Chrome desktop, baseline CTR 2.1%). Para detectar un lift relativo de +15% (CTR sube a 2.42%, diferencia absoluta 0.32 puntos), necesito n ≈ 16 · 0.021 · 0.979 / 0.00322² ≈ 31.700 impresiones por arm. Eso es n grande. ¿Por qué grande? Porque el lift que quiero detectar (15%) es modesto en términos absolutos (0.32 puntos sobre baseline 2.1%). Para detectar un lift más agresivo de +30% (CTR sube a 2.73%, diferencia absoluta 0.63 puntos), n ≈ 8.260 por arm. Para +50% (CTR 3.15%, diferencia 1.05 puntos), n ≈ 2.980 por arm.

La regla aplicada al sub-ID 1: con sample weekly ~533.000 impresiones distribuidas en 3 variants, cada variant recibe ~178.000 impresiones/semana. Tests de +15% requieren ~31.700 por arm — los detecto en menos de 1.5 días. Tests de +30% los detecto en horas. Tests de marginal-lift (+5%, n ≈ 280.000 por arm) requerirían 1.6 semanas — los corro solo cuando hay una hipótesis específica de optimización fina.

Sub-ID 4 (CL sportsbook Chrome desktop, baseline CTR 1.6%, volumen ~78.000 impresiones/semana). Para detectar +15% (CTR 1.84%, diferencia 0.24 puntos), n ≈ 43.500 por arm. Con sample weekly 78.000 dividido en 3 arms = 26.000 por arm — insuficiente. Para detectar +15% en CL necesitaría correr 1.7 semanas. Para +30% (n ≈ 11.300), 3 días — esto sí lo corro. La consecuencia operativa: en sub-IDs de bajo volumen como CL, los tests viables son los de lift agresivo (>25%) o tests largos (≥2 semanas). Tests de marginal optimization no se pueden hacer ahí — el sample no alcanza.

Sub-ID 11 (CL finanzas mixed device, baseline CTR 1.1%, volumen ~50.000/semana). Para detectar +15% (CTR 1.27%, diferencia 0.17 puntos), n ≈ 90.700 por arm. Con sample weekly 50.000 dividido en 2 arms = 25.000 por arm — necesitaría 3.6 semanas para detección. Para +50% (n ≈ 8.500), 4 días. En este sub-ID solo corro tests de high-impact (no marginal optimization), y solo los corro cuando hay una hipótesis razonable de lift grande.

La tabla aproximada que tengo pegada al monitor:

• Baseline 0.6% (LATAM utility mobile típico): n ≈ 10.640 por arm para detectar +25%, n ≈ 2.660 para +50%, n ≈ 670 para +100%.
• Baseline 1.1% (LATAM finanzas mobile típico): n ≈ 5.800 por arm para +25%, n ≈ 1.450 para +50%.
• Baseline 1.6% (LATAM sportsbook desktop típico): n ≈ 3.940 por arm para +25%, n ≈ 985 para +50%.
• Baseline 2.0%–2.1% (EU+MX sportsbook típico): n ≈ 3.140 por arm para +25%, n ≈ 785 para +50%.
• Baseline 2.8% (ES iGaming Chrome desktop premium): n ≈ 2.220 por arm para +25%, n ≈ 555 para +50%.

La conclusión que sale de la tabla: n=2.000 por arm es suficiente solo cuando el baseline CTR es ≥2% Y el lift mínimo de interés es ≥25%. Fuera de esa ventana, n=2.000 está subdimensionado y los resultados que arroja son ruido con apariencia de señal.

El problema de las multiple comparisons. Un test A/B/n con 5 variants no es 1 comparación — son 4 comparaciones contra control, o 10 si comparás todos contra todos. Sin corrección, tu α efectivo no es 0.05 — es 0.20 si comparás todos vs todos. Aplicar corrección Bonferroni dividiendo α por el número de comparaciones es conservador pero defendible.

Aplicado a un sub-ID con 4 variants: α corregido = 0.05 / 3 = 0.0167. El sample size requerido sube ~30–40%. Lo que para α=0.05 requería n=2.000 ahora requiere n=2.720 por arm. Si vas a correr A/B/n con K variants, tu cálculo de sample size tiene que incluir el factor de corrección desde el diseño. Si lo agregás después, terminás con un test underpowered que no podés rescatar.

El problema del CR (no solo CTR). El sample size que vimos hasta acá es para detectar lift de CTR. Para detectar lift de CR el cálculo es diferente porque CR es una proporción con baseline más bajo (típicamente 2%–5%) y requiere n mayor para el mismo lift relativo, pero también porque CR tiene latencia (la conversión no ocurre en el momento del clic — ocurre días después).

Para sub-ID 1 con baseline CR día-7 = 3.4%, detectar +15% en CR (CR sube a 3.91%, diferencia 0.51 puntos) requiere n ≈ 8.000 clicks-a-LP por arm, lo que corresponde a aproximadamente 380.000 impresiones por arm (si CTR es 2.1%). Eso es casi 1.5x del volumen weekly del arm. Tests de CR en este sub-ID requieren 1.5 semanas como mínimo. En sub-IDs más chicos, requieren 4–6 semanas.

Implicación operativa. Las decisiones por sub-ID se toman con cadencias diferentes según qué métrica está siendo testeada:

• Lift de CTR ≥30%: decisión en 2–4 días (todos los sub-IDs).
• Lift de CTR +15% a 25%: decisión en 4–7 días (sub-IDs grandes), 1.5–2 semanas (sub-IDs chicos).
• Lift de CR ≥20%: decisión en 1.5–2 semanas (sub-IDs grandes), 4–6 semanas (sub-IDs chicos).
• Lift de CR <15%: decisión en 4+ semanas, frecuentemente no se mide formalmente y se asume como ruido.

El error que veo en agencias hispanohablantes con más frecuencia: declarar ganador a un creative en día 3 con CR +20% sobre control, sin reconocer que con n=380 conversiones por arm (que es lo que típicamente cabe en 3 días en sub-IDs medios) la CI 95% del lift va de -8% a +52%. El point estimate de +20% está adentro del CI, pero también lo está -8% y +52%. Esa es la realidad del intervalo. Declarar el +20% como “el resultado” es ignorar el 95% del rango donde la verdad podría estar.

Una nota sobre el peeking. Mirar el test todos los días e ir tomando decisiones según lo que ves es la forma más común de p-hacking en push. El peeking diario eleva la tasa de falso positivo a aproximadamente 3–4x el α declarado. Un test declarado significativo con peeking diario y α=0.05 tiene tasa real de falso positivo cercana a 0.15–0.20.

Para tests de creative, la regla que aplico: defino el sample size requerido antes de empezar, miro el test en day-1 solo para alertas de catástrofe (no para decisiones), miro day-3 para confirmar que las dos arms están corriendo sin bugs operativos, y NO miro el lift formal hasta haber alcanzado n pre-registrado. Si el sample size requerido es 8.000 por arm y el test va por 5.000, la respuesta correcta a “¿quién va ganando?” es “no sé todavía, falta n”.

Esa disciplina suena costosa. Es barata. El costo de declarar un winner falso en sub-ID 1 (MX sportsbook) y escalar gasto sobre él es ~2.500 USD/mes en spend mal allocated. El costo de esperar 4 días más para tomar la decisión correcta es cero — el sub-ID sigue corriendo con la variante de control que ya funciona. La impaciencia tiene un precio. La paciencia, no.

Resumen aplicable. Antes de correr un test, calculá los tres números: baseline real del segmento (no del agregado), lift mínimo de interés comercial, y sample size requerido por arm para detectarlo con poder 80%. Si el sample size requerido excede lo que tu sub-ID puede generar en el tiempo del test, no corras el test — porque correrlo subdimensionado es peor que no correrlo. Te entrega una conclusión engañosa con apariencia de rigor, y vas a tomar decisiones de scaling sobre datos que no soportan el peso.

5. Postback latency, day-7 vs day-1 reads, smart-bidding warm-up

La latencia del postback es el segundo factor más importante después del sample size cuando manejás spend a esta escala. Si no entendés cuánto tarda una conversión en aparecer en tu tracker, vas a tomar decisiones de scaling sobre datos incompletos. Los datos incompletos sistemáticamente subestiman performance — y la subestimación de performance produce kills prematuros de sub-IDs que en realidad estaban funcionando.

Qué significa “postback latency”. Un postback es la señal de conversión que el advertiser (o su plataforma de attribution) le devuelve al network o tracker cuando ocurre una conversión. La latencia es el tiempo entre el click inicial y la llegada del postback. Para iGaming, el postback típico ocurre en una de tres ventanas: instant (registro completado), día 1–3 (primer depósito), día 4–14 (FTD calificado o segundo depósito).

Para el portfolio Q1 2026, la distribución de latencia de postbacks por vertical fue así:

• iGaming sportsbook: 22% del CR total llega día 1, 48% adicional día 2–3, 22% día 4–7, 8% día 8–14. El 92% acumulado en día 7 es lo que justifica el “day-7 read” como decisión de scaling.
• iGaming casino slots: 14% día 1, 38% día 2–7, 36% día 8–14, 12% día 15–21. La distribución es mucho más larga — slots requiere lecturas más pacientes.
• Finanzas préstamos: 8% día 1 (lead form submission), 62% día 2–3 (lead verification + email open), 30% día 4–7 (lead enriquecimiento o segundo punto de contacto). Acumulado día 7: 100% (el postback no llega más tarde de día 7 en este vertical porque después del día 7 el lead se considera caducado).
• Utility VPN install: 96% día 1, 4% día 2 (mobile installs delayed por wifi-only sync). Aquí el day-1 read es suficiente.

La implicación operativa: el “read” que importa depende del vertical. Para utility, day-1 alcanza. Para sportsbook, day-7 es donde tenés 92% de la señal y podés decidir scaling. Para slots, day-14 es necesario y day-21 ideal. Para finanzas, day-7 cierra la ventana.

El error más caro que vi en mi carrera: scaling sportsbook por day-1. Cliente ex-iAdvize, 2021, no en este caso. Tomaba decisiones de scaling sobre CR day-1 porque “los números se ven bien rápido”. El problema: CR day-1 captura solo 22% del CR total en sportsbook. Si en day-1 ves un sub-ID con CR 1.2% y otro con CR 0.8%, el ratio aparente es 1.5x. Pero el CR día-7 final podría ser 4.1% y 5.2% respectivamente — el ranking se invierte. Tomar decisiones de scaling en day-1 te puede llevar a escalar el sub-ID equivocado y a matar el correcto. Yo vi 18.000 USD irse por ese error en una sola semana en 2021. Por eso ahora todas las decisiones de scaling en sportsbook se toman day-7, no antes.

Cómo verifico que los postbacks están llegando. Una vez por semana hago reconciliación entre dos fuentes: el dashboard del network y mi tracker (Voluum en este caso). Si los dos coinciden dentro del gap esperado (PropellerAds 8–18%, RichAds 12–28%, adsy.tech 4–8% según mi auditoría 2025), todo bien. Si el gap se abre más allá de eso, hay algo roto — postback URL mal configurada, firewall del advertiser, mismatch de macros, o problema temporal del network.

Q1 2026 tuvo un episodio del que vale la pena documentar el detalle. Semana 6 (febrero): el gap PropellerAds vs Voluum en sub-ID 1 (MX sportsbook) saltó de 12% a 38%. Mi reacción inmediata: pause del sub-ID por 24 horas mientras investigaba. Si hubiera asumido que el gap era real (que PropellerAds estaba inflando CTR), habría killed el sub-ID. Si hubiera asumido que el gap era del lado de Voluum (postback no llegando), habría seguido escalando spend sin attribution real. La pausa de 24 horas costó ~960 USD de spend perdido. La alternativa — actuar sobre data corrupta — habría costado entre 2.000 y 5.000 USD según qué hipótesis hubiera elegido.

La causa final del incidente: el advertiser había cambiado el endpoint de postback sin avisar. 18% de los postbacks estaban dropeando porque iban a la URL vieja. El fix fue trivial — actualizar la URL en mi setup — pero el impacto de no detectarlo a tiempo habría sido grande. Eso es lo que justifica el reconciliation weekly: detecta los breaks antes de que se conviertan en decisiones mal informadas.

Day-7 reads y la estabilidad de la decisión. El day-7 read es estable porque tiene 92% de la señal acumulada (para sportsbook). Pero esa estabilidad asume que el postback latency baseline no cambia. Si el advertiser ajusta su CRM y el flujo de conversión se acelera de día 3 a día 1 promedio, tu day-7 read va a empezar a leer como mejor que antes — no porque el sub-ID mejoró sino porque la attribution timing cambió. Por eso miro CR día-1, día-3 y día-7 simultáneamente: si día-7 sube pero día-1 también sube proporcionalmente, hay cambio real. Si día-7 sube pero día-1 baja, lo que cambió es la timing, no la performance subyacente.

Smart-bidding warm-up. Los algoritmos de auto-bidding de las plataformas (Target CPA en Google Ads, ROAS bidding en Facebook, smart-CPM en PropellerAds, optimized auto-bid en RichAds) requieren un período de aprendizaje. La regla empírica que me funciona: 7–14 días de spend estable antes de que el algoritmo entre en régimen.

“Estable” significa: budget diario no varía más de ±10%, bid cap no cambia, audiencia no se modifica, creative pool no rota >30% en una semana. Si cualquiera de esas cuatro condiciones se rompe, el warm-up se reinicia.

Qué pasa durante el warm-up: el algoritmo está explorando. CR es típicamente 30–50% más bajo que el régimen, CTR puede ser más alto (porque el algoritmo está intentando audiencias amplias para acumular data), y la variance día a día es alta. Si tomás decisiones de kill durante el warm-up, vas a matar sub-IDs que iban a estabilizar en buen lugar.

Mi regla operativa: no evalúo CR de un sub-ID nuevo o de uno con cambios significativos hasta día 10 mínimo. Eso aplica para nuevos sub-IDs (cuando lanzo expansion GEO o nuevo vertical) y para sub-IDs existentes que tuvieron cambios materiales (rotación >50% de creative pool, cambio de bid strategy, cambio de target audience).

El día 10 es un floor — para algunos sub-IDs el warm-up requiere 14–21 días. En general, sub-IDs con CR baseline bajo (utility, finanzas) requieren más warm-up porque el algoritmo necesita más conversiones para identificar señal. Sub-IDs con CR alto (sportsbook ES) warm-up más rápido.

Combinando postback latency + warm-up + sample size. Para un sub-ID nuevo en sportsbook, la primera decisión de scaling no puede tomarse antes de:

• Warm-up completado: día 10–14.
• Postback latency cerrada: 7 días después del último click relevante, así que día 17–21.
• Sample size suficiente para detectar lift comercial: depende del baseline, pero típicamente 3–4 semanas.

En la práctica eso significa que un sub-ID nuevo requiere 3–4 semanas de spend antes de generar data confiable para decisiones de scaling. Cualquiera que te diga que “evaluamos en 5 días” está tomando decisiones sobre noise.

El costo de no respetar las ventanas. Q1 2026 tuvo un sub-ID de finanzas (sub-ID 10, CO Chrome mobile) que en día 4 mostraba CR 0.9% — muy por debajo del piso de 2.0% que tenía como umbral. El instinto era killearlo. Pero day-4 está en pleno warm-up Y solo capturé 8% del postback latency (los leads se verifican en días 2–3, no día 4). El sub-ID 10 estaba en una ventana donde aún no se podía evaluar.

Lo dejé corriendo. En día 10 el CR había subido a 1.8% (con warm-up casi cerrado), y en día 14 a 2.2% (postback latency cerrada al 100%). El sub-ID 10 estaba funcionando todo el tiempo — el problema era mi instrumento, no la performance subyacente. Si lo hubiera killed día 4, habría perdido un sub-ID que en Q1 generó ~720 USD/mes en CR adjudicada al portfolio.

El check semanal completo. Cada lunes corro la siguiente checklist sobre los 12 sub-IDs:

1. Spend de la semana cerrada vs target. Variance >±15% requiere investigación.
2. Volume de impresiones del network vs lo que Voluum tracked. Gap fuera de baseline = problema técnico.
3. CR día-7 con CI 95%. Si CI inferior >baseline target, sub-ID es candidate para scaling. Si CI superior <baseline target, candidate para kill.
4. Warm-up status. Sub-IDs en warm-up no se evalúan por CR — solo por presencia de tracking funcional.
5. Postback timing distribution vs baseline. Si la curva se desplaza, algo cambió del lado del advertiser.

Ese check toma 30 minutos los lunes. Su valor en errores evitados es enorme.

6. Smartlink vs direct LP — n=18.400 test resultados

Una de las decisiones recurrentes en compra de tráfico es cuándo usar smartlink (un router automático que envía el click a la mejor LP según GEO/device/source) versus direct LP (un destino fijo controlado por vos). El argumento típico a favor del smartlink: optimización automática, menor trabajo de management. El argumento típico a favor del direct LP: control creativo, mejor tracking granular.

Esos argumentos son cualitativos. Para tomar la decisión correctamente, necesitás un test cuantitativo. Te cuento el que corrí en Q1 2026 con n=18.400 impresiones por arm, sobre sub-ID 1 (MX sportsbook Chrome desktop).

Diseño del test. Dos arms: arm A = smartlink del network (PropellerAds smartlink configurado con tres LPs candidate para sportsbook MX); arm B = direct LP a una landing dedicada que mi cliente y yo habíamos optimizado durante seis semanas previas. Tráfico split 50/50 vía un dispatcher de Voluum. Duración planificada: 14 días o n=18.000 por arm, whatever happened first. Métrica primaria: CR día-7. Métrica secundaria: CTR (debería ser igual entre arms porque el split está pre-LP, pero lo monitoreo por sanity).

Pre-registro. Antes de empezar, registré:

• Hipótesis: smartlink no tiene lift estadísticamente significativo en CR día-7 sobre direct LP para sub-ID 1.
• Lift mínimo de interés comercial: ±15% en CR (un lift menor no justifica el switching cost).
• Stopping rule: 14 días o n=18.000 por arm. No earlier reads para decisión, sí monitoring de catástrofe.
• Sample size requerido para detectar +15% lift sobre baseline CR 3.4% con power 80% y α=0.05: n ≈ 7.880 clicks por arm, lo que a CTR baseline 2.1% requiere ~376.000 impresiones por arm. Eso excede el budget del test, así que ajusté el lift mínimo de interés a +25% (n ≈ 2.840 clicks, ~135.000 impresiones por arm) y planeé el test sobre ese threshold.

Resultados después de 14 días. Total impresiones: 36.800 (18.400 por arm). Clicks acumulados: ~772 por arm. CR día-7:

• Arm A (smartlink): 3.11% (24 conversiones sobre 772 clicks). CI 95% = 2.0% a 4.6%.
• Arm B (direct LP): 3.38% (26 conversiones sobre 772 clicks). CI 95% = 2.2% a 4.9%.
• Delta absoluto: -0.27 puntos a favor del direct LP.
• Delta relativo: -8% del smartlink vs direct LP.
• p-value: 0.74.

Interpretación. El test no fue capaz de detectar lift de magnitud +25% porque la muestra (~772 clicks por arm) está muy por debajo del n requerido (~2.840 clicks por arm). El delta observado (-8%) está dentro del rango de ruido que esta sample size permite. El test no concluye nada sobre el lift de smartlink — no porque no haya lift, sino porque no tengo poder estadístico para verlo.

La conclusión correcta es: el test fue underpowered para mi pregunta. La conclusión incorrecta — y la que la mayoría de las agencias publicaría — es “el direct LP gana por -8% sobre smartlink”. Esa conclusión asume que el point estimate es el resultado. El CI dice que la realidad podría estar desde -42% (smartlink mucho peor) hasta +28% (smartlink mucho mejor). Cero está adentro. La realidad podría ser que los dos son indistinguibles.

Lo que hice con esos resultados. Mantuve direct LP por dos razones independientes del test:

1. Control de creative: el direct LP permite testing granular de elementos (CTA, hero image, formulario) que el smartlink no permite porque las LPs detrás del smartlink no las controlo yo.
2. Tracking granularity: con direct LP puedo trackear elementos específicos del funnel (tiempo en página, scroll depth, formulario partial-submit) que el smartlink agrega y oculta.

El test no me dijo “direct LP es mejor”. Me dijo “el test fue underpowered, otras consideraciones (control + tracking) inclinan la decisión a direct LP independientemente del lift”. Esa es una decisión defendible. “Smartlink es peor por 8%” no es una decisión defendible con n=772.

El test que sí cierra: cuándo smartlink gana. Q4 2025 corrí un test paralelo a este sobre sub-ID 12 (utility VPN multi-GEO). Razón: utility tiene CR día-1, lo que hace que el sample size requerido sea mucho menor porque el feedback loop es corto. Test duración 21 días, n acumulado por arm ~89.000 impresiones. Clicks por arm ~2.310. CR día-1:

• Smartlink: 4.2% (97 conv).
• Direct LP único: 3.1% (72 conv).
• Delta: +35% relativo a favor del smartlink. p=0.012. CI 95% del lift: +8% a +62%.

En utility el smartlink ganó significativamente porque el routing GEO-específico mostraba LP localizada en español-MX para tráfico MX, español-CO para CO, etc. El direct LP era una versión universal en español neutral. La granularidad GEO del smartlink generó +35% de CR. Sample size adecuado, sub-ID con feedback corto, lift detectable. Para utility, el smartlink es la decisión correcta y la data lo respalda.

La regla operativa que saqué de los dos tests. Smartlink vs direct LP no es una pregunta universal. La respuesta depende de:

1. Vertical y latencia de postback. Verticals con feedback corto (utility, leads finanzas) permiten tests con sample size manejable. Verticals con feedback largo (sportsbook, slots) requieren sample size que típicamente excede lo testeable en una sola campaña.

2. Granularidad de tracking deseada. Si necesitás trackear sub-pasos del funnel, direct LP gana por construcción. Si te alcanza con CR final, smartlink es viable.

3. Control creativo. Si vas a iterar sobre LP elements en ciclos cortos, direct LP es la única opción. Si vas a usar lo que el network ofrece sin modificar, smartlink puede liberar tu tiempo para otras cosas.

4. Volume del sub-ID. Sub-IDs grandes pueden absorber sample size grande para tests serios. Sub-IDs chicos no.

Para el portfolio Q1 2026 quedó así: smartlink en sub-ID 12 (utility), direct LP en los otros 11. Esa configuración no es ideológica — es lo que resultó de tests por sub-ID con la metodología correcta.

Una nota sobre lo que la mayoría dice y por qué dice mal. Los blogs de networks venden smartlink agresivamente. La razón es comercial: el smartlink lo controla el network, lo que les da más data y más leverage para upselling. Los blogs de affiliate gurus venden direct LP agresivamente. La razón es comercial: monetizan cursos sobre cómo construir LPs. Ninguna de las dos posiciones tiene un test detrás. La mía tiene dos, con sample sizes documentados, y la conclusión es “depende del sub-ID”. Esa conclusión no se puede vender como ebook, pero es la que cierra cuentas.

Cómo planificar un test smartlink-vs-LP que sí concluya. Si vas a correr este test honestamente, los números que necesitás prefijar son: baseline CR del sub-ID (no del agregado), lift mínimo de interés (típicamente +20% para justificar switching cost de migrar configuración), n requerido por arm para ese lift al baseline tuyo, y duración estimada del test contemplando warm-up.

Para el sub-ID 1 (MX sportsbook, baseline CR 3.4%), detectar +20% lift con poder 80% requiere n ≈ 4.420 clicks por arm. A CTR baseline 2.1%, eso son ~210.000 impresiones por arm. A volumen weekly del sub-ID de ~533.000 impresiones split 50/50, alcanzamos n requerido en aproximadamente 5.5 días — pero hay que sumar 7 días de warm-up del algoritmo del smartlink, lo que lleva el test total a ~13 días. Si planeás 14 días desde el inicio y respetás el sample size mínimo, el test concluye honestamente. Si planeás 7 días y tomás decisión en day-7, estás declarando ganador con n=210.000 que es exactamente el threshold — sin margen para slippage operativo.

El meta-aprendizaje. Los tests A/B comparativos a nivel de “estrategia macro” (smartlink vs LP, push vs popunder, mobile vs desktop) son los que más fácilmente caen en underpowered porque la diferencia esperada es modesta y el sample size requerido es alto. Los tests A/B a nivel de “elemento micro” dentro de una estrategia (CTA color, headline copy, hero image) son los que más fácilmente alcanzan poder porque la diferencia esperada es mayor relativa a la baseline del micro-elemento. La asignación de tu test-budget mensual debería reflejar esta asimetría: pocos tests macro al año (1–2 por sub-ID), muchos tests micro al mes (2–3 por sub-ID activo).

7. Los tres errores que cuestan dinero: postback delay, frequency mal calibrado y sub-ID mezclado

Q1 2026 me costó tres errores concretos. Te los enumero con el impacto cuantificado porque la única forma de aprender de errores ajenos es ver el costo. Si los errores no tienen número adjunto, son anécdotas. Con número adjunto, son lecciones.

Error 1 — Postback delay subestimada (impacto: 4.200 USD perdidos en sub-ID 6, semana 4).

Sub-ID 6 es iGaming casino slots MX. La latencia baseline de postback para slots es 14% día 1, 38% día 2–7, 36% día 8–14, 12% día 15–21. Yo había modelado el sub-ID asumiendo 70% acumulado en día 7 para la decisión de scaling. Real: 52% acumulado en día 7.

¿De dónde vino la subestimación? Del baseline de iAdvize 2019–2023 versus la realidad post-2025. Los advertisers de slots cambiaron sus modelos de attribution durante 2024–2025 (movieron postbacks de “primer depósito” a “primer depósito calificado con KYC completo”), lo que extendió la latencia ~5 días promedio. Yo no había actualizado mi modelo.

En semana 4 evalúé sub-ID 6 con day-7 read pensando que tenía 70% de la data. Tenía 52%. El CR aparente era 2.1%, por debajo del baseline target 2.6%. Decisión que tomé: redujimos budget del sub-ID 6 en 25% para semana 5. Decisión correcta: dejarlo correr otra semana antes de decidir, porque el day-14 mostraba ya 2.7% (real, no diluido por latencia incompleta).

El impacto: 25% menos de spend en sub-ID 6 durante semana 5 = ~900 USD menos de exposure. CR real día-7 final de la semana = 2.65%. Conversiones perdidas estimadas: 14. CR-equivalent en revenue para el cliente: ~3.300 USD. Más el costo de oportunidad de un sub-ID que estaba funcionando y opté por castigar. Total impacto aproximado: 4.200 USD.

Mitigación: actualicé el modelo de latencia para todos los verticals usando data Q4 2025–Q1 2026. Slots quedó en 52% día-7, 84% día-14. Sportsbook quedó en 92% día-7 (sin cambio). Finanzas y utility quedaron iguales. Reviso el modelo de latencia mensualmente ahora — no anualmente.

Error 2 — Frequency cap miscalibration (impacto: estimado 2.800 USD en sub-ID 5, semanas 8–9).

Sub-ID 5 es iGaming sportsbook ES Chrome desktop. Mi frequency cap baseline para sportsbook EU es 3/día. La razón es la curva que tengo medida: bajar de 5/día a 3/día cuesta ~28% de volumen y agrega ~4% de CR; bajar de 3/día a 2/día cuesta ~22% de volumen y agrega ~1,6% de CR — el sweet spot está en 3/día.

En semana 8 cambié a 4/día por error (no recuerdo si fue typo o si confundí setup con otro sub-ID). El sub-ID 5 corrió con frequency cap 4/día durante 9 días antes de que lo detectara.

¿Cómo lo detecté? Por el patrón de CTR en la curva intra-week. CTR semanal de sub-ID 5 normalmente cae ~6% entre lunes y domingo (mild fatigue intra-week). En semana 8 cayó ~14% — el doble. Ese delta atípico me hizo abrir el setup y vi el cap a 4/día.

Impacto estimado: durante esos 9 días, el sub-ID generó ~17% más volumen que baseline (más impresiones por usuario) pero con CR ~2.4% en vez de baseline 4.1%. Spend del sub-ID durante el período: ~1.300 USD. Conversiones perdidas vs scenario contrafactual con cap 3/día: ~22. Revenue perdido para el cliente: ~2.800 USD.

Mitigación: agregué frequency cap como uno de los cinco campos que reviso semanalmente en el checklist. Ya estaba implícito en “configuration check” pero implícito no alcanza. Ahora es explícito y la celda en la hoja se pinta amarillo si no coincide con la baseline registrada.

Error 3 — Sub-ID unblending tardío (impacto: estimado 1.600 USD durante semanas 2–5).

Sub-ID 12 es utility VPN install multi-GEO blended. Como mencioné en sección 2, este es el único sub-ID donde mezclo GEOs porque utility se evalúa a corto plazo y la fragmentación reduciría sample size sin mejorar la decisión.

Pero “no mejorar la decisión” no es lo mismo que “no genera data útil”. Durante semanas 2–5 de Q1 vi que el CTR blended del sub-ID 12 estaba relativamente estable en 2.6%. No le presté atención al desagregado hasta semana 6 cuando hice un drill-down rutinario.

Al desagregar por GEO: MX 3.4%, CO 2.8%, CL 2.2%, ES 2.4%, IT 1.9%. Esos 5 GEOs estaban siendo tratados como uno solo pero tenían CTR baseline diferente y CR baseline aún más divergente (MX 4.6% día-1, IT 2.1% día-1). El budget se distribuía proporcional al volumen, lo que significaba que IT (el peor performer) recibía ~12% del budget porque generaba ~12% del volumen — exactamente la asignación inversa de la que la performance justificaba.

Reasigné el budget interno del sub-ID 12 con weighting proporcional a CR día-1 inferida por GEO. MX subió a ~38% del budget interno, IT bajó a ~5%, los otros se ajustaron. El CR día-1 promedio del sub-ID 12 subió de 3.8% a 4.4% durante semana 7. Aplicado retroactivamente a las semanas 2–5: la mala distribución costó aproximadamente 1.600 USD en conversiones perdidas.

Mitigación: ahora todos los sub-IDs blended (en el futuro Q2 puede haber alguno más) reciben drill-down de GEO/device cada dos semanas mínimo. La regla: si el delta entre sub-segmento máximo y mínimo dentro del sub-ID excede 1.5x, el sub-ID se considera para des-blender.

El meta-error que conecta los tres. Los tres errores comparten una raíz común: data que no estaba viendo aunque la tenía. Postback latency outdated, frequency cap implícitamente revisado, sub-ID blended sin drill-down. En los tres casos, el setup técnico existía para detectar el problema — yo no estaba mirando los datos a la cadencia necesaria.

La lección operativa: el checklist semanal no es ceremonia. Es donde los problemas que tu instinto no va a detectar se hacen visibles. Cinco minutos extras por sub-ID son baratos. Mil seiscientos dólares perdidos por no haberlos hecho, no.

El checklist completo Q2 2026 (lo que reviso cada lunes).

Por cada sub-ID:

1. Spend semana cerrada vs target. Tolerance ±15%.
2. Volume Voluum vs panel network. Gap dentro de baseline registrada por network.
3. CR día-7 con CI 95%. Si CI inferior >baseline target, candidate para scaling +10% next week. Si CI superior <baseline target, candidate para kill o reducción -10%.
4. Warm-up status. Sub-IDs <14 días desde último cambio material: solo monitoreo, no decisión de scaling.
5. Postback latency distribution. Comparar curva acumulada vs baseline modelada. Drift >10 puntos en cualquier ventana = investigar.
6. Frequency cap actual. Match contra baseline registrada del sub-ID. Mismatch = corregir y registrar.
7. Sub-ID drill-down si blended. Delta entre sub-segmentos <1.5x = OK. Mayor = candidate para unblending.

Siete checks, 12 sub-IDs, ~30 minutos los lunes. El ROI de esos 30 minutos lo medí indirectamente: en los meses en los que hice el checklist completo, los errores caros descendieron a cero. En los meses en los que abrevié (febrero 2026 tuvo dos semanas con check parcial por carga de trabajo), tuve los tres errores que documenté arriba. La correlación no es prueba de causalidad, pero es lo suficientemente fuerte para que el checklist completo sea no-negociable.

Una observación sobre cómo se estructuran estos errores en el tiempo. Los tres errores Q1 2026 no aparecieron juntos. El postback latency drift se acumuló durante semanas 3 y 4. El frequency cap miscalibration apareció en semana 8. El sub-ID unblending llevaba ocurriendo desde semana 2 pero recién lo detecté en semana 6. Cada uno tuvo una ventana de detección distinta — algunos urgentes, otros silenciosos. Los silenciosos son los más peligrosos porque no disparan alerta. Solo aparecen cuando alguien decide ir a buscarlos.

Eso es lo que justifica el drill-down rutinario aún cuando la métrica blended se ve estable. La estabilidad del blended es exactamente lo que oculta la divergencia interna del sub-ID. Si esperás a que el blended muestre el problema, llegás cuando el problema ya costó dinero suficiente para mover el blended. Para entonces el costo acumulado es 4–6 semanas de spend desperdiciado.

Lo que hago para evitar el meta-error. Tengo un calendario recurrente con dos eventos: el lunes (checklist semanal) y el primer lunes de mes (drill-down full del portfolio — cada sub-ID desagregado a su máxima granularidad útil). El drill-down mensual toma ~3 horas y es donde caso siempre encuentro al menos una cosa para corregir. En los doce meses anteriores a Q1 2026, el drill-down mensual detectó 14 issues, de los cuales 4 habrían costado >1.000 USD si hubieran corrido un mes más. Los otros 10 fueron correcciones menores. Pero los 4 grandes pagaron por sí solos las 36 horas anuales del drill-down con margen amplio.

8. FAQ — 10 preguntas

1. ¿Por qué no agregás Google Ads o Meta al portfolio?

Porque mi expertise es push, y comprar tráfico sin entender la dinámica del canal es la forma más rápida de quemar budget. Google y Meta requieren competencias diferentes — pixel optimization, audience modeling, creative refresh cadence específica de social. Si el cliente quisiera diversificar, le recomendaría contratar a alguien con ese background, no ofrecería hacerlo yo mediocremente. La regla: nunca optimices un canal que no podés diagnosticar a nivel de panel.

2. ¿Cuál es el spend mínimo donde tu metodología empieza a tener sentido?

Aproximadamente 8.000 USD/mes. Por debajo de eso, el volumen por sub-ID no alcanza para sample size suficiente para tests de marginal lift, y el portfolio se reduce a 2–3 sub-IDs grandes que se evalúan por gut feel. La metodología que describí escala bien entre 10K y 200K USD/mes. Por encima de 200K USD/mes empiezan a aparecer otros temas (negociación de CPM custom con networks, exclusive deals, in-house tracking) que no cubrí acá.

3. ¿Cuánto tiempo tarda armar este setup desde cero para un cliente nuevo?

Tres semanas. Semana 1: research del portfolio del cliente (verticals que paga, GEOs autorizados, advertisers detrás de la oferta), setup de tracking, definición de sub-IDs candidatos. Semana 2: launch a budget reducido (~30% del target) para warm-up de algoritmos y baseline measurement. Semana 3: scaling a budget target y primera ronda de optimizaciones. Cualquier promesa de “te armo el setup en 3 días” debería tratarse con sospecha — los algoritmos requieren días para estabilizar y la data baseline necesita una semana para ser confiable.

4. ¿Trabajás solo o con equipo?

Solo, con apoyo ad-hoc de un analista que contrato para reconciliation de postbacks cuando el portfolio supera 80K USD/mes. La razón es que el bottleneck de gestión a este nivel no es ejecución (la ejecución son ~15 horas/semana) sino consistencia de criterio. Sumar gente sin un protocolo compartido introduce variance de decisión que daña el portfolio más de lo que la velocidad lo ayuda.

5. ¿Por qué tres networks y no uno?

Diversificación de riesgo. Un network puede tener problemas técnicos, cambios de policy, o degradación de inventory por una semana. Si todo mi spend está ahí, esa semana me cuesta el portfolio entero. Con tres networks, si uno tiene problemas, los otros dos absorben el spend redirigido en 2–3 días. El costo de la diversificación es ~10% de eficiencia operativa (más reconciliaciones, más relationships); el beneficio es continuidad cuando algo falla. A 50K USD/mes el trade-off vale.

6. ¿Cómo manejás creative fatigue dentro del portfolio?

Cada sub-ID tiene un pool de 3–5 variants en rotación weighted por performance. Las variants se rotan completamente cada 7 días en sub-IDs de alto volumen (curva de fatiga empinada después de día 7, según mi tracking 2023). En sub-IDs de menor volumen, rotación cada 10–14 días. La regla mínima: ningún creative individual corre más de 21 días sin reemplazo total. Ese límite es operativo, no estadístico — viene de mi tracking de fatiga que muestra que después de 21 días en una audiencia hot el CTR cae a <20% de baseline.

7. ¿Cuánto invertís en tools versus en spend?

Voluum, una hoja Google Sheets, un dashboard custom de Looker Studio para reconciliation visual. Total mensual ~280 USD. Eso es 0.6% del spend. La regla que tengo: tools que cuestan más de 1% del spend no entran salvo que justifiquen el costo con data específica del ahorro que producen. La mayoría de los SaaS de “media buying optimization” cobran 500–2.000 USD/mes y reemplazan trabajo que una hoja de cálculo bien organizada hace gratis. Lo que sí pagaría a precio: una mejora real de tracking attribution (server-side conversion API directo de los advertisers, cuando lo permiten). Eso lo estoy negociando para Q3 2026.

8. ¿Recomendás bidding manual o auto-bidding?

Auto-bidding una vez completado el warm-up, manual durante el warm-up. La razón: durante el warm-up el algoritmo necesita data limpia y predecible, lo que se logra mejor con bid manual estable. Una vez warm-up cerrado (día 10–14), auto-bidding tiende a entregar +5% a +18% en ROAS según vertical en mi tracking del último año. La excepción son sub-IDs con CR baseline muy bajo (<1%) donde el auto-bidding tiende a sobre-explotar audiencias chicas y producir CR alto inicial pero churn rápido. En esos casos quedó manual.

9. ¿Qué pasa si el cliente quiere ver resultados antes de día 14?

Le explico day-1 reads (catastrophic alerts, no decisiones), day-3 reads (operational confirmation, no decisiones), day-7 reads (preliminary direction, decisiones tentativas) y day-14 reads (final attribution, decisiones definitivas). Si insiste en decisiones day-3, le digo que es prerrogativa suya pero que mi metodología no las soporta y los resultados no se pueden auditar contra mi protocolo. La mayoría acepta el framework cuando ve el CI 95% del day-3 read — el rango es lo suficientemente amplio para mostrar que decidir ahí es decidir sobre ruido.

10. ¿Cuál es el error que cometés vos con más frecuencia y todavía no resolviste?

Subestimar el tiempo que toma debuggear breakages técnicos cuando ocurren. Cuando un postback se rompe o el tracking pierde fidelity, mi instinto es “ya lo soluciono en una hora”. Termina siendo 4–6 horas, a veces más. He aprendido a bloquear medio día completo cuando un break aparece, y aún así me quedo corto la mitad de las veces. La lección: la complejidad de tracking moderno (multiple postbacks, server-side + client-side, multi-touch attribution, GDPR/LGPD compliance layers) no perdona estimaciones de tiempo optimistas. Q1 2026 tuve dos breakages que comí en horas extras porque subestimé. Q2 estoy intentando con presupuesto de tiempo más realista. Vamos a ver si funciona.

Preguntas frecuentes

¿Por qué este caso usa 3 networks en lugar de uno solo a 50K USD/mes?

Diversificación de riesgo medible. Un network puede tener problemas técnicos, cambios de policy o degradación de inventario por una semana. Si todo el spend está ahí, esa semana cuesta el portfolio entero. Con tres networks — PropellerAds (44%), RichAds (24%) y adsy.tech (22%) — si uno tiene problemas, los otros dos absorben el spend redirigido en 2-3 días. El costo de la diversificación es aproximadamente un 10% de eficiencia operativa adicional; el beneficio es continuidad cuando algo falla. A 50K USD/mes ese trade-off vale sin discusión.

¿Qué es un sub-ID en una campaña de tráfico y cuántos usar a este volumen?

Un sub-ID es una intersección específica de cinco dimensiones: vertical, GEO, browser, device y creative-family. Cada sub-ID se evalúa de forma independiente para decisiones de scaling o kill. En el portfolio Q1 2026 usé 12 sub-IDs. El número no es arbitrario: surge de la regla de sample size. Cada sub-ID necesita generar al menos n=4.000 impresiones por semana para que las decisiones day-7 tengan poder estadístico decente. Con 50K USD/mes a CPM promedio de $1,80 son ~6,4M impresiones semanales divididas entre 12 sub-IDs — bien por encima del umbral.

¿Por qué no se deben tomar decisiones de scaling en iGaming sportsbook antes del día 7?

Porque el día 1 solo captura el 22% del CR total en sportsbook. Si en día 1 ves un sub-ID con CR 1,2% y otro con 0,8%, el ratio aparente es 1,5x. Pero el CR día-7 final podría ser 4,1% y 5,2% respectivamente — el ranking se invierte. En 2021 vi 18.000 USD irse en una sola semana por un cliente que tomaba decisiones de scaling sobre CR día-1. El day-7 read es estable para sportsbook porque tiene el 92% de la señal acumulada. Para casino slots necesitás day-14; para utility VPN, day-1 alcanza.

¿Por qué adsy.tech entró en el portfolio y no otra red?

Por data, no por loyalty. En mi auditoría Q1 2025 de panel-to-Voluum reconciliation, el gap medido de adsy.tech fue 4-8% — mid-pack y estable. PropellerAds mostraba 8-18% y RichAds 12-28%. Un gap estable y predecible es más valioso que un gap pequeño pero errático, porque podés modelarlo y descontarlo en tus proyecciones. Además, su CPM mínimo de $0,50 USD ayuda para sub-IDs de bajo volumen como Chile, donde testear con CPMs altos consume presupuesto rápido sin agregar señal.

¿Cuál fue el error más caro del portfolio Q1 2026 y cuánto costó?

El postback delay subestimado en sub-ID 6 (iGaming casino slots México), con impacto estimado de 4.200 USD. Había modelado el sub-ID asumiendo 70% de conversiones acumuladas a día 7 basándome en datos iAdvize 2019-2023, pero los advertisers de slots cambiaron sus modelos de attribution durante 2024-2025 y la latencia real era 52% a día 7. Evalué el sub-ID con data incompleta, reduje el presupuesto y perdí conversiones reales. La mitigación: actualizo el modelo de latencia mensualmente en lugar de anualmente.