Un juez que mueve dinero cada noche es tan peligroso como útil si se alimenta de datos rotos. La diferencia entre una automatización seria y una bomba de relojería está en lo que se niega a hacer. Esta lección cierra el módulo con la ingeniería de seguridad: anomalías, monedas, límites y la auditoría del propio juez.
Los datos que engañan
| Anomalía | Qué parece | Qué es | Cómo se detecta |
|---|---|---|---|
| CPA de un día × 20 | Campaña desbocada | Clics caros de hoy cuyas conversiones llegarán mañana (latencia) | Día aislado, sin conversiones aún, fuera de la ventana de latencia |
| Conversiones a cero con clics normales | Campaña que dejó de funcionar | Medición rota | Acción "sin conversiones recientes"; diagnóstico |
| Pico de conversiones de un día | Campaña brillante | Subida offline masiva (un lote del CRM), duplicados, spam | Conversiones por fecha de conversión vs fecha de clic; lote en la hoja de subidas |
| Gasto a la mitad de golpe | Target imposible | Presupuesto cambiado por otro usuario, límite de inversión, rechazo | Historial de cambios; estado de anuncios |
| CPA real muy distinto del esperado en una cuenta nueva del MCC | Campaña mala | Moneda distinta (pesos, coronas) con umbrales pensados en euros | Moneda de la cuenta |
Umbrales que escalan con la moneda
Un caso real de la suite: un umbral anti-anomalía de "CPA > 1.000 = dato roto" funcionaba en euros y reseteaba CPAs a cero en una cuenta en pesos colombianos, donde 1.000 COP es calderilla y un CPA normal son decenas de miles. La lección: todo umbral absoluto debe escalar con un factor de moneda (tipo aproximado a EUR o USD), y todo juez que opera en un MCC con varias monedas debe leer la moneda de cada cuenta al empezar su ejecución. Lo que vale para los scripts vale para cualquier hoja de reglas.
Diseño «si falla, no toca»
Reglas de ingeniería de un juez seguro:
- Lectura completa antes de escribir: si falta cualquier dato (conversiones, IS, estado), no se decide sobre esa campaña.
- Transacción por campaña: un fallo al escribir una campaña no deja otra a medias; y la que falló se queda como estaba.
- Verificación posterior: tras escribir, releer y confirmar que el valor es el esperado; si no, avisar.
- Modo TEST como estado por defecto de toda campaña nueva en el sistema: semanas de veredictos registrados sin aplicar.
- Sin decisión en aprendizaje ni dentro de la espera tras el último movimiento.
- Registro de todo, incluido lo que no se hizo y por qué ("anomalía", "sin datos", "en espera").
Límites absolutos
Aunque la matriz diga otra cosa:
- Presupuesto por campaña entre un mínimo y un máximo fijados por el plan (lección de planificación).
- Target entre un suelo y un techo por campaña (nunca un tCPA de 1 € por una cadena de pasos).
- Máximo de campañas movidas por noche (si el juez quiere mover 30 de 30, algo pasa en los datos, no en las campañas).
- Movimiento máximo acumulado por mes (±40 % en presupuesto, por ejemplo).
Son cortafuegos: raramente actúan; cuando actúan, evitan el desastre.
Cambios de otros
El juez no está solo: otros usuarios, reglas automáticas, recomendaciones aplicadas y scripts de terceros tocan la cuenta. Antes de cada decisión, el historial de cambios de la campaña en la ventana: si hubo un cambio externo de presupuesto o target, el juez se abstiene y avisa. Dos sistemas moviendo la misma palanca es la receta del aprendizaje eterno.
La auditoría mensual del propio juez
Una vez al mes, con el registro:
- Precisión: de los movimientos de hace 3-4 semanas, ¿cuántos mejoraron el cumplimiento? ¿Cuántos hubo que revertir?
- Falsos positivos: anomalías detectadas que eran reales, y decisiones tomadas sobre datos que luego resultaron rotos.
- Bandas y pasos: ¿demasiado nervioso (muchos movimientos pequeños) o demasiado lento (incumplimientos largos sin acción)? Ajustar.
- Límites: ¿saltó algún cortafuegos? ¿Por qué?
- Cobertura: campañas "sin datos" crónicas → reestructurar.
Un juez que se audita mejora; uno que no, acumula sesgos.
💡 Truco ninja: la mayoría de estas salvaguardas nacieron de incidentes reales en la suite — el umbral de moneda, el "si falla no toca", la verificación tras escribir, la abstención ante cambios externos. Ninguna es elegante; todas son baratas comparadas con un lunes de presupuestos reseteados. Si construyes tu propio juez, copia la lista antes que la matriz.
Qué debes recordar
- Anomalías típicas: latencia, medición rota, lotes offline, cambios externos, moneda.
- Umbrales que escalan con la moneda y juez que lee la moneda de cada cuenta.
- «Si falla, no toca»: lectura completa, transacción por campaña, verificación, Modo TEST, registro de lo no hecho.
- Límites absolutos como cortafuegos; abstención ante cambios de otros; auditoría mensual del juez.
Fin del Módulo 4. El Módulo 5 entra en el fraude publicitario: granjas, apps, bots, IPs — y cómo se defiende una cuenta.