Blog

Por que o ITP do Safari Faz Suas Conversões Sumirem (e o Que Fazer)

Publicado 2026-07-16

safari itp conversões caindointelligent tracking preventionitp cookie 7 diassafari não rastreia conversões

"Por algum motivo, os números só não fecham para os usuários de iPhone." Essa é uma reclamação de queima lenta, mas cada vez mais comum, nas áreas de operação de anúncios e otimização de sites. O rastreamento funciona corretamente no Chrome, mas o tráfego via Safari (iPhone, iPad, Mac) volta raquítico. Você não se lembra de ter mudado nada — mas os números simplesmente não batem. Na maioria das vezes, a causa são as restrições de cookies impostas pelo ITP (Intelligent Tracking Prevention), embutido no Safari por padrão.

Algum desses cenários soa familiar?

Bastante tráfego vindo de iPhone e Mac, mas só as conversões do Safari estão baixas
No GA4, a taxa de novos usuários no Safari está anormalmente alta (a mesma pessoa parece ser contada como nova repetidamente)
Uma conversão de um clique em anúncio de alguns dias atrás não é atribuída, mesmo estando dentro da janela de atribuição
Usuários que deveriam ser tratados como visitantes recorrentes aparecem como visitantes de primeira vez toda vez
IDs de clique de anúncios (gclid, fbclid) param de funcionar depois de alguns dias

Este guia explica como o ITP do Safari faz conversões caírem ou sumirem, por que a identificação de visitantes recorrentes e a atribuição quebram, o que você pode fazer a respeito, e como verificar — no seu ambiente real de produção — exatamente como os cookies estão sendo tratados agora.

Princípio básico: o ITP não é um "defeito", é um recurso de privacidade

O maior motivo pelo qual isso dá errado é assumir que números menores no Safari significam uma "tag quebrada" ou um "erro de configuração". Na realidade, esse é o resultado de uma proteção de privacidade deliberadamente construída no Safari (mais precisamente, no seu motor de navegador, o WebKit). Não é algo que você pode "consertar" — é uma especificação que você precisa considerar como um dado da realidade desde o início.

Veja o que o ITP realmente faz:

O que o ITP faz	Comportamento concreto
Limita o tempo de vida de cookies first-party	Cookies first-party definidos via JavaScript (`document.cookie`) são apagados depois de no máximo 7 dias. Após uma navegação cross-site (link decoration — um redirecionamento com parâmetros de query), pode encolher para 24 horas
Bloqueia cookies third-party	Cookies definidos por outros domínios são bloqueados por padrão, cortando o rastreamento cross-site
Suprime a medição cross-site	Restringe progressivamente a identificação de um usuário entre sites

O ponto principal: quanto mais um cookie é definido via JavaScript, mais curto seu tempo de vida é tratado. A maioria das tags de medição define cookies exatamente por esse caminho JavaScript — é por isso que a base da sua medição colide de frente com o ITP do Safari.

Por que "some em 7 dias" derruba suas conversões

A regra do ITP que mais importa na prática é o limite do tempo de vida de cookies first-party em no máximo 7 dias. Veja por que isso reduz seus números, dividido em quatro efeitos.

1. A identificação de visitantes recorrentes quebra

As tags de medição armazenam um identificador em um cookie (como o _ga do GA4) para reconhecer um usuário. Quando esse identificador é apagado depois de 7 dias, a mesma pessoa retornando no dia 8 é recontada como um "novo usuário diferente". O resultado: menos visitantes recorrentes, e novos usuários inflados além da realidade.

Armadilha comum: "a taxa de novos usuários no Safari está estranhamente alta" — muitas vezes isso não é aquisição indo bem. É um sinal de que o _ga está sendo resetado e a mesma pessoa está sendo contada como nova repetidamente.

2. A janela de atribuição efetivamente encolhe

Mesmo que você tenha configurado "contar conversões dentro de 14 dias de um clique em anúncio", se o cookie usado para essa avaliação some em 7 dias (às vezes 24 horas), a segunda metade da janela simplesmente não pode ser atribuída. Não importa quão longa seja a sua janela de atribuição configurada, no Safari você só consegue capturar resultados dentro de uma janela substancialmente mais curta.

3. O armazenamento de `gclid` / `fbclid` expira

Usuários que chegam de anúncios carregam um ID de clique indicando de qual anúncio vieram (o gclid do Google, o fbclid do Meta). Muitas implementações armazenam isso em um cookie first-party via JavaScript e o leem de volta quando o usuário converte mais tarde. Mas se esse cookie some em 7 dias, uma conversão posterior não pode ser vinculada de volta ao clique no anúncio. Você acaba com "houve um clique, mas o resultado não é creditado".

4. Novos usuários são inflados

Conforme os efeitos 1 a 3 se acumulam, no Safari a mesma pessoa é contada como nova repetidamente, inflando a contagem de usuários e a taxa de novos usuários além da realidade. Como o denominador aumenta, você também tem uma distorção secundária: a taxa de conversão (CVR) parece mais baixa do que realmente é.

Não é só o Safari: todos os navegadores do iOS são afetados

Um detalhe que muitas equipes ignoram: no iOS (iPhone e iPad), todo navegador — Chrome, Firefox, Edge e outros — usa o motor WebKit da Apple por baixo dos panos. A política da App Store da Apple exige isso. Isso significa que as restrições de cookies do ITP se aplicam a todos eles, não só ao aplicativo Safari.

Na prática, isso significa que:

Um usuário abrindo seu site no "Chrome no iPhone" ainda está sujeito ao mesmo limite de 7 dias de cookies e ao bloqueio de cookies third-party que o Safari
Seus relatórios de tráfego específicos do Safari subestimam o verdadeiro alcance do impacto do ITP — as perdas se estendem a todo o tráfego de navegadores iOS
A parcela de usuários afetados é muito maior do que a participação de mercado isolada do Safari sugere

Ao estimar o impacto, olhe para o tráfego total do iOS, não só para as sessões do Safari.

O bloqueio de cookies third-party também está em ação

Além do limite de tempo de vida, o ITP bloqueia por padrão cookies third-party definidos por outros domínios. Historicamente, o retargeting de anúncios e a medição cross-domain dependiam desses cookies third-party.

Como o Safari não permite isso:

Usuários não podem ser identificados entre sites, então sua audiência de retargeting encolhe
Vincular uma compra concluída em múltiplos domínios (por exemplo, seu site principal e um domínio de pagamento) quebra com mais facilidade
Quanto mais sua medição depende de tags de domínios externos, maior a perda no Safari

Em resumo, o Safari aplica uma restrição dupla — "cookies first-party de curta duração" mais "cookies third-party negados por padrão" — então, se você roda a mesma implementação do Chrome, não é surpresa que os números não batam.

Por que as conversões caem mesmo com a tag "disparando"

A tag está rodando (disparando), mas os números do relatório caem. Esse é o padrão mais confuso com o ITP. O motivo: disparar (uma requisição é enviada) e ser medido (identificação contínua, baseada em cookies) se desacoplam.

No Safari, mesmo quando a tag dispara corretamente e as requisições saem:

Cookies somem em 7 dias, então a mesma pessoa não pode ser identificada continuamente (recorrências se disfarçam de novas)
Quando o armazenamento do click ID expira, você perde qual anúncio gerou o resultado
Cookies third-party não estão disponíveis, então a costura cross-site e cross-domain quebra

Então, mesmo que você confirme que "a requisição está disparando na Network", se o cookie por trás dela estiver sendo encurtado ou expirando, ela não é registrada como uma conversão contínua e utilizável para anúncios. Verificar apenas se a tag dispara nunca vai revelar um problema de ITP.

O custo escondido: os algoritmos de anúncios degradam quando os sinais somem

O impacto do ITP vai além de relatórios imprecisos — ele degrada ativamente o desempenho das suas campanhas de anúncios. Plataformas de anúncios como Google Ads e Meta Ads dependem de sinais de conversão para treinar seus modelos de machine learning. Quando as conversões do Safari (e do iOS) não são reportadas:

O Lance Inteligente e a otimização de campanhas recebem dados incompletos. O algoritmo vê menos conversões do que realmente ocorreram, então subvaloriza audiências e posicionamentos que de fato convertem — especialmente os inclinados para dispositivos Apple.
Campanhas podem entrar em status de "aprendizado limitado". Quando as conversões reportadas de uma campanha caem abaixo do limite da plataforma (frequentemente em torno de 50 por semana), o algoritmo não consegue sair da fase de aprendizado, levando a uma entrega instável e custos mais altos.
Audiências semelhantes (lookalike) perdem precisão. Com um pool de conversões enviesado que subrepresenta usuários iOS, a plataforma constrói modelos de audiência inclinados para demografias não-Apple, potencialmente perdendo seus clientes de maior valor.

Isso cria um ciclo vicioso: menos conversões reportadas levam a uma otimização pior, o que leva a genuinamente menos conversões, o que produz ainda menos sinal para o algoritmo. Quebrar esse ciclo exige alimentar os dados de conversão de volta para a plataforma através de um caminho que contorne as limitações de cookies do lado do navegador — é aí que entram o server-side tagging e as Conversions APIs.

O que você pode fazer: mitigações para o ITP

Você não pode "desligar" o ITP, mas pode suavizar seu impacto mudando como os cookies são definidos. A direção é: "substituir cookies definidos via JavaScript por um método de vida mais longa".

1. Defina cookies first-party a partir do servidor (cookies HTTP)

Um cookie first-party definido pelo servidor via cabeçalho de resposta HTTP (Set-Cookie) — em vez de via JavaScript (document.cookie) — tem muito menos probabilidade de estar sujeito ao limite de 7 dias do ITP. Mover o armazenamento do identificador para o lado do servidor é a mitigação mais fundamental.

2. Use server-side tagging (server-side GTM)

Isso move o processamento de tags para fora do navegador e por meio de um servidor que você controla. Como os cookies podem ser tratados no lado do servidor (no seu próprio domínio), eles ficam menos expostos a limites de tempo de vida e bloqueios. A implementação é mais pesada, mas é uma medida de alto impacto contra as perdas no Safari.

3. Envie diretamente do servidor com uma Conversions API (CAPI)

Em vez de passar pelo navegador, isso envia conversões do seu servidor diretamente para a plataforma de anúncios (como a CAPI do Meta). Como depende menos da situação de cookies do navegador, isso pode recuperar perdas no Safari. Combinar uma CAPI com conversões avançadas fortalece a taxa de correspondência ao enviar dados first-party com hash junto com o evento de conversão.

Armadilha comum: mesmo quando você acha que migrou para server-side, não é incomum que o cookie real ainda esteja sendo definido via JavaScript (e não com um cabeçalho Set-Cookie). "Ter implementado" e "o cookie estar realmente sendo emitido como um cookie HTTP" são duas coisas diferentes. Você precisa confirmar, nos cabeçalhos de resposta em produção, que o cookie realmente é emitido pelo servidor.

Atenção: a regra de correspondência de IP pode anular seu ajuste server-side

Desde o Safari 16.4, o WebKit aplica uma verificação adicional: se o prefixo do endereço IP do servidor que emite o cabeçalho Set-Cookie não corresponder ao prefixo do endereço IP do servidor de origem do site, o cookie é limitado a 7 dias — mesmo tendo sido definido no lado do servidor.

Isso pega um padrão de implantação comum: seu site roda em um provedor de hospedagem enquanto seu contêiner de server-side GTM roda em uma nuvem diferente (Google Cloud, um serviço sGTM gerenciado, etc.). Como os IPs estão em faixas diferentes, o Safari silenciosamente sobrescreve a expiração do seu cookie de volta para 7 dias, e sua mitigação silenciosamente para de funcionar.

O que verificar:

Confirme que seu endpoint sGTM e seu site resolvem para endereços IP na mesma faixa de prefixo
Se você usa um subdomínio CNAME (por exemplo, data.seusite.com) apontando para um servidor de rastreamento de terceiros, a detecção de CNAME cloaking do WebKit também pode limitar o cookie
Depois de implantar, verifique a expiração real do cookie em um navegador Safari de produção — o cabeçalho Set-Cookie sozinho não garante que o navegador respeitou a expiração que você definiu

O que uma checagem na sua própria máquina não consegue lhe dizer

Depois de mitigar o ITP, naturalmente você vai querer confirmar "está funcionando?". Mas testar uma vez na sua própria máquina tem dois pontos cegos específicos do ITP:

Seu ambiente não é o mesmo de um usuário real do Safari. Um navegador de desenvolvimento difere de um visitante típico em extensões, cache e estado de login. O ITP em particular se comporta de forma diferente dependendo de "houve uma navegação cross-site?" e "esse navegador já teve contato com o domínio antes?" — então, em um ambiente não limpo de desenvolvedor, a expiração de 7 dias ou o encurtamento de 24 horas que atinge usuários reais pode não se reproduzir. Você acaba com o descompasso de "funcionou no meu Safari" enquanto quebra para um visitante geral de primeira visita.
Qualquer coisa envolvendo um clique em anúncio é difícil de reproduzir. Para ver corretamente "como o Safari trata alguém que chegou com um gclid de um clique em anúncio e converteu alguns dias depois", você precisaria clicar em um anúncio ao vivo para recriar o caminho e a passagem do tempo — o que carrega o risco de uma violação de política de anúncios como um autoclique.

Problemas de ITP acontecem no caminho do "usuário do Safari de produção em sua primeira visita", não no "seu ambiente já mitigado". O fato de que a costura funciona quando você testa é exatamente o que gera complacência.

Como verificar "como os cookies estão sendo tratados agora" em produção

Método 1: Verifique o método de emissão e a expiração do cookie no DevTools

A checagem mais básica. Tanto no Safari quanto no Chrome, o DevTools em "Application (ou Storage)" → "Cookies" mostra a expiração (Expires / Max-Age) de cada cookie.

A expiração do seu cookie de medição (como o _ga) está sendo truncada para dentro de 7 dias?
Esse cookie é definido via JavaScript ou pelo servidor (HttpOnly)?

O que isso te diz: se, agora em produção, seu cookie identificador está sendo encurtado pelo ITP, e se foi substituído por um emitido pelo servidor.

Método 2: Verifique `Set-Cookie` nos cabeçalhos de resposta

Na aba Network, abra os cabeçalhos de resposta da página e veja se o cookie é emitido via um cabeçalho Set-Cookie. Se seu cookie identificador aparece aqui, isso é evidência de que está sendo emitido no lado do servidor (como um cookie HTTP). Se for definido apenas via JavaScript, não vai aparecer aqui.

O que isso te diz: se sua mitigação de ITP (emissão server-side) está realmente funcionando, não só sendo alegada.

Método 3: Verifique no Safari, incluindo a passagem do tempo

A essência do ITP é que "cookies somem conforme o tempo passa". Então você precisa verificar não só logo após a emissão, mas se o mesmo identificador de usuário é preservado alguns dias depois. Em particular, no Safari, confirme que a expiração do cookie não encolheu para 24 horas depois de uma navegação cross-site via link decoration (com parâmetros de query).

O que isso te diz: se, sob condições parecidas com produção de uma primeira visita e uma navegação cross-site, o identificador está batendo no muro de 7 dias / 24 horas.

Uma checklist para verificar com confiança

Você verificou a expiração do seu cookie de medição (como o _ga) no Safari de produção?
Esse cookie é definido pelo servidor (Set-Cookie) ou via JavaScript?
Depois de uma navegação cross-site (link decoration), a expiração não encolheu para 24 horas?
O armazenamento de gclid / fbclid ainda é válido alguns dias depois (não expirou)?
A taxa de novos usuários via Safari não está anormalmente alta (suspeite de recorrências sendo recontadas como novas)?
O server-side tagging / CAPI está de fato emitindo e enviando — não só "implementado"?
Você verificou sob condições reais do Safari, não só do Chrome (não julgue a partir do seu ambiente não limpo)?

Perguntas frequentes

P. Quanto as conversões caem com o ITP do Safari? R. Varia. O tamanho depende muito da participação de usuários do Safari, do comprimento da sua janela de atribuição e se o seu é um negócio de compra recorrente. O que é verdade em geral: quanto mais um caminho envolve revisitar ou reconverter além de 7 dias, maior o impacto.

P. Isso é um bug do Safari? Dá para consertar? R. Não é um bug — é uma especificação, resultado da proteção de privacidade (ITP) do Safari (WebKit). Não é algo para "consertar"; a resposta realista é mitigar o impacto com emissão de cookies server-side, uma CAPI, e coisas do gênero.

P. Então o Chrome está tranquilo? R. O Chrome permitiu cookies third-party por muito tempo, mas o movimento em direção a uma privacidade mais forte é comum a todos os navegadores. ITP é um nome específico do Safari, mas se preparar para "cookies first-party de curta duração" e "cookies third-party restritos" vale a pena além do Safari, bem no futuro.

P. Estou armazenando o gclid, mas os resultados não são atribuídos. Por quê? R. Se você armazena o gclid em um cookie first-party via JavaScript, o ITP pode apagá-lo depois de 7 dias (24 horas depois de uma navegação cross-site). Se a conversão acontecer depois dessa janela, ela não pode ser atribuída. A correção é mudar para armazenamento server-side — veja rastreamento de conversão com dados first-party para uma estratégia mais ampla sobre reduzir a dependência de identificadores gerenciados pelo navegador.

P. O server-side tagging resolve completamente? R. Reduz drasticamente as perdas, mas não "completamente". Se um erro de implementação deixa o cookie ainda definido via JavaScript, ou a conexão cross-domain está faltando, o efeito é limitado. Depois de implementar, é essencial confirmar que um cookie HTTP realmente está sendo emitido em produção.

P. O impacto do ITP é o mesmo para GA4 e anúncios? R. A raiz é a mesma (encurtamento e bloqueio de cookies), mas se manifesta de forma diferente. No GA4 aparece como inflação de novos usuários e fragmentação de sessões; nos anúncios aparece como expiração de click ID e perda de atribuição. É mais seguro verificar os dois separadamente.

Conclusão: verifique com "o usuário do Safari de produção em sua primeira visita", não com "seu ambiente limpo"

O problema de conversões caindo com o ITP do Safari não pode ser diagnosticado observando se a tag dispara. O que importa é verificar — sob condições reais do Safari — como os cookies estão realmente sendo emitidos, quanto tempo vivem, e se a identificação se sustenta conforme o tempo passa. Isso é uma especificação de privacidade, não um defeito, então considere isso como um dado da realidade, mitigue com emissão server-side e afins, e depois meça se está "realmente funcionando".

O ConversionOK executa sua página ao vivo em um navegador independente e isolado e intercepta as requisições reais enviadas e os cookies emitidos (seu método de emissão e expiração), então os verifica — sem necessidade de clicar no seu próprio anúncio e sem interferência do seu ambiente de escritório. Comece com uma checagem estática gratuita para confirmar como o ponto de entrada da sua medição é tratado sob condições reais de navegador.