Como spy tools de anúncios coletam dados (e como reagir)

Resumo essencial: Spy tools de anúncios (AdPlexity, Anstrex, Spy.House, BigSpy e companhia) montam suas bases principalmente ao se cadastrar como publishers em redes de anúncios push e native de terceiros e capturando cada bid response que o próprio JavaScript delas recebe. As redes toleram isso estruturalmente porque ganham receita duas vezes com a mesma atividade: uma vez do anunciante original, outra dos copiadores. As defesas duradouras não são esconder o criativo (impossível contra um publisher pago para entregá-lo), e sim reduzir o valor do que vaza: distintividade de marca que faz a cópia parecer pior, URLs de clique com token, personalização server-side na lander, detecção de bots na borda do funil e auditorias da própria campanha via proxies móveis em ASN de operadora real, o mesmo vantage point que o operador da spy tool usa.

Plataformas de ad intelligence para afiliados (AdPlexity, Anstrex, AdSpy, BigSpy, Spy.House, Mobidea e uma cauda longa de concorrentes menores) vendem acesso a bases com milhões de criativos pesquisáveis por GEO, vertical, anunciante e data. A maior parte do que se escreve publicamente sobre elas para em “elas coletam anúncios de redes de anúncios” e parte para a análise do produto. Os mecanismos reais de coleta são tecnicamente interessantes, as defesas contra eles não são óbvias e quase nada sério é escrito sobre nenhum dos dois.

Os cinco mecanismos de coleta

Cinco mecanismos fundamentalmente diferentes alimentam uma base moderna de ad spy, cada um com seu perfil de engenharia e sua história de defesa:

1. Publisher infiltration: cadastrar-se como publisher em redes push/native de terceiros para capturar cada criativo que elas entregam. Objeto deste artigo.
2. Coleta de assinaturas push: explorar o protocolo Web Push para capturar payloads de notificação criptografados via um service worker controlado pelo operador da spy tool.
3. Bibliotecas públicas de anúncios e scraping de anúncios sociais: Meta Ad Library, TikTok Creative Center, Google Ads Transparency Center, mais scroll de feed via account farms para o que as bibliotecas não expõem.
4. MITM em SDK in-app: parques de Android rooteados interceptando o tráfego dos SDKs de anúncio do AppLovin MAX, Google AdMob, ironSource e similares.
5. Crawling de landing pages e funil: seguir o destino do clique pelo criativo através de tracker, cloaker e prelander para identificar a oferta, a rede de afiliados, o software de tracking e o funil completo reverso-engenheirado.

O modelo mental

O mecanismo dominante de coleta para bases de spy tools de push, native, inpage e popunder é o mais simples estruturalmente: o operador da spy tool se torna um publisher.

Imagine uma casinha de três andares. Uma parede dá para uma rodovia movimentada. Outra parede dá parcialmente para uma rua transversal mais tranquila. O dono decide como fatiar essas paredes para anúncios: dez painéis colados em sequência na parede da rodovia (muita receita, casa feia, menos visitas de volta) ou um único banner discreto na parede lateral (menos receita, a casa continua sendo casa). Essa decisão de fatiamento (qual espaço é oferecido e como é dividido) é o que a indústria de ad-tech chama de inventário.

O dono oferece um layout específico de espaço disponível. Uma rede de anúncios fecha contratos dos dois lados: com o dono, para preencher os slots, e com marcas, para colocar anúncios neles. A rede cuida do casamento e fica com uma fatia.

Mapeando para ad-tech:

A parede é sua. Você vende. Você é pago por ela. Você vê exatamente qual outdoor é colado, e quando. Tudo que uma base de spy tool vende como “inteligência competitiva” segue desse único fato.

Mais dois termos usados abaixo, explicados uma vez e depois soltos: uma vertical é o nicho em que o anunciante opera (finanças, seguros, e-commerce); um DSP é a plataforma do lado do comprador que o anunciante usa para de fato comprar inventário em leilões em tempo real. Se nada disso é familiar, o IAB Tech Lab é a fonte canônica dos protocolos e a Wikipedia sobre real-time bidding cobre o básico em 10 minutos.

Os três passos

1. Cadastrar-se como publisher. Formulário padrão de onboarding em qualquer rede push/native. Entregue um domínio, aceite os termos, incorpore a tag JavaScript da rede ou configure um subdomínio CNAME para push.
2. Mandar visitantes para o inventário. Tráfego popunder/redirect barato, em torno de US$ 0,50 por mil, ou visitantes auto-gerados a partir de uma fazenda de proxy residencial ou móvel rodando browsers reais contra a página shell. Cada visitante dispara uma chamada de anúncio.
3. Capturar o bid response. A rede manda os metadados do criativo como JSON simples. O JS do publisher (código que o próprio operador escreveu) lê a resposta, posta no endpoint de coleta do operador e depois renderiza o anúncio normalmente, sem nada parecer estranho.

As escalas declaradas publicamente são realistas dado esse modelo: a Spy.House divulga ingestão de 12 milhões de criativos por dia em mais de 185 países, com AdPlexity e Anstrex publicando listas de cobertura sobrepostas em native, push e mobile. Uma operação com 30 redes, 50 shell sites e 95 GEOs atinge essa faixa sem dificuldade.

O que trafega na rede

O núcleo técnico é uma requisição HTTP e uma resposta HTTP por impressão, ambas totalmente visíveis para o publisher porque é o próprio JavaScript do publisher que faz a requisição.

Uma tag típica de publisher:

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

No carregamento da página, o SDK monta uma chamada de anúncio. Como curl, o que trafega pela rede se parece com:

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"

A rede roda a seleção dela (um leilão de real-time bidding entre DSPs nas exchanges maiores, com IAB OpenRTB como protocolo padrão, ou casamento direto de campanha nos especialistas em push/native) e devolve o criativo vencedor 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, corpo, URLs de imagem, destino do clique, ID da campanha, ID do anunciante, preço de bid e o contexto de targeting que disparou o match: a entrega inteira do anúncio em um objeto estruturado. O SDK do publisher então renderiza o anúncio.

A interceptação é mecânica. O publisher controla o JavaScript no nível da página, que roda antes do SDK; um wrapper de fetch ou um shim de XMLHttpRequest vê tudo:

// 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;
  };
})();

O SDK vê uma resposta idêntica e renderiza o anúncio normalmente. O collector recebe o registro completo. O visitante vê um anúncio funcionando. Nenhuma requisição é bloqueada, nenhuma resposta é alterada, nenhuma métrica de falha sobe em lugar nenhum.

Modelos de precificação e o que cada um vaza

Redes diferentes usam modelos diferentes de precificação, e o modelo determina quais campos do bid response carregam sinal útil. O vocabulário:

• CPM (cost per mille): anunciante paga por mil impressões. Padrão em push, popunder, na maior parte do native. PropellerAds, RichAds, Adsterra. Bid expresso em dólares por mil.
• CPC (cost per click): anunciante paga por clique. Comum em MGID, Taboola, Outbrain native. Bid por clique.
• CPA (cost per action): anunciante paga por conversão (cadastro, depósito, instalação). Usado por redes de afiliados (AdCombo, MaxBounty, ClickDealer), raramente diretamente pelas redes de anúncios. A conversão acontece server-side, no anunciante, então payouts de CPA não aparecem no bid response.
• CPI (cost per install): CPA mobile em que a ação é uma instalação atribuída por um MMP (AppsFlyer, Adjust, Branch).
• CPV (cost per view): vídeo, paga por view completo.

O modelo que vaza mais inteligência é o CPC. O valor do bid é um sinal em tempo real do que os anunciantes estão dispostos a pagar por clique naquele GEO e naquela vertical, atualizado a cada impressão. Três meses de histórico de CPC por anunciante por GEO viram um dataset de inteligência competitiva que nenhum anunciante consentiu compartilhar, e que se acumula como efeito colateral da visão normal do publisher sobre o bid response.

Concretamente, a API interna de consulta do operador da spy tool acaba expondo 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"

retornando uma série 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}
]

O frontend comercial da spy tool é uma caixa de busca em cima exatamente desse formato. O cliente vê dropdowns de filtro e gráficos de trajetória de bid; por baixo, a mesma consulta de série temporal contra a mesma tabela normalizada de bids, populada impressão por impressão a partir do bloco de interceptação JS acima.

CPM vaza menos por impressão, mas é útil em agregado. Um único bid CPM expressa disposição a pagar por mil impressões (frações de centavo cada) e isoladamente diz pouco sobre como o anunciante valoriza um clique ou uma conversão. É função de orçamento × correspondência de audiência × pressão de leilão por uma unidade de atenção, não uma leitura direta do modelo econômico do anunciante.

O que importa é a distribuição. Em milhares de impressões logadas para a mesma campanha, a série temporal de CPM revela o formato do orçamento (bids subindo = pressão para escalar, bids caindo = orçamento esgotado ou dayparting), níveis de preço por GEO (inventário em DE pode fechar em US$ 3 CPM enquanto VN fecha em US$ 0,30 para a mesma vertical, mostrando o preço real do mercado), prioridades de audiência (quais buckets de targeting atraem os bids mais altos) e o ciclo de vida da campanha. Nada disso é visível em uma única impressão; tudo emerge de algumas semanas de histórico acumulado.

CPA não aparece no bid response: o operador da spy tool não é o endpoint de conversão. Fechar essa lacuna exige seguir o destino do clique através de tracker, cloaker e offer wall, o que é um mecanismo totalmente diferente.

Por que o bid está no response, afinal? Pergunta legítima: a base de spy tool está lendo um número que a rede poderia em princípio simplesmente não mandar. Cinco motivos que se sobrepõem:

1. OpenRTB exige. O campo price é obrigatório no schema BidResponse.seatbid.bid. Redes que rodam em cima de OpenRTB herdam a transparência por design.
2. Verificação de revshare do publisher. Redes push e native pagam ao publisher entre 60% e 80% do bid do anunciante. Esconder o número → perder a confiança do publisher → perder inventário para um concorrente que mostra. Opacidade é desvantagem competitiva no lado da oferta.
3. Otimização de yield no lado do publisher. Publishers configuram floors de CPM por zona, fazem A/B test de placements, ajustam densidade de criativo. Tudo isso exige dados de bid por impressão. Um publisher que não vê a que preço o inventário fecha não consegue otimizar o que vende.
4. Renderização client-side. Push, native, popunder e inpage são todos renderizados pelo próprio JavaScript do publisher. O bid fica no mesmo payload que a URL do criativo e a URL de clique que a tag precisa para renderizar, e vaza a custo zero para a rede.
5. URL de clique frequentemente codifica o bid. Muitas redes embutem o valor do bid na URL de tracking do clique para reconciliação de billing entre impressão e clique. Mesmo que bid fosse removido do topo do JSON, ele viajaria nos parâmetros da URL de clique.

A exceção estrutural é o caso walled-garden detalhado abaixo: Google AdSense agrega ganhos do publisher por nível de categoria em vez de expor bids por impressão. Essa opacidade é uma das três defesas que fazem a publisher infiltration falhar contra os walled gardens, e uma escolha que as redes terceiras poderiam replicar mas não fazem, porque o valor da transparência para o publisher no onboarding e na retenção supera o custo de ser indexado pela cauda longa das spy tools.

OpenRTB e o bidstream

A maior parte das exchanges e muitas das redes maiores falam o protocolo IAB OpenRTB. Bid request e response seguem um schema JSON público (BidRequest, Imp, Seatbid, Bid) com campos documentados para domínio do anunciante (adomain), markup do criativo (adm), preço de bid (price), ID do criativo (crid) e taxonomia de categorias IAB (cat). Para um operador de spy tool, a rede compatível com OpenRTB é o alvo mais amigável: nomes de campo previsíveis, schema documentado, normalização entre redes trivial.

O pipeline prático: um parser por formato legado/proprietário, um parser compartilhado entre todas as redes OpenRTB, todo o output normalizado para um único schema interno. A UI de busca cross-network no frontend da spy tool é uma camada fina sobre essa tabela normalizada, e é por isso que toda spy tool relevante expõe basicamente o mesmo conjunto de filtros (GEO, dispositivo, OS, browser, tipo de anúncio, intervalo de datas, palavra-chave de anunciante).

O caminho mais fácil: o dashboard do publisher

Interceptação em nível de fio é o caso geral. O caso específico é ainda mais simples: o próprio dashboard de publisher da rede é uma UI de busca sobre os mesmos dados. Logado como publisher, o operador vê thumbnails de criativos, nomes ou IDs de anunciantes, destinos de clique, valores de bid nas impressões servidas, distribuição por horário e IDs de campanha. O dashboard existe para que publishers legítimos monitorem e façam brand safety; para um operador de spy tool é a interface de exportação mais conveniente possível.

Onde o dashboard é rico, o operador usa. Onde ele é fraco, ausente ou pouco documentado (especialmente em push, em que o payload criptografado do Web Push em trânsito é mais difícil de tratar sem controlar o service worker que decifra), a interceptação no fio preenche a lacuna. Multiplicado por 25–40 redes, a base resultante é estruturada, normalizada e razoavelmente atualizada em relação ao estado vivo de toda campanha push/native em execução no mundo.

O multiplicador GEO

Um publisher no Brasil vê criativos brasileiros. Para capturar criativos em 95 países, o operador precisa de:

1. Visitantes reais de cada GEO nos shell sites do publisher, para que a rede de anúncios sirva inventário geossegmentado naturalmente. Os operadores compram tráfego barato (popunder, redirect, push) de outras redes e roteiam pelos próprios shell sites para disparar chamadas de anúncio. A economia: uma impressão de redirect custa US$ 0,0005 e gera um criativo servido que vale indexar.

2. Visitantes sintéticos via proxies residenciais ou móveis, executando a página do publisher num browser real para carregar a tag de anúncio e capturar a resposta. Esse caminho é mais caro por impressão, mas produz cobertura limpa e segmentada por operadora que o tráfego de redirect barato não consegue. Os maiores marketplaces de spy tools fazem cross-sell com fornecedores de proxy móvel e residencial como categoria parceira primária exatamente por isso.

A dimensão de operadora móvel importa especificamente: redes de anúncios fazem targeting pelo ASN da operadora do IP requisitante. Proxies de datacenter genéricos aparecem como “Wi-Fi/desconhecido” e perdem totalmente as campanhas segmentadas por operadora. Proxies móveis em endpoints reais de operadora trazem à tona campanhas que só disparam para, digamos, assinantes Vivo BR ou Vodafone IT, exatamente o inventário que vale espionar, porque esse targeting indica uma campanha lucrativa e bem ajustada.

Por que as redes de anúncios toleram estruturalmente

O loop econômico é a resposta:

Anunciante paga Rede de Anúncios
        ↓
Rede de Anúncios serve criativo ao site "publisher" do operador da spy tool
        ↓
Rede de Anúncios paga receita de publisher ao operador da spy tool  ← incentivo da rede
        ↓
Operador da spy tool loga cada criativo e vende acesso a outros afiliados
        ↓
Outros afiliados sobem campanhas-cópia pela mesma Rede de Anúncios
        ↓
Rede de Anúncios fatura mais receita de anunciante (o loop fecha)

A rede é paga duas vezes pela mesma atividade. O gasto do anunciante original financia o payout de publisher para a spy tool. O gasto do anunciante copiador financia o próximo ciclo. Redes não têm incentivo para detectar ou banir esses publishers, e existe evidência observável desse alinhamento: a PropellerAds mantém um índice dedicado /blog/tag/spy-tools/ no blog corporativo, a RichAds publica uma listicle de top push spy tools, e a Adsterra publica seu próprio post recomendando as melhores ad spy tools. As três cobrem o mesmo conjunto de plataformas que indexa o inventário delas, muitas vezes com links de afiliado para essas ferramentas. As redes não são adversárias do ecossistema spy; são uma camada complementar.

Por que walled gardens são diferentes

O mecanismo acima funciona em PropellerAds, RichAds, MGID e nas outras 30 e poucas redes push/native de terceiros porque essas redes ficam entre anunciantes e um ecossistema aberto de publishers independentes. Qualquer um com domínio vira publisher; a rede não tem superfície first-party própria nem como entregar um anúncio sem um publisher para hospedar. O publisher é o canal de entrega outbound da rede. O operador da spy tool se torna um.

Google Search, Meta (Facebook e Instagram), TikTok e LinkedIn não funcionam assim. Os anúncios deles rodam nas próprias superfícies first-party (página de resultados do Google, feeds de Instagram e Facebook, For You do TikTok, timeline do LinkedIn), renderizados pelos próprios apps e servidores. O anunciante paga a eles; eles mostram o anúncio direto ao usuário na própria propriedade. Não existe inventário de publisher terceiro para se cadastrar, nenhuma tag JS que alguém possa incorporar para receber sponsored posts do Meta, nenhuma API para assinar anúncios do Google Search fora das superfícies do próprio Google. A superfície de entrega é a plataforma.

Onde os walled gardens têm redes de publishers terceiros (Google AdSense e a Google Display Network mais ampla, Meta Audience Network para in-app), três defesas estruturais impedem a publisher infiltration de funcionar.

1. Iframes cross-origin

Anúncios do AdSense carregam dentro de um iframe servido por googleads.g.doubleclick.net ou tpc.googlesyndication.com. O JavaScript do publisher roda na página pai; o anúncio roda no iframe; a same-origin policy do browser torna o conteúdo do iframe invisível ao código do 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.

O publisher aluga um retângulo vazio para o Google. Sem metadados de bid, sem URL de criativo, sem identidade de anunciante alcançável pelo código do publisher.

2. Seleção server-side sem bid response exposto

O Google decide qual anúncio mostrar na infraestrutura dele. O publisher recebe um anúncio renderizado dentro do iframe sandbox, não um bid response JSON com ID de anunciante, ID de campanha e metadados do criativo. O dashboard de publisher mostra receita agregada por categoria IAB, não histórico de bid por criativo, e mesmo essas categorias são deliberadamente grossas (“Finance > Insurance”, não “campanha Allianz sub-30 EU”). A visão que o publisher tem do que roda nele é deliberadamente de baixa resolução.

3. Enforcement agressivo no nível da conta

Google e Meta operam trust-and-safety dedicado no lado dos publishers, com detecção de fraude por ML e proibições explícitas nos Termos de Serviço contra fazer scraping, interceptação ou fingerprinting dos anúncios servidos na sua conta. Suspensão da conta e retenção de receita são a resposta padrão, aplicada em escala. A estrutura de incentivos é oposta à da PropellerAds: walled gardens perdem dinheiro com fraude do publisher em vez de ganharem mais com ela, então policiam.

O efeito combinado: as únicas formas programáticas de ver anúncios do Meta ou do Google em escala são as próprias ad libraries das plataformas e o scroll de feed via account farms na superfície voltada ao usuário. Interceptação no fio do lado do publisher, o truque universal nas redes terceiras, não sobrevive ao contato com a arquitetura de walled garden.

Detecção pelo lado do anunciante

Para um anunciante rodando uma campanha e querendo saber se está sendo indexado:

1. Injete fingerprints únicos nas URLs de clique. Um parâmetro de query que codifica um token aleatório por criativo, logado no servidor da landing. Se esse token aparece nos resultados de busca de uma spy tool, ou na sua própria análise de concorrência, o criativo foi indexado.

2. Audite o tráfego de clique procurando referrers de spy tools. Bases de spy tool fazem preview de landing pages fazendo fetch da infraestrutura delas. O User-Agent do fetch, faixas de IP (frequentemente sub-redes de cloud conhecidas na UE e nos EUA) e a ausência de execução de JS são detectáveis no servidor da landing.

3. Suba criativos isca com texto distintivo mas sem sentido, em valores de bid baixos. Procure por esse texto nas spy tools após 48 horas. As ferramentas que mostram têm; as que não mostram ainda não têm.

Movimentos defensivos

Legenda: ✓ cobertura total (a defesa bloqueia materialmente o mecanismo) · ◐ parcial (ajuda mas não bloqueia totalmente) · ○ sem efeito.

O alinhamento estrutural entre redes de anúncios e bases de spy tool (redes pagas duas vezes pela mesma atividade) significa que não existe forma de ser anunciante pagante em redes push ou native e não ser indexado. O criativo vai vazar. O que o anunciante controla são duas coisas: reduzir o valor do que vaza (para que a cópia não ajude o copiador) e tornar o vazamento comercialmente inútil (para que mesmo uma cópia perfeita não venda nada). As defesas abaixo vão do mais fundamental ao mais tático.

Três termos usados ao longo desta seção, ainda não introduzidos:

• Lander ou landing page: o site de destino para onde o clique leva. O criativo é o que aparece no feed do usuário; a lander é a página que carrega depois do clique.
• Funil: a cadeia completa, do criativo até a lander e dali até a ação que o anunciante de fato quer (cadastro, compra, instalação), passando por redirects de tracking.
• Cloaker: um filtro server-side no funil que mostra conteúdo diferente para tipos diferentes de visitante; compradores reais veem a oferta real, bots e crawlers veem um decoy genérico. O termo é mais associado ao marketing de afiliados em zona cinza, mas o mecanismo subjacente (distinguir um humano de um scraper) é prática padrão em prevenção de fraude legítima, personalização regional e defesa contra bots, que é o que Cloudflare Bot Management , DataDome e FingerprintJS Pro fazem para grandes marcas.

1. Distintividade de marca: a única defesa duradoura

Um criativo difícil de copiar de forma convincente vale mais do que um criativo difícil de encontrar. Se um concorrente pega seu criativo, troca o nome da marca e o resultado ainda parece plausível para o seu público, o vazamento move dinheiro. Se a troca lê como obviamente falsa, não move. Tipografia distintiva, paleta de cores, estrutura visual e voz pesam mais defensivamente do que qualquer contramedida técnica: a mesma lógica que protege campanhas icônicas de outdoor há um século.

O teste prático: pegue seu criativo, substitua sua marca pela de um concorrente e pergunte se ainda lê como anúncio crível para a marca dele. Se sim, o ativo é genérico e o vazamento é perigoso. Se “isso obviamente não é deles”, o vazamento é em grande parte inofensivo. Um concorrente rodando a mesma copy com o nome dele parece falsificação para quem já conhece você.

2. Separe o gancho da oferta

Um criativo distintivo é difícil de copiar de forma convincente. Um criativo carregado de oferta é fácil de decifrar. Mantenha as especificidades (nome do parceiro, preço, segmento alvo, CTA exato) fora da unidade em si e atrás do clique. Um anúncio que diz “Allianz baixa para €18/mês para menores de 30, contrate aqui” entrega ao concorrente parceiro, preço, segmento e funil em uma única captura de tela. O mesmo gancho na sua voz distintiva, com o spec protegido atrás da lander, entrega o ângulo mas não o playbook.

3. URLs de clique com token

Cada URL de clique carrega um token por clique, assinado server-side com expiração curta. De uma a quatro horas é o bastante. Sua lander valida o token; tokens expirados ou repetidos caem em uma página genérica em vez da oferta real. Um crawler de spy tool captura a URL uma vez, a URL morre antes de aparecer na base, e a manobra mais simples de análise competitiva (replay do clique capturado) para de funcionar.

O criativo carrega uma única URL estática apontando para o seu próprio redirector (https://track.you.com/c/<creative-id>). Essa é a URL que a rede indexa e armazena. Quando um clique real chega, o redirector emite um token fresco assinado e faz 302 do visitante para a lander com o token anexado. Use 302, não 301: 301 é cacheável, o que congelaria um token na URL para todo visitante seguinte; 302 força cada clique a passar de novo pelo seu servidor para receber um token novo.

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;
}

As principais plataformas de atribuição (AppsFlyer com OneLink + Protect360, Branch, Adjust, Google Campaign Manager 360) geram os próprios IDs por clique e rodam detecção de fraude server-side (replay de clique, spoofing, tráfego bot) dentro da infraestrutura delas, mas o veredito chega como flag pós-atribuição no seu dashboard, não como primitiva que a sua lander pode checar no momento da requisição. O padrão de token assinado acima fica em cima de qualquer plataforma que você use; é mirado especificamente no vetor de replay do crawler de spy tool, que as suítes antifraude de clique não foram construídas para tratar.

A janela de expiração é um trade-off. Curta demais (menos de uma hora) e usuários reais abrindo uma aba e voltando no dia seguinte caem na página decoy, prejudicando conversão. Longa demais (mais de um dia) e as bases de spy pegam URLs vivas mais rápido do que expiram. Quatro horas cobrem a vasta maioria da latência legítima de clique em tráfego mobile e passam dos windows de refresh da maioria das spy databases. Para campanhas sustentadas, rotacione a chave de assinatura semanalmente para que mesmo tokens capturados parem de validar contra a chave atual.

4. Personalização server-side na lander

A lander não é um HTML estático com detalhes da oferta cravados. É renderizada por visitante a partir do contexto da requisição: GEO, dispositivo, referrer, parâmetros de clique, hora. Dois visitantes acessando URLs aparentemente idênticas veem páginas materialmente diferentes. Um crawler de spy tool captura uma visão sintética; a visão capturada não representa o que os clientes reais veem, e a base de spy fragmenta sua campanha em snapshots dependentes de contexto em vez de registrar uma lander canônica para copiar.

Os inputs que conduzem a variação são primitivas de contexto de requisição que toda stack web já tem: GEO (do IP ou parâmetro de clique), ASN de operadora, classe do dispositivo, OS, browser, entropia do referrer, timestamp do clique e os IDs de campanha/criativo carregados na URL de clique. Cada input desloca qual variante de oferta, qual método de pagamento, qual bloco de copy e qual preço o visitante vê. Um crawler de spy tool de um ASN de datacenter em Frankfurt acessando uma URL pensada para Vodafone IT 5G no iOS vê uma variante de fallback que nada tem a ver com o targeting real da campanha.

A linha entre personalização e cloaking é intenção e disclosure. Personalização trata todo visitante legítimo como caso de primeira classe e mostra a oferta que ele foi de fato segmentado para receber; os únicos visitantes que veem conteúdo decoy são aqueles cujo contexto de requisição não bate com nenhuma audiência servida (bots, crawlers de spy, tráfego de revisão da própria rede de anúncios quando relevante). Cloaking no sentido estrito de afiliados engana deliberadamente os revisores de compliance da rede de anúncios. O mesmo mecanismo implementa os dois; a legitimidade vive no que é mostrado para o tráfego de revisão da rede versus um visitante não-segmentado.

A pegadinha de toda essa lógica condicional: você não consegue verificar do escritório. Carregar sua própria lander de um IP de datacenter, VPN de consumidor ou laptop no Wi-Fi de casa todos batem no ramo de fallback por design, exatamente o que as regras de personalização bloqueiam. O único teste de verdade-no-terreno é carregar a lander pelo contexto de requisição que você realmente segmenta: mesmo ASN de operadora, mesmo GEO, mesma classe de dispositivo. A iProxy.online transforma um celular Android e um chip local num proxy móvel dedicado no IP real da operadora, então você consegue carregar a lander como um visitante Vodafone IT 5G real carregaria e confirmar que a variante servida bate com o targeting antes de escalar gasto. A mesma frota dobra como auditoria de defesa contra spy: faça replay da URL capturada numa base de spy a partir do mesmo IP de operadora e confira se sua lógica de decoy de fato dispara para o contexto em que o crawler estava.

5. Detecção de bots na borda do funil

Esta é a aplicação legítima e defensável de técnicas tipo cloaking. Camadas padrão de mitigação de bots na borda da lander identificam visitantes automatizados e desviam eles do conteúdo real da oferta. A mesma maquinaria que os grandes e-commerces rodam contra credential stuffing e bots de hoarding de estoque vale aqui: o crawler de spy tool é um bot; detecção de bots mantém a página de oferta fora do alcance dele. A lander capturada vira um decoy genérico e o valor da base de spy para um concorrente copiador degrada.

O que os principais produtos de mitigação de bots pegam, na prática: Cloudflare Bot Management pontua cada requisição numa combinação de fingerprint TLS, ordem de frames HTTP/2, reputação de IP, histórico comportamental e um challenge de confiança; DataDome empilha sinais similares com foco em comportamento application-side (movimento de mouse, cadência de scroll, timing de campo de formulário); FingerprintJS Pro enfatiza fingerprints duráveis de browser que sobrevivem à limpeza de cookies e ao uso de aba anônima. Um crawler headless de spy tool rodando de um IP de datacenter limpo falha nos três nos sinais básicos; um crawler sofisticado rodando um Chromium real por trás de um proxy residencial passa em um ou dois, mas raramente na pilha completa.

Onde essa defesa gera mais ruído é em torno do tráfego de operadora móvel. IPs de proxy móvel de ASNs reais de operadora roteiam por CGNAT e parecem comportamentalmente idênticos a visitantes móveis legítimos: mesmo pool NAT, mesmo perfil TLS, mesmos fingerprints de dispositivo. Uma regra grosseira de “bloquear todo tráfego residencial ou de proxy móvel” vai prejudicar a conversão de usuários móveis reais mais do que vai atrapalhar um operador de spy competente. Calibre o threshold de detecção contra o impacto na conversão: falsos positivos no mobile custam dinheiro real, então prefira sinais comportamentais (padrões de interação, tempo na página, engajamento em formulário) em vez de bloqueios por classe de IP no segmento mobile.

O padrão que mais vemos: uma equipe calibra regras de detecção de bots contra o formato do tráfego de uma operadora e depois confia demais na regra para outra operadora no mesmo GEO. Os sinais que de fato separam operadoras e classes de dispositivo ficam abaixo das camadas que um navegador antidetecção ou um cloud phone consegue repintar: o MTU do SIM difere entre operadoras, os fingerprints da stack TCP diferem entre classes de dispositivo, e os dois são primitivas em nível de kernel que uma ferramenta de userspace não consegue forjar. Um threshold calibrado em iPhones na Vodafone IT pode marcar visitantes Android legítimos da TIM IT uma semana depois. Teste pelo menos duas combinações operadora × dispositivo por mercado alvo antes de fechar o threshold.

Calibrar esse threshold com honestidade exige testar a partir do próprio contexto de requisição. Um proxy móvel da iProxy.online entrega um ASN real de operadora com roteamento CGNAT e perfil TLS de dispositivo genuíno; combinado com um navegador antidetecção, deixa você carregar sua própria lander tanto como visitante mobile legítimo quanto como crawler mais sofisticado tentando imitar um. Suba as regras até elas pegarem o setup antidetect e depois desça até pararem de punir o baseline mobile puro. O gap entre esses dois thresholds é a sua janela operacional.

6. Dynamic Creative Optimization (DCO)

Recurso padrão da indústria no Meta, no Google e na maioria das DSPs programáticas: variação automatizada de componentes do criativo (headline, imagem, CTA, cor, copy) na hora da impressão. Quando cada criativo servido é uma combinação ligeiramente diferente, a base de spy não vê um “vencedor” claro para copiar. Vê variantes fragmentadas que não se agrupam, então concorrentes rodando campanhas-cópia testam contra premissas erradas e queimam orçamento. DCO é movimento defensivo a custo incremental zero, já que as plataformas suportam nativamente.

Os eixos de variação que mais importam para fragmentação defensiva: headline (3–10 variantes), imagem principal (3–8 variantes), texto do botão CTA (3–5 variantes) e cor de destaque (2–4 variantes). Combinatorialmente, quatro eixos com cinco variantes cada produzem 625 combinações servidas. Uma base de spy raspando 200 dessas impressões vê o que parece serem 200 criativos distintos; nenhuma combinação domina o dado, nenhum “melhor” claro emerge, e um concorrente rodando a campanha-cópia contra o conjunto capturado testa toda variante por igual e aprende nada sobre qual converte.

DCO é mais difícil de escapar em redes terceiras de push e native do que em walled gardens. Meta Advantage+ Creative e Google Performance Max fazem variação por componente automaticamente; PropellerAds e similares aceitam várias variantes de criativo dentro de uma campanha mas geralmente não fragmentam componentes dentro de um criativo único. O workaround em push: suba 20–30 micro-variantes do criativo como unidades separadas dentro da campanha, garantindo que nenhum criativo único domine as impressões. Operacionalmente mais pesado que o equivalente em walled garden, mas atinge a mesma fragmentação defensiva.

7. Watermarking pixel-level

Marcadores esteganográficos embutidos em imagens, vídeos e copy do criativo: imperceptíveis ao espectador, recuperáveis de uma cópia capturada. Toolchains open source como o watermark-anything do Meta demonstram payloads de imagem em qualidade de produção que sobrevivem a recompressão JPEG, redimensionamento e ao caminho de screenshot-recomprime que um crawler de spy tipicamente usa para ingerir criativos. O mesmo princípio se estende a texto via substituição de espaços em branco Unicode. Um paper recente cataloga a abordagem para headlines e linhas de copy, em que variantes invisíveis de caracteres codificam um ID por impressão sem alterar o texto renderizado. Nenhum dos dois impede a indexação. Os dois identificam quais bases de spy capturaram quais criativos e quando, o que é inteligência útil sobre a pesquisa competitiva: quem está estudando suas campanhas, em qual cadência e por quais caminhos de coleta.

8. Velocidade vence ocultação

Bases de spy ficam atrasadas: 24 a 72 horas para as mais rápidas, às vezes uma semana para a cauda longa. Uma equipe que sobe uma nova variante de criativo a cada 48 horas fica consistentemente à frente de concorrentes copiando a anterior. Para campanhas de teste essa é defesa completa; para presença de marca sustentada é parcial, e a distintividade de marca em #1 carrega o resto do peso.

9. Espelhe o que as bases de spy veem

A defesa que os anunciantes consistentemente pulam é auditar suas próprias campanhas a partir do mesmo vantage point que uma base de spy usa. Se o único lugar onde você vê seu próprio criativo é no dashboard de reporting da rede, você não tem ideia de como ele aparece para o tipo de tráfego que os operadores de spy de fato capturam: visitantes sintéticos vindos de IPs residenciais e de operadora móvel em cada GEO alvo. Redes fazem a entrega baseada em ASN de operadora; um criativo que serve liso para o IP do escritório no Wi-Fi pode nunca chegar a um assinante Vodafone IT 5G que a rede está de fato segmentando. Você está voando às cegas em relação ao que seus concorrentes podem comprar acesso.

A auditoria é mecânica: suba um browser real através de um proxy de operadora móvel em cada GEO alvo, carregue uma página de publisher rodando a rede de anúncios relevante e capture o criativo servido e o bid response numa janela de amostra. O resultado é a visão do operador de spy sobre a sua campanha: quais criativos aparecem, em quais níveis de bid, contra quais parâmetros de targeting. Se seu criativo “Vodafone IT 5G sub-30” não aparece na auditoria por bucket de operadora, a rede não está entregando do jeito que você quis, e a mesma lacuna de entrega é invisível para os seus relatórios. Se aparece, você sabe exatamente qual recorte da sua campanha está downstream de qualquer base de spy. Rode o browser de auditoria por um perfil antidetect vinculado ao proxy móvel para que a visão capturada bata com o que um visitante real naquele contexto veria.

10. Diversifique a superfície de buckets de operadora das suas campanhas

Uma campanha mirando “DE mobile” roda como bucket único e amplo. Uma campanha segmentada em “DE / Vodafone DE 5G sub-30”, “DE / Telekom DE 4G todas as idades”, “DE / O2 DE 5G urbano”, e assim por diante, roda como uma dúzia de buckets estreitos. O volume total de impressão é o mesmo; a pegada na base de spy não é.

Operadores de spy consultam a base normalizada por GEO, dispositivo, OS, browser e campos de contexto de targeting da rede. Uma campanha bucket-amplo agrupa numa fatia contígua única da base de spy: consulte “DE mobile [vertical]” e a campanha toda aparece numa única visão. Uma campanha bucket-estreito fragmenta entre consultas: nenhum comprador de inteligência competitiva combina naturalmente uma dúzia de filtros específicos de operadora, idade e dispositivo para reconstruir a campanha completa, e os criativos capturados se espalham por células que parecem campanhas pequenas separadas, em vez de uma grande. O mesmo gasto total, o mesmo alcance total, um sinal fundamentalmente diferente em qualquer base de spy.

Isso funciona porque redes de anúncios fazem entrega pelo ASN de operadora como campo de targeting de primeira classe. A mesma propriedade que viabiliza as auditorias por proxy móvel em #9 dá significado à diversificação por bucket de operadora aqui. Proxies de datacenter ou residenciais genéricos que mascaram o ASN de operadora não conseguem entregar essa defesa; o pool de visitantes do operador de spy já é segmentado por operadora, então uma campanha que opera em buckets estreitos de operadora segue fragmentada na base de spy mesmo depois da captura.

Pensamento final: o outdoor sempre foi copiado

Publicidade em outdoor vem sendo copiada há um século, e a Coca-Cola não mantém uma war room para impedir. Ela tem algo mais poderoso: uma identidade criativa tão distintiva que a cópia é visivelmente uma cópia. Defesas técnicas compram dias; distintividade de marca compra décadas.

A casa na rodovia nunca vai impedir que olhem para a parede. O dono escolhe o que é pintado nela, e uma pintura reconhecível em qualquer lugar não perde valor no dia em que alguém tira uma foto.