Cómo recopilan datos las spy tools de ads

Conclusión clave: Las spy tools de ads (AdPlexity, Anstrex, Spy.House, BigSpy y similares) construyen sus bases de datos sobre todo registrándose como publishers en redes de anuncios push y native de terceros, y luego capturando cada bid response que llega a su propio JavaScript. Las redes lo toleran estructuralmente porque cobran dos veces por la misma actividad: una del anunciante original y otra de los copiones. Las defensas duraderas no son ocultarse (imposible contra un publisher al que pagas por entregar el creativo) sino reducir el valor de lo que se filtra: distintividad de marca que hace que las copias se vean inferiores, click URLs con token, personalización del lander en servidor, detección de bots en el borde del funnel, y replicar la propia mirada del operador de la spy tool sobre tus campañas mediante auditorías con proxies móviles desde ASN de operadora reales.

Las plataformas de inteligencia publicitaria para afiliados (AdPlexity, Anstrex, AdSpy, BigSpy, Spy.House, Mobidea y una larga cola de competidores más pequeños) venden acceso a bases de datos con millones de creativos publicitarios, buscables por GEO, vertical, anunciante y fecha. La mayoría de lo que se escribe sobre ellas en público se queda en “recopilan anuncios de las redes” y salta a la reseña de producto. Los mecanismos reales de recopilación son técnicamente interesantes, las defensas no son obvias, y casi nada serio se publica sobre ninguna de las dos cosas.

Los cinco mecanismos de recopilación

Cinco mecanismos fundamentalmente distintos alimentan una base de datos moderna de espionaje publicitario, cada uno con su propio perfil de ingeniería y su propia historia defensiva:

1. Infiltración como publisher: registrarse como publisher en redes push/native de terceros para capturar cada creativo que entregan. El tema de este artículo.
2. Captura de suscripciones push: explotar el protocolo Web Push para capturar payloads cifrados de notificaciones a través de un service worker controlado por el operador.
3. Librerías públicas de anuncios y scraping social: Meta Ad Library, TikTok Creative Center, Google Ads Transparency Center, más cuentas farmeadas haciendo scroll del feed para lo que las librerías no exponen.
4. MITM de SDKs in-app: granjas de dispositivos Android rooteados que interceptan el tráfico de SDKs de anuncios como AppLovin MAX, Google AdMob, ironSource y otros.
5. Crawling de landing pages y funnels: seguir los destinos de click del creativo a través de cadenas de tracker, cloaker y prelander para identificar la oferta, la red de afiliados, el software de tracking y todo el funnel revertido.

El modelo mental

El mecanismo dominante para bases de datos de espionaje en push, native, inpage y popunder es el más simple estructuralmente: el operador de la spy tool se convierte en publisher.

Imagínate una casa pequeña de tres pisos. Una pared da a una autopista con mucho tráfico. Otra pared mira parcialmente hacia un cruce más tranquilo. El dueño decide cómo cortar esas paredes para anuncios: diez paneles apretados en la pared que da a la autopista (mucha plata, casa fea, menos visitas que vuelven), o un solo banner pequeño con buen gusto en la pared lateral (menos ingresos, la casa sigue funcionando como casa). Esa decisión de cortar (qué espacio se ofrece y cómo se reparte) es lo que en ad-tech se llama inventory.

El dueño ofrece una disposición concreta de espacio disponible. Una red de anuncios firma contratos por los dos lados, con el dueño para llenar los slots, y con marcas para meter sus anuncios. La red gestiona el matching y se queda con una comisión.

Mapeado al mundo ad-tech:

Es tu pared. Tú la vendes. Te pagan por ella. Ves exactamente qué valla se pega encima, y cuándo. Todo lo que una base de datos de espionaje vende como “inteligencia competitiva” se deriva de ese único hecho.

Dos términos más usados abajo, glosados una vez y luego dados por sabidos: un vertical es el nicho en el que opera un anunciante (finanzas, seguros, e-commerce); un DSP es la plataforma del lado del comprador que el anunciante usa para comprar inventario en subastas en tiempo real. Si esto es terreno nuevo, IAB Tech Lab es la fuente canónica para los protocolos y Wikipedia sobre real-time bidding cubre lo básico en 10 minutos.

Los tres pasos

1. Regístrate como publisher. Formulario estándar de onboarding en cualquier red push/native. Entregas un dominio, aceptas términos, embebes el tag JavaScript de la red o configuras un subdominio CNAME para push.
2. Manda visitantes hacia el inventory. Tráfico barato de popunder/redirect a unos 0,50 USD por cada 1000 impresiones, o visitantes generados por ti mismo desde una granja de proxies residenciales o móviles corriendo navegadores reales contra la página fachada. Cada visitante dispara una llamada de anuncio.
3. Captura la bid response. La red manda los metadatos del creativo como JSON plano. El JS del publisher (código que el operador escribió) lee la respuesta, la postea al endpoint de recolección del operador, y luego renderiza el anuncio con normalidad para que nada se vea raro.

Las cifras públicas de escala son realistas con este modelo: Spy.House publica capturas de 12 millones de creativos por día en más de 185 países, y AdPlexity y Anstrex publican coberturas que se solapan en native, push y mobile. Una sola operación con 30 redes, 50 sitios fachada y 95 GEOs cae en ese rango sin esfuerzo.

Qué viaja realmente por el cable

El núcleo técnico es una petición HTTP y una respuesta HTTP por impresión, ambas totalmente visibles para el publisher porque es el propio JavaScript del publisher el que hace la petición.

Un tag típico de publisher:

<script async
  src="//cdn.adnetwork.example/sdk.js"
  data-zone-id="1234567"></script>

Al cargar la página el SDK arma una petición de anuncio. Como curl, lo que viaja por el cable se ve así:

curl -G "https://srv.adnetwork.example/req" \
  --data-urlencode "zone=1234567" \
  --data-urlencode "geo=DE" \
  --data-urlencode "device=android" \
  --data-urlencode "browser=chrome" \
  --data-urlencode "ua=Mozilla/5.0 (Linux; Android 14; SM-S921B) AppleWebKit/537.36" \
  --data-urlencode "referer=https://shell-site.example" \
  --data-urlencode "screen=412x915" \
  --data-urlencode "lang=de" \
  --data-urlencode "ts=1737542890"

La red corre su selección: una subasta de real-time bidding entre DSPs en los exchanges más grandes (el protocolo estándar es IAB OpenRTB ), o matching directo de campaña para los specialists de push/native, y devuelve el creativo ganador como JSON:

{
  "zone_id": 1234567,
  "campaign_id": 287465,
  "advertiser_id": 5821,
  "creative": {
    "title": "Stop overpaying for car insurance",
    "body": "Drivers in DE are switching — check rates now",
    "icon": "https://cdn.adnetwork.example/c/874513_icon.jpg",
    "image": "https://cdn.adnetwork.example/c/874513_main.jpg",
    "click_url": "https://trk.adnetwork.example/c?cid=287465&zid=1234567&sid=abc123&v=1.42"
  },
  "pricing": {
    "model": "cpc",
    "bid": 1.42,
    "currency": "USD"
  },
  "targeting_matched": {
    "geo": "DE",
    "carrier": "vodafone-de",
    "device_type": "mobile",
    "os": "android"
  }
}

Título, cuerpo, URLs de imágenes, destino de click, ID de campaña, ID de anunciante, precio de puja y el contexto de targeting que disparó el match: toda la entrega del anuncio en un único objeto estructurado. Después, el SDK del publisher renderiza el anuncio.

La interceptación es mecánica. El publisher controla JavaScript a nivel de página que corre antes del SDK; un wrapper de fetch o un shim de XMLHttpRequest ve todo:

// loaded before the network's SDK
(function () {
  const origFetch = window.fetch;
  window.fetch = async function (input, init) {
    const res = await origFetch(input, init);
    const url = typeof input === 'string' ? input : input.url;
    if (url.includes('adnetwork.example')) {
      // tee the response to the collector before returning to the SDK
      res.clone().json()
        .then(payload => navigator.sendBeacon(
          'https://collector.spy.example/p',
          JSON.stringify({ origin: location.hostname, ts: Date.now(), payload })
        ))
        .catch(() => {});
    }
    return res;
  };
})();

El SDK ve una respuesta idéntica y renderiza el anuncio con normalidad. El collector recibe el registro completo. El visitante ve un anuncio funcionando. Ninguna petición bloqueada, ninguna respuesta alterada, ninguna métrica de fallo subiendo en ningún sitio.

Modelos de precios y qué filtra cada uno

Distintas redes usan distintos modelos de precios, y el modelo determina qué campos llevan señal útil en la bid response. El vocabulario:

• CPM (cost per mille): el anunciante paga por cada 1000 impresiones. Default para push, popunder y la mayoría de native. PropellerAds, RichAds, Adsterra. Puja expresada en dólares por mil.
• CPC (cost per click): el anunciante paga por click. Común en MGID, Taboola, Outbrain native. Puja por click.
• CPA (cost per action): el anunciante paga por conversión (signup, depósito, instalación). Lo usan las redes de afiliados (AdCombo, MaxBounty, ClickDealer); las redes de anuncios rara vez lo usan directamente. La conversión ocurre del lado del servidor del anunciante, así que los pagos CPA no son visibles en la bid response.
• CPI (cost per install): CPA para apps móviles donde la acción es una instalación atribuida por un MMP (AppsFlyer, Adjust, Branch).
• CPV (cost per view): video, paga por vista completada.

El modelo que más inteligencia filtra es CPC. El importe de puja es una señal en tiempo real de cuánto está dispuesto a pagar un anunciante por click en ese GEO y vertical, fresca en cada impresión. Tres meses de histórico de pujas CPC por anunciante por GEO son un dataset de inteligencia competitiva que ningún anunciante consintió compartir, y se acumula como efecto colateral de la mirada ordinaria del publisher sobre la bid response.

En concreto, la API interna del operador de la spy tool acaba exponiendo endpoints como:

curl -G "https://api.spy-internal.example/v1/bids" \
  -H "Authorization: Bearer $TOKEN" \
  --data-urlencode "advertiser_id=5821" \
  --data-urlencode "geo=DE" \
  --data-urlencode "carrier=vodafone-de" \
  --data-urlencode "model=cpc" \
  --data-urlencode "from=2026-04-19" \
  --data-urlencode "to=2026-05-19"

que devuelven una serie temporal:

[
  {"ts":"2026-04-20T08:14Z","creative_id":874513,"campaign_id":287465,"bid":0.78},
  {"ts":"2026-04-21T08:14Z","creative_id":874513,"campaign_id":287465,"bid":0.84},
  {"ts":"2026-04-22T08:14Z","creative_id":874513,"campaign_id":287465,"bid":0.91},
  {"ts":"2026-04-23T08:14Z","creative_id":891204,"campaign_id":289103,"bid":1.12},
  {"ts":"2026-04-24T08:14Z","creative_id":891204,"campaign_id":289103,"bid":1.18}
]

El frontend comercial de la spy tool es una caja de búsqueda exactamente sobre esa forma. El cliente ve dropdowns de filtros y gráficos de trayectoria de puja; por debajo, la misma query de serie temporal contra la misma tabla normalizada de pujas, poblada impresión a impresión desde el bloque de interceptación JS de arriba.

CPM filtra menos por impresión pero es útil en agregado. Una sola puja CPM expresa la disposición a pagar por cada mil impresiones, fracciones de centavo cada una, y por sí sola dice poco sobre cómo valora el anunciante un click o una conversión. Es una función de presupuesto × match de audiencia × presión de subasta por una unidad de atención, no una lectura directa del modelo económico del anunciante.

Lo que importa es la distribución. A lo largo de miles de impresiones registradas para la misma campaña, la serie temporal CPM revela la forma del presupuesto (pujas que suben = presión para escalar; pujas que caen = agotamiento de presupuesto o dayparting), niveles de precio por GEO (el inventory DE puede liquidar a 3 USD CPM mientras VN liquida a 0,30 USD para el mismo vertical, exponiendo precios reales de mercado), prioridades de audiencia (qué cubetas de targeting atraen las pujas más altas) y duración de campaña. Nada de eso es visible en una impresión aislada; todo emerge tras unas pocas semanas de historial acumulado.

CPA no aparece en la bid response en absoluto: el operador de la spy tool no es el endpoint de conversión. Cerrar ese gap requiere seguir el destino del click por tracker, cloaker y offer wall, que es un mecanismo completamente distinto.

¿Por qué la puja viaja en la respuesta? Pregunta justa: la base de datos de espionaje está leyendo un número que la red, en principio, podría simplemente no mandar. Cinco razones que se superponen:

1. OpenRTB lo exige. El campo price es obligatorio en el schema BidResponse.seatbid.bid. Las redes que corren sobre OpenRTB heredan esa transparencia por diseño.
2. Verificación del revshare del publisher. Las redes push y native pagan al publisher entre el 60 % y el 80 % de la puja del anunciante. Ocultar el número equivale a perder confianza del publisher y perder inventory frente a un competidor que sí lo muestra. La opacidad es desventaja competitiva en el lado de la oferta.
3. Optimización de yield del publisher. Los publishers fijan suelos CPM por zona, hacen A/B testing de placements, ajustan densidad de creativos. Todo eso requiere datos de puja por impresión. Un publisher que no puede ver a cuánto liquida su inventory no puede optimizar lo que vende.
4. Renderizado del lado del cliente. Push, native, popunder e inpage los renderiza el propio JavaScript del publisher. La puja viaja en el mismo payload que la URL del creativo y la URL de click que el tag necesita para renderizar, así que se filtra sin coste extra para la red.
5. La URL de click suele codificar la puja. Muchas redes meten el valor de puja en la URL de tracking del click para reconciliar la facturación entre impresión y click. Aunque quitaras bid del JSON de nivel superior, viajaría dentro de los parámetros de la URL de click.

La excepción estructural es el caso walled-garden que detallamos abajo: Google AdSense agrega los ingresos del publisher a nivel de categoría en vez de exponer pujas por impresión. Esa opacidad es una de las tres defensas que hacen que la infiltración como publisher falle contra los walled gardens, y es una elección que las redes de terceros podrían replicar pero no replican, porque el valor de la transparencia hacia el publisher en onboarding y retención supera al coste del indexado a largo plazo por las spy tools.

OpenRTB y el bidstream

La mayoría de exchanges y muchas de las redes más grandes hablan el protocolo IAB OpenRTB. La bid request y la bid response siguen un schema JSON público , BidRequest, Imp, Seatbid, Bid, con campos documentados para dominio del anunciante (adomain), markup del creativo (adm), precio de puja (price), ID del creativo (crid) y taxonomía de categoría IAB (cat). Para un operador de spy tool, la red OpenRTB-compliant es el objetivo más fácil de procesar: los nombres de campo son predecibles, el schema está documentado, normalizar entre redes es trivial.

El pipeline práctico: un parser por cada formato legacy/propietario de red, un parser compartido entre todas las redes OpenRTB-compliant, todo el output normalizado a un único schema interno. La UI de búsqueda cross-network en el frontend de la spy tool es entonces una capa fina sobre esa tabla normalizada, por eso cada servicio de espionaje grande expone esencialmente el mismo set de filtros (GEO, dispositivo, OS, navegador, tipo de anuncio, rango de fechas, keyword de anunciante).

El camino más fácil: el dashboard del publisher

La interceptación a nivel de cable es el caso general. El caso específico es aún más simple: el propio dashboard del publisher de la red es una UI de búsqueda sobre los mismos datos. Logueado como publisher, el operador ve miniaturas de creativos, nombres o IDs de anunciantes, destinos de click, importes de puja sobre impresiones servidas, distribuciones por hora del día, IDs de campaña. El dashboard existe para que los publishers legítimos puedan monitorear y hacer brand-safety check sobre lo que les corre; para un operador de spy tool es la interfaz de export más fácil posible.

Donde el dashboard es rico, el operador lo usa. Donde es flojo, ausente o no documentado (en particular push, donde el payload Web Push cifrado a nivel de cable es más difícil de manejar sin controlar el service worker que lo descifra), la interceptación de cable rellena el hueco. Multiplicado por entre 25 y 40 redes, la base de datos resultante está estructurada, normalizada y aproximadamente al día con el estado en vivo de cada campaña push/native corriendo en el mundo.

El multiplicador de GEO

Un publisher en Brasil ve creativos brasileños. Para capturar creativos en 95 países, el operador necesita una de dos cosas:

1. Visitantes reales desde cada GEO hacia los sitios fachada del publisher, para que la red de anuncios sirva inventory geo-segmentado de forma natural. Los operadores compran tráfico barato (popunder, redirect, push) de otras redes y lo enrutan por sus propios sitios publishers para disparar las llamadas de anuncios. La economía: una impresión de redirect cuesta 0,0005 USD y genera un creativo servido que vale la pena indexar.

2. Visitantes sintéticos mediante proxies residenciales o móviles, ejecutando la página del publisher con un navegador real para cargar el ad tag y capturar la respuesta. Esta vía es más cara por impresión pero produce cobertura limpia y segmentada por operadora que el tráfico de redirect barato no da. Los marketplaces de espionaje más grandes hacen cross-sell de proveedores de proxies móviles y residenciales como categoría primaria de partners justamente por esto.

La dimensión de operadora móvil importa específicamente: las redes de anuncios segmentan por el ASN de la operadora de la IP que pide. Los proxies datacenter genéricos aparecen como “Wi-Fi/unknown” y se pierden por completo las campañas segmentadas por operadora. Los proxies móviles a través de endpoints reales de operadora exponen campañas que solo se disparan, por ejemplo, para suscriptores de Vodafone IT o Vivo BR, que es exactamente el inventory que vale la pena espiar porque ese targeting sugiere una campaña rentable y bien afinada.

Por qué las redes de anuncios lo toleran estructuralmente

El loop económico es la respuesta:

Anunciante paga a la Red de Anuncios
        ↓
Red de Anuncios sirve el creativo al sitio "publisher" del operador de la spy tool
        ↓
Red de Anuncios paga al operador de la spy tool su revenue como publisher  ← incentivo de la red
        ↓
El operador de la spy tool registra cada creativo y vende acceso a otros afiliados
        ↓
Otros afiliados lanzan campañas copia a través de la misma Red de Anuncios
        ↓
La Red de Anuncios cobra más revenue del anunciante (el loop se cierra)

A la red de anuncios le pagan dos veces por la misma actividad. El gasto del anunciante original financia el pago al spy operator. El gasto del anunciante que copia financia el siguiente ciclo. Las redes no tienen incentivo para detectar o banear a estos publishers, y hay evidencia observable de esta alineación: PropellerAds mantiene un índice dedicado /blog/tag/spy-tools/ en su blog corporativo, RichAds publica un listicle de mejores spy tools de push, y Adsterra corre su propio post de recomendaciones de “best ad-spy tools”, los tres cubriendo el mismo set de plataformas que indexan su propio inventory, a menudo con links de afiliado a esas herramientas. Las redes no son adversarias del ecosistema de espionaje; son una capa complementaria.

Por qué los walled gardens son distintos

El mecanismo de arriba funciona en PropellerAds, RichAds, MGID y las otras 30 y pico redes push/native de terceros porque esas redes están entre los anunciantes y un ecosistema abierto de publishers independientes. Cualquiera con un dominio se convierte en publisher; la red no tiene superficie first-party propia y no tiene forma de entregar un anuncio sin un publisher que lo aloje. El publisher es el canal de entrega outbound de la red. El operador de la spy tool se convierte en uno.

Google Search, Meta (Facebook e Instagram), TikTok y LinkedIn no funcionan así. Sus anuncios corren en sus propias superficies first-party (la página de resultados de Google, los feeds de Instagram y Facebook, el For You de TikTok, la timeline de LinkedIn), renderizadas por sus propias apps y servidores. El anunciante les paga a ellos; ellos muestran el anuncio directamente al usuario en su propiedad. No hay inventory de publishers terceros donde registrarse, no hay tag JS que nadie pueda embeber para recibir posts patrocinados de Meta, no hay API para suscribirse a los anuncios de Google Search desde fuera de las superficies de Google. La superficie de servicio es la plataforma.

Donde los walled gardens sí tienen redes de publishers terceros (Google AdSense y el Google Display Network más amplio, Meta Audience Network para in-app), tres defensas estructurales evitan que la infiltración como publisher funcione.

1. Iframes cross-origin

Los anuncios AdSense cargan dentro de un iframe servido desde googleads.g.doubleclick.net o tpc.googlesyndication.com. El JavaScript del publisher corre en la página padre; el anuncio corre en el iframe; la política same-origin del navegador hace invisible el contenido del iframe al código del publisher:

// the publisher's page tries to inspect the ad iframe
const adFrame = document.querySelector('iframe[src*="doubleclick"]');

adFrame.contentDocument;
// → null  (same-origin policy blocks access)

adFrame.contentWindow.document.body;
// → DOMException: Blocked a frame with origin "https://my-publisher.example"
//                 from accessing a cross-origin frame.

El publisher le alquila un rectángulo vacío a Google. Ni metadatos de puja, ni URL del creativo, ni identidad del anunciante alcanzables desde el código del publisher.

2. Selección server-side sin bid response expuesta

Google elige qué anuncio mostrar en su propia infraestructura. El publisher recibe un anuncio ya renderizado dentro del iframe sandboxed, no una bid response JSON con ID de anunciante, ID de campaña y metadatos del creativo. El dashboard del publisher muestra revenue agregado por categoría IAB, no historial de pujas por creativo, y hasta esas categorías son deliberadamente genéricas (“Finance > Insurance”, no “Allianz under-30s EU campaign”). La mirada del publisher sobre lo que corre por su propiedad es de baja resolución por diseño.

3. Enforcement agresivo a nivel de cuenta

Tanto Google como Meta corren operaciones dedicadas de trust-and-safety en el lado del publisher, con detección de fraude basada en ML, junto con prohibiciones explícitas en los Términos de Servicio sobre scrapear, interceptar o fingerprintar anuncios servidos a través de tu cuenta. La respuesta estándar es la terminación de cuenta más la retención del revenue, aplicada a escala. La estructura de incentivos es opuesta a la de PropellerAds: los walled gardens pierden plata con el fraude del publisher en vez de ganar más con él, así que lo vigilan.

El efecto combinado: las únicas formas programáticas de ver anuncios de Meta o Google a escala son las propias librerías de anuncios de las plataformas y las cuentas farmeadas que hacen scroll del feed contra la superficie de usuario. La interceptación de publisher a nivel de cable, el truco universal en redes de terceros, no sobrevive al contacto con la arquitectura walled-garden.

Detección desde el lado del anunciante

Para un anunciante que corre una campaña y quiere saber si lo están indexando:

1. Inyecta huellas únicas en las URLs de click. Un query param que codifica un token aleatorio por creativo, logueado en el servidor de la landing. Si ese token aparece en los resultados de búsqueda de una spy tool, o en tu propio análisis de competencia, el creativo ya está indexado.

2. Audita el tráfico de click buscando referrers de spy tools. Las bases de datos de espionaje hacen preview de las landings fetcheándolas desde su infraestructura. El User-Agent del fetch, los rangos de IP (a menudo subnets cloud conocidas en EU y US) y la ausencia de ejecución de JS son detectables en el servidor de la landing.

3. Lanza creativos señuelo con texto distintivo pero sin sentido, con pujas pequeñas. Busca ese texto en las spy tools tras 48 horas. Las que lo expongan, lo tienen; las que no, todavía no.

Movimientos defensivos

Leyenda: ✓ cobertura completa (la defensa bloquea el mecanismo) · ◐ parcial (ayuda pero no bloquea del todo) · ○ sin efecto.

La alineación estructural entre redes de anuncios y bases de datos de espionaje (redes pagadas dos veces por la misma actividad) significa que no hay forma de ser anunciante pago en redes push o native y evitar ser indexado. El creativo se va a filtrar. Lo que un anunciante sí controla son dos cosas: reducir el valor de lo que se filtra (para que la copia no le sirva al copión) y hacer que la filtración sea comercialmente inútil (para que ni siquiera una copia perfecta mueva producto). Las defensas debajo van de la más fundamental a la más táctica.

Tres términos usados a lo largo de esta sección, dado que no los introdujimos antes:

• Lander o landing page: el sitio destino al que lleva el click. El creativo es lo que aparece en el feed del usuario; el lander es la página que se carga tras el click.
• Funnel: la cadena completa desde el creativo, pasando por redirects de tracking, hasta el lander y de ahí a la acción que el anunciante quiere de verdad (un signup, una compra, una instalación).
• Cloaker: un filtro server-side en el funnel que muestra contenido distinto a distintos tipos de visitante: los compradores reales ven la oferta de verdad, los bots y crawlers ven un señuelo genérico. La palabra se asocia sobre todo con el marketing de afiliados en zona gris, pero el mecanismo subyacente (distinguir un visitante humano de un scraper) es práctica estándar en prevención de fraude legítima, personalización regional y defensa contra bots, que es lo que Cloudflare Bot Management , DataDome y FingerprintJS Pro hacen para marcas grandes.

1. Distintividad de marca: la única defensa duradera

Un creativo difícil de copiar convincentemente vale más que uno difícil de encontrar. Si un competidor puede levantar tu creativo, cambiar el nombre de la marca y el resultado sigue siendo plausible para tu audiencia, la fuga mueve plata. Si el cambio se lee como obviamente falso, no. Tipografía, paleta de color, estructura visual y voz distintivas cargan más peso defensivo que cualquier contramedida técnica: la misma lógica que ha protegido a las campañas de vallas publicitarias icónicas durante un siglo.

La prueba práctica: agarra tu creativo, reemplaza tu marca por la de un competidor y pregúntate si todavía se lee como un anuncio creíble para ellos. Si sí, el asset es genérico y la fuga es peligrosa. Si “esto obviamente no es suyo”, la fuga es prácticamente inofensiva. Un competidor corriendo el mismo copy con su nombre puesto se ve como una copia barata para cualquiera que ya te conozca.

2. Separa el hook de la oferta

Un creativo distintivo es difícil de copiar convincentemente. Un creativo cargado de oferta es fácil de leer. Mantén las especificaciones (nombre del partner, precio, segmento objetivo, CTA exacta) fuera de la unidad y detrás del click. Un anuncio que dice “Allianz baja a 18 €/mes para menores de 30, firma aquí” le entrega al competidor el partner, el precio, el segmento y el funnel de un solo vistazo. El mismo hook con tu voz distintiva, con las specs gateadas detrás del lander, regala el ángulo pero no el playbook.

3. Click URLs con token

Cada URL de click lleva un token por-click, firmado del lado del servidor con expiración corta. Una a cuatro horas alcanza. Tu lander valida el token; tokens expirados o reproducidos caen en una página genérica en vez de en la oferta real. Un crawler de spy tool captura la URL una vez, la URL está muerta cuando aparece en la base de datos, y la jugada más simple de análisis de competencia (replicar el click capturado) deja de funcionar.

El creativo lleva una única URL estática apuntando a tu propio redirector (https://track.tu-marca.com/c/<creative-id>). Esa es la URL que la red indexa y guarda. Cuando llega un click real, el redirector firma un token fresco y hace un 302 al lander con el token pegado. Usa 302, no 301: 301 es cacheable, lo que congelaría un token sobre la URL para todos los visitantes que vengan después; 302 fuerza cada click a volver a pasar por tu servidor para conseguir un token fresco.

const crypto = require('node:crypto');

const SECRET = Buffer.from('<rotated server-side secret>');
const TTL = 4 * 3600; // 4 hours

// In the redirector, on each click:
function sign(creativeId) {
  const nonce = crypto.randomBytes(8).toString('hex');
  const payload = `${creativeId}.${Math.floor(Date.now() / 1000)}.${nonce}`;
  const sig = crypto.createHmac('sha256', SECRET).update(payload).digest('hex').slice(0, 16);
  return `${payload}.${sig}`; // appended to the click URL as ?t=...
}

// On the lander, before revealing the offer:
function verify(token) {
  const [creativeId, ts, nonce, sig] = token.split('.');
  const payload = `${creativeId}.${ts}.${nonce}`;
  const expected = crypto.createHmac('sha256', SECRET).update(payload).digest('hex').slice(0, 16);
  const sigBuf = Buffer.from(sig);
  const expBuf = Buffer.from(expected);
  if (sigBuf.length !== expBuf.length) return false;
  return crypto.timingSafeEqual(sigBuf, expBuf)
      && Math.floor(Date.now() / 1000) - parseInt(ts, 10) < TTL;
}

Las grandes plataformas de atribución (AppsFlyer con OneLink + Protect360, Branch, Adjust, Google Campaign Manager 360) generan sus propios IDs por click y corren detección de fraude server-side (click replay, spoofing, tráfico bot) dentro de su infraestructura, pero el veredicto llega como un flag post-atribución en tu dashboard, no como una operación primitiva que tu lander pueda comprobar en tiempo de request. El patrón de token firmado de arriba se monta sobre cualquier plataforma que uses; va apuntado específicamente al vector de replay del crawler de la spy tool, que las suites de click-fraud no están diseñadas para cubrir.

La ventana de expiración es un trade-off. Demasiado corta (menos de una hora) y los usuarios reales que abren una pestaña y vuelven al día siguiente caen en la página señuelo, perjudicando la conversión. Demasiado larga (más de un día) y las spy tools agarran URLs vivas más rápido de lo que expiran. Cuatro horas cubre la enorme mayoría de la latencia legítima de click en tráfico móvil y esquiva la mayoría de las ventanas de refresh de las spy tools. Para campañas sostenidas, rota la clave de firma semanalmente para que ni los tokens capturados validen contra la clave actual.

4. Personalización server-side en el lander

El lander no es un HTML estático con los detalles de la oferta horneados. Se renderiza por visitante desde el contexto del request: GEO, dispositivo, referrer, parámetros del click, hora. Dos visitantes pegándole a URLs que parecen idénticas ven páginas materialmente distintas. Un crawler de spy tool captura una vista sintética; la vista capturada no representa lo que ven los clientes reales, y la base de datos del espía fragmenta tu campaña en snapshots específicos al contexto en vez de registrar un solo lander canónico para copiar.

Los inputs que controlan la variación son primitivas de contexto de request que cualquier stack web ya tiene: GEO (desde IP o click param), ASN de operadora, clase de dispositivo, OS, navegador, entropía del referrer, timestamp del click, e IDs de campaña/creativo cargados en la URL de click. Cada input cambia qué variante de oferta, qué método de pago, qué bloque de copy y qué precio ve el visitante. Un crawler de spy tool desde un ASN datacenter en Frankfurt visitando una URL de click pensada para Vodafone IT 5G en iOS ve una variante fallback que no tiene nada que ver con el targeting real de la campaña.

La línea entre personalización y cloaking es intención y disclosure. La personalización trata a cada visitante legítimo como un caso de primera clase y le muestra la oferta con la que efectivamente lo segmentaron; los únicos visitantes que ven contenido señuelo son aquellos cuyo contexto de request no coincide con ninguna audiencia servida (bots, crawlers de spy tools, tráfico de revisión publicitaria de la propia red cuando aplica). El cloaking en sentido estricto del afiliado intencionalmente engaña a los revisores de compliance de la red. El mismo mecanismo implementa ambos; la legitimidad vive en qué se le muestra al tráfico de revisión de la red comparado con lo que ve un visitante no segmentado.

El detalle con toda esta lógica ramificada: no la puedes verificar desde la oficina. Cargar tu propio lander desde una IP datacenter, una VPN de consumo o una laptop con Wi-Fi de tu casa cae en la rama fallback por diseño, exactamente lo que las reglas de personalización bloquean. La única prueba de verdad de terreno es cargar el lander con el contexto de request que efectivamente segmentas: mismo ASN de operadora, mismo GEO, misma clase de dispositivo. iProxy.online convierte un teléfono Android con SIM local en un proxy móvil dedicado sobre la IP real de operadora, así que puedes cargar el lander como lo haría un visitante real de Vodafone IT 5G y confirmar que la variante servida coincide con el targeting antes de escalar gasto. La misma flota sirve también como auditoría de spy-defense: replica la URL capturada en una base de datos de spy tool desde la misma IP de operadora y chequea si tu lógica señuelo realmente se dispara para el contexto en el que estaba el crawler.

5. Detección de bots en el borde del funnel

Esta es la aplicación legítima y defendible de técnicas tipo cloaking. Capas estándar de mitigación de bots en el borde del lander identifican visitantes automatizados y los rutean lejos del contenido real de oferta. La misma maquinaria que los retailers online corren contra credential stuffing y bots que acaparan inventario aplica acá: el crawler de la spy tool es un bot; la detección de bots mantiene la página de oferta fuera de su alcance. El lander capturado se convierte en un señuelo genérico, y el valor de la base de datos de espionaje para un competidor que copia se degrada en consecuencia.

Qué cazan en concreto los grandes productos de mitigación de bots: Cloudflare Bot Management puntúa cada request sobre una combinación de huella TLS, ordenamiento de frames HTTP/2, reputación de IP, historial conductual y un confidence challenge; DataDome capa señales similares con foco en comportamiento del lado de la aplicación (movimiento del mouse, cadencia de scroll, timing de campos de formulario); FingerprintJS Pro enfatiza huellas digitales del navegador durables que sobreviven al borrado de cookies y al modo incognito. Un crawler de spy tool headless desde una IP datacenter limpia falla los tres en las señales básicas; un crawler sofisticado corriendo un Chromium real detrás de un proxy residencial pasa una o dos, rara vez el stack completo.

Donde esta defensa se pone ruidosa es alrededor del tráfico de operadora móvil. Las IPs de proxy móvil desde ASN reales de operadora rutean a través de CG-NAT y se ven conductualmente idénticas a visitantes móviles legítimos: mismo pool NAT, mismo perfil TLS, mismas huellas de dispositivo. Una regla bruta tipo “bloquear todo el tráfico residencial o de proxy móvil” te va a perjudicar la tasa de conversión en usuarios móviles reales más de lo que ralentiza a un operador de spy tool competente. Afina el umbral de detección de bots contra el impacto en conversión: los falsos positivos en móvil cuestan plata real, así que prefiere señales conductuales (patrones de interacción, tiempo en página, engagement con formularios) sobre bloqueos por clase de IP para el segmento móvil.

El patrón que vemos más seguido: un equipo afina las reglas de detección de bots contra la forma de tráfico de una operadora, y después confía de más en la regla sobre una operadora distinta del mismo GEO. Las señales que de verdad separan operadoras y clases de dispositivo viven debajo de las capas que un navegador antidetección o un cloud phone pueden repintar: el MTU de la SIM difiere entre operadoras, las huellas del stack TCP difieren entre clases de dispositivo, y ambas son primitivas a nivel de kernel que una herramienta de userspace no puede falsificar. Un umbral afinado sobre iPhones de Vodafone IT puede flaggear a visitantes Android legítimos de TIM IT una semana después. Prueba contra al menos dos combinaciones operadora × dispositivo por mercado objetivo antes de cerrar el umbral.

Afinar ese umbral con honestidad requiere probar desde el propio contexto de request. Un proxy móvil de iProxy.online te da un ASN real de operadora con ruteo CG-NAT y un perfil TLS de dispositivo genuino; emparejado con un navegador antidetección, te deja cargar tu propio lander como visitante móvil legítimo y como crawler más sofisticado tratando de imitar a uno. Sube las reglas hasta que cacen el setup antidetección, y bájalas hasta que dejen de castigar la línea base de móvil pelado. La brecha entre esos dos umbrales es tu ventana de operación.

6. Dynamic Creative Optimization (DCO)

Funcionalidad estándar de la industria en Meta, Google y la mayoría de DSPs programáticos: variación automatizada de componentes del creativo (titular, imagen, CTA, color, copy) en el momento de la impresión. Cuando cada creativo servido es una combinación ligeramente distinta, la base de datos del espía no ve un solo “ganador” claro que valga la pena copiar. Ve variantes fragmentadas que no se agrupan, así que los competidores que corren campañas copia testean contra los supuestos equivocados y queman presupuesto. DCO es una jugada defensiva sin coste incremental: las plataformas la soportan nativamente.

Los ejes de variación que más pesan para fragmentación defensiva: titular (3 a 10 variantes), imagen principal (3 a 8 variantes), texto del botón CTA (3 a 5 variantes) y color de acento (2 a 4 variantes). Combinatoriamente, cuatro ejes con cinco variantes cada uno producen 625 combinaciones servidas. Una base de datos de espía scrapeando 200 de esas impresiones ve lo que parecen 200 creativos distintos; ninguna combinación domina los datos, ningún “mejor” claro emerge, y un competidor corriendo su campaña copia contra el set capturado testea cada variante por igual y no aprende nada sobre cuál convierte.

DCO es más difícil de escapar en redes push y native de terceros que en los walled gardens. Meta Advantage+ Creative y Google Performance Max hacen variación a nivel de componente automáticamente; PropellerAds y redes push similares aceptan múltiples variantes de creativo bajo una campaña pero usualmente no fragmentan componentes dentro de un solo creativo. El workaround en push: lanzar entre 20 y 30 micro-variantes del creativo como unidades separadas dentro de la campaña, asegurando que ningún creativo único domine las impresiones. Más pesado operativamente que el equivalente walled-garden pero alcanza la misma fragmentación defensiva.

7. Watermarking a nivel de píxel

Marcadores esteganográficos embebidos en imágenes, videos y copy del creativo: imperceptibles para el espectador, recuperables desde una copia capturada. Toolchains open-source como watermark-anything de Meta demuestran payloads de imagen production-grade que sobreviven a la recodificación JPEG, al resize y al camino captura-y-recomprime que suele usar un crawler de spy tool para ingerir creativos. El mismo principio se extiende al texto vía substitución de espacios en blanco Unicode. Un paper de método reciente cataloga el enfoque para titulares y líneas de copy, donde variantes de caracteres invisibles codifican un ID por impresión sin alterar el texto renderizado. Ninguno previene el indexado. Ambos identifican qué bases de datos de spy tools capturaron qué creativos y cuándo, que es inteligencia útil sobre la investigación competitiva: quién está estudiando tus campañas, en qué calendario, a través de qué caminos de recopilación.

8. La velocidad le gana a la ocultación

Las bases de datos de espionaje van con retraso: de 24 a 72 horas las más rápidas, a veces una semana en la cola larga. Un equipo que lanza una nueva variante de creativo cada 48 horas va consistentemente por delante de los competidores que copian la anterior. Para campañas de test esto es defensa completa; para presencia de marca sostenida es parcial, y el punto de distintividad de marca en el #1 carga el resto del peso.

9. Replica lo que ven las bases de datos de espionaje

La defensa que los anunciantes saltan sistemáticamente es auditar sus propias campañas desde el mismo punto de vista que usa una base de datos de espionaje. Si el único lugar donde ves tu propio creativo es en el dashboard de reportes de la red, no tienes idea de cómo se le presenta al tipo de tráfico que los operadores de spy tools efectivamente capturan: visitantes sintéticos desde IPs residenciales y de operadora móvil en cada GEO objetivo. Las redes segmentan la entrega por ASN de operadora; un creativo que sirve limpiamente a la IP de tu oficina sobre Wi-Fi puede nunca llegar al suscriptor de Vodafone IT 5G al que la red realmente está apuntando. Estás volando a ciegas sobre lo que tus competidores pueden comprar acceso.

La auditoría es mecánica: levanta un navegador real a través de un proxy de operadora móvil en cada GEO objetivo, carga una página publisher corriendo la red de anuncios relevante y captura el creativo servido y la bid response sobre una ventana de muestra. El resultado es la vista que tiene el operador de spy tool sobre tu campaña: qué creativos salen, a qué niveles de puja, contra qué parámetros de targeting. Si tu creativo “Vodafone IT 5G menores de 30” no aparece en la auditoría por operadora, la red no lo está entregando como pensaste, y la misma brecha de entrega es invisible para tu reporting. Si sí aparece, sabes exactamente qué forma de tu campaña queda corriente abajo de cualquier base de datos de espionaje. Corre el navegador de auditoría a través de un perfil antidetección atado al proxy móvil para que la vista capturada coincida con lo que vería un visitante real en ese contexto.

10. Diversifica el footprint por operadora de tus campañas

Una campaña apuntando a “DE móvil” corre como una sola cubeta ancha. Una campaña segmentada en “DE / Vodafone DE 5G menores de 30”, “DE / Telekom DE 4G todas las edades”, “DE / O2 DE 5G urbano”, y así, corre como una docena de cubetas estrechas. El volumen total de impresiones es el mismo; el footprint en la base de datos de espionaje no.

Los operadores de spy tools consultan su base de datos normalizada por GEO, dispositivo, OS, navegador y los campos de contexto de targeting de la red. Una campaña de cubeta ancha se agrupa en una sola rebanada contigua de la DB del espía: consulta “DE móvil [vertical]” y toda la campaña aparece en una vista. Una campaña de cubetas estrechas se fragmenta entre consultas: ningún comprador de inteligencia competitiva combina naturalmente una docena de filtros específicos de operadora, edad y dispositivo para reconstruir la campaña completa, y los creativos capturados se reparten entre celdas que parecen campañas pequeñas separadas en vez de una sola campaña grande. El mismo gasto total, el mismo alcance total, una señal fundamentalmente distinta en cualquier base de datos de espionaje.

Esto funciona porque las redes de anuncios segmentan la entrega por ASN de operadora como campo de targeting de primera clase. La misma propiedad que hace posible las auditorías con proxy móvil del #9 hace significativa la diversificación por cubeta de operadora acá. Los proxies datacenter o residenciales genéricos que enmascaran el ASN de operadora no pueden entregar esta defensa; el pool de visitantes de operadora móvil del operador de la spy tool está él mismo segmentado por operadora, así que una campaña que opera en cubetas estrechas de operadora se mantiene fragmentada en la base de datos del espía incluso tras la captura.

Pensamiento final: la valla siempre se ha copiado

La publicidad en vallas se ha pirateado durante un siglo, y Coca-Cola no tiene un cuarto de guerra para frenarlo. Tiene algo más poderoso: una identidad creativa tan distintiva que una copia es visiblemente una copia. Las defensas técnicas dan días de ventaja; la distintividad de marca da décadas.

La casa en la autopista nunca puede impedir que la gente mire la pared. El dueño sí decide qué se pinta en ella, y una pintura reconocible en todas partes no pierde su valor el día que alguien le toma una foto.