Em algum momento dos últimos anos seus dashboards pioraram — e você não fez nada para merecer isso. Mesmas campanhas, mesmo pixel, mesmo checkout, mas as conversões reportadas caíram, os públicos de remarketing encolheram e o custo por compra da plataforma parou de bater com os pedidos que você contava na mão. Você não quebrou nada. Foi a camada de medição embaixo dos seus anúncios que quebrou.

Este post explica o que quebrou — App Tracking Transparency, o Intelligent Tracking Prevention do Safari, a morte lenta do cookie de terceiros —, o que as plataformas perderam de vista, por que chegaram as conversões modeladas e por que a saída durável é rastrear no seu próprio domínio e servidor.

A Engrenagem Que Fazia o Trabalho

A medição de anúncios rodava sobre duas peças de encanamento compartilhado.

A primeira era o cookie de terceiros. O pixel da plataforma rodava em milhões de sites, e todos liam e escreviam o mesmo cookie do domínio da plataforma. Aquele identificador único costurava a navegação de uma pessoa pela internet inteira: a plataforma via a impressão, o clique, a página de produto e a compra, tudo ligado a um único perfil.

A segunda era o ID de dispositivo móvel (o IDFA da Apple, o advertising ID do Google). Dentro de apps, onde cookie não existe, ele fazia o mesmo papel: um identificador estável, disponível por padrão, ligando o toque num anúncio dentro de um app à compra feita em outro.

Os dois funcionavam entre propriedades de empresas diferentes, sem esforço do anunciante. Essa propriedade é exatamente o que removeram.

O Que o ATT Mudou de Verdade

Com o iOS 14.5, a Apple lançou o App Tracking Transparency. Costumam descrevê-lo como "a Apple matou o rastreamento"; o que ele fez foi algo mais estreito e mais consequente: colocou o IDFA atrás de um pedido de permissão explícito, app por app — o famoso "Pedir para o App Não Rastrear" — e tornou a recusa o padrão na prática, porque a maioria, perguntada com clareza, diz não.

Três detalhes importam:

O ATT governa apps, não a web. Ele travou o ID de dispositivo e o compartilhamento de dados entre apps. O lado web do colapso veio da política dos navegadores (próxima seção).
O identificador não degradou — sumiu. Para quem recusa, não há versão aproximada do IDFA: a ligação entre o toque num anúncio do Instagram e uma compra em outro lugar deixa de existir.
O que a Apple ofereceu no lugar é agregado. O reporte estilo SKAdNetwork devolve contagens atrasadas, com thresholds, no nível da campanha — útil para leitura direcional, inútil para ligar uma conversão específica a um clique específico.

Para plataformas cuja entrega era calibrada por feedback de conversão por usuário, foi uma perda estrutural, não um incômodo de relatório.

A história na web é o Intelligent Tracking Prevention do Safari. O ITP bloqueia cookies de terceiros por completo — o identificador cross-site descrito acima não existe mais no Safari, e o Firefox aplica bloqueio parecido. O Chrome passou anos sinalizando restrições próprias enquanto lançava APIs substitutas.

As plataformas se adaptaram com a decoração de link: anexar um ID de clique à URL de destino (gclid, fbclid, ttclid), fazer o pixel guardá-lo num cookie first-party via JavaScript e lê-lo de volta na conversão. O ITP respondeu na lata: o Safari limita a vida dos cookies escritos por JavaScript a 7 dias, e a apenas 24 horas quando a visita chega decorada com parâmetros de rastreamento vindos de um domínio rastreador conhecido.

Na prática — conta ilustrativa, não estudo: um cliente no iPhone clica no seu anúncio na terça e compra no sábado. O cookie com o ID do clique expirou dias atrás. Para a plataforma, o comprador de sábado é um desconhecido. A conversão aconteceu; a atribuição dela, não.

O Que as Plataformas Pararam de Ver

Sinal	Antes	Depois de ATT + ITP
ID de dispositivo (IDFA) em apps	Disponível por padrão	Pedido de opt-in; recusado na maioria
Cookie de terceiros	Um perfil pela web inteira	Bloqueado no Safari e no Firefox; restrito nos demais
Cookie first-party escrito via JS	Durava meses	Limitado a 7 dias / 24 horas no Safari
ID de clique na hora da conversão	Lido de um cookie durável	Some, a menos que você mesmo o capture e guarde
Contagem de conversões	Eventos observados	Observados mais estimativas modeladas

Os sintomas na ponta são os que você sentiu: públicos de remarketing menores, frequency caps que pararam de funcionar entre sites e contagens subnotificando o tráfego de iOS e Safari.

Conversões Modeladas: Tapando o Buraco com Matemática

As plataformas não deixaram os buracos vazios. Onde a ligação determinística quebrou, Google, Meta e TikTok introduziram a modelagem de conversões: estimativas estatísticas de quantas conversões provavelmente aconteceram no segmento não observável, baseadas no comportamento dos usuários que elas ainda enxergam.

Sendo justo: na escala das plataformas, modelar é uma resposta de engenharia razoável, e um número modelado costuma ficar mais perto da realidade do que uma subcontagem crua. Mas isso muda o que o seu dashboard é. Parte da coluna "Compras" deixou de ser uma contagem de eventos — virou uma inferência. Você não consegue ligar uma conversão modelada a um número de pedido, auditá-la contra a sua loja, nem saber quais campanhas absorveram mais chute. E quem produz a estimativa é a mesma entidade que te vende os anúncios.

Por Que o Rastreamento First-Party Sobrevive

Todos os mecanismos quebrados acima têm algo em comum: dependiam de um terceiro identificar o seu visitante em sites alheios. Esse comportamento é o que navegadores e sistemas operacionais decidiram encerrar — e não vão voltar atrás.

O que nenhuma dessas políticas restringe é a sua relação com o seu próprio visitante no seu próprio domínio. Uma arquitetura first-party inverte o desenho:

O script de rastreamento é servido do seu domínio e envia eventos para o seu endpoint — o seu site observando o seu tráfego, não um rastreador observando a web.
IDs de clique e UTMs são capturados na chegada e guardados no servidor, no seu banco de dados. Uma linha no Postgres não expira em 24 horas porque o Safari mandou.
A verdade da conversão vem de eventos server-side — um webhook do checkout da Shopify ou do Stripe com o pedido real e o valor real —, não de um script no navegador.
A junção entre clique e pedido acontece no seu servidor, sob regras que você pode inspecionar. É essa a arquitetura sobre a qual o Decisa foi construído: captura de cliques no próprio domínio, pedidos via webhook e uma atribuição auditável pedido a pedido.

O resultado é uma medição que não se importa com o que a próxima versão do iOS vai mudar, porque nada na cadeia depende de identidade cross-site.

O Que Fazer Esta Semana

Capture IDs de clique em first-party. Guarde gclid, fbclid, ttclid e UTMs na chegada, no servidor — não só num cookie.
Leve a verdade da conversão para o servidor. Webhooks do seu checkout, e não eventos de navegador, definem o que é um pedido.
Devolva as conversões verificadas via Conversions API da Meta e conversões otimizadas do Google, para que os algoritmos de lance aprendam com pedidos reais em vez de modelados.
Reposicione suas decisões. Use os números da plataforma para otimizar dentro dela; decida orçamento e escala com os seus próprios dados cruzados.

O rastreamento não quebrou porque você configurou um pixel errado. Quebrou porque uma arquitetura inteira — identificar pessoas nas propriedades de outras empresas — foi aposentada. O substituto não é um pixel melhor. É ser dono do caminho do dado.