Safari ITP e rastreamento de anúncios: o que ainda funciona

A Intelligent Tracking Prevention (ITP) do Safari limita por quanto tempo um site consegue reconhecer um visitante que volta. Ela bloqueia todos os cookies de terceiros e limita os cookies definidos por JavaScript a 7 dias, ou a 24 horas depois de alguns cliques em anúncios. As compras enviadas via server-side a partir dos dados do pedido, os IDs de clique salvos quando o comprador chega e os dados de clientes com hash continuam funcionando.

Este guia explica cada regra do ITP como o WebKit a documenta, o que as regras fazem com as janelas de atribuição e o remarketing e quais métodos de rastreamento ainda funcionam para uma loja online. Termina com uma forma de verificar o quanto o Safari afeta a sua própria loja.

O que é o Safari ITP?

A Intelligent Tracking Prevention é um conjunto de proteções de privacidade do WebKit, o motor de navegador por trás do Safari no Mac, no iPhone e no iPad. O WebKit a ampliou muitas vezes e documenta as regras atuais na sua página Tracking Prevention.

Algumas regras do ITP valem para todos os sites. Outras valem apenas para domínios que o ITP classificou como tendo capacidade de rastreamento entre sites, com base em como esses domínios se comportam nos sites que uma pessoa visita. O ITP vem ativado por padrão, então afeta todos os visitantes do Safari na sua loja, não só os mais preocupados com privacidade.

Quais são os limites de cookies do Safari ITP?

O limite de 7 dias para cookies de script

A maioria dos pixels e das ferramentas de análise grava os próprios cookies first-party com JavaScript. O pixel do Meta, por exemplo, mantém um ID de navegador em um cookie chamado _fbp. No Safari, o ITP apaga cookies e outros dados de armazenamento criados por JavaScript depois de 7 dias sem interação do usuário no seu site. O WebKit define interação do usuário como um clique, um toque ou o pressionar de uma tecla. Rolar a página não conta.

Na prática, um comprador que volta e usa o seu site em até 7 dias geralmente mantém o cookie. Um comprador que fica mais de 7 dias sem aparecer volta sem ele e parece um visitante novo.

O limite de 24 horas depois de um link decorado

As plataformas de anúncios adicionam IDs de clique aos links dos seus anúncios. O WebKit chama isso de decoração de link. Quando um domínio que o ITP classificou como rastreador envia o visitante para a sua página, e a URL final tem uma query string ou um fragmento, os cookies que o JavaScript grava nessa página de entrada ficam limitados a 24 horas. O limite vale para a página alcançada por essa navegação, não para o site como um todo.

Cookies de terceiros

O Safari bloqueia todos os cookies de terceiros por padrão, e o WebKit diz que não há exceções a esse bloqueio. Um terceiro só pode pedir acesso por mecanismos como a Storage Access API. Por isso, uma plataforma de anúncios não consegue ler o próprio cookie de dentro das suas páginas. Ela depende dos cookies first-party que o pixel dela grava, que ficam sujeitos às regras de 7 dias e de 24 horas.

Camuflagem por CNAME e por endereço IP

Uma solução alternativa comum é um subdomínio de rastreamento, como t.yourstore.com, que aponta para um servidor de rastreamento. Os cookies desse subdomínio são definidos na resposta HTTP, então não são cookies de script. O WebKit trata o subdomínio como camuflado quando ele aponta por um CNAME para um domínio diferente. Desde o Safari 17, ele também trata o subdomínio como camuflado quando o endereço IP dele parece ser de outra parte que não o seu site, por exemplo quando os dois endereços estão em faixas de rede claramente diferentes. Nos dois casos, o ITP limita a 7 dias os cookies definidos na resposta. Quem é o dono do servidor não importa para essas regras.

Como o Safari trata IDs de clique em links?

Um ID de clique como fbclid ou gclid faz parte da URL de entrada. Na navegação normal, o Safari carrega a URL com os parâmetros dela, então um script na página de entrada consegue ler o ID de clique. O limite de 24 horas acima restringe por quanto tempo dura um cookie gravado nessa página. Ele não remove o ID de clique da URL.

A Navegação Privada vai além. Desde o Safari 17, a Link Tracking Protection se aplica quando o visitante navega de um site para outro, como de um anúncio para a sua loja. O Safari remove um conjunto de parâmetros de query que o WebKit identificou como usados para rastrear usuários ou cliques entre sites. O anúncio do WebKit não lista os parâmetros. O exemplo dele remove um parâmetro de rastreamento e mantém um parâmetro de campanha. Na página de entrada, os scripts de terceiros que leem a URL também a recebem sem a query string. As mesmas proteções estão disponíveis na navegação normal para quem ativa a proteção avançada contra rastreamento e fingerprinting para toda a navegação.

E o Private Relay e os endereços IP?

Segundo o WebKit, o Safari esconde os endereços IP de rastreadores conhecidos por padrão desde o Safari 15. Quem paga pelo iCloud+ também pode ativar o iCloud Private Relay. Ele envia o tráfego do Safari por dois relays separados, operados por empresas diferentes, então os sites veem o endereço IP de um relay em vez do endereço do próprio visitante. A Apple diz que o endereço do relay mantém a localização aproximada do visitante, no nível da cidade, e que vários usuários da mesma região podem compartilhar um endereço.

Isso enfraquece o rastreamento que depende do endereço IP, como associar um visitante pelo endereço IP e pelo navegador. Não afeta IDs de clique, e-mails com hash nem dados de pedidos. O ROASaurus usa a associação por IP só como último recurso, e apenas quando exatamente um visitante recente com aquele endereço IP e navegador se encaixa. Um endereço de relay compartilhado costuma, então, resultar em nenhuma associação.

O que o ITP significa para as janelas de atribuição?

Uma janela de atribuição é o número de dias depois de um clique em que uma compra ainda pode ser creditada a esse clique. No ROASaurus, você escolhe uma janela de lookback de 1 a 90 dias, com 7 dias como padrão. As plataformas de anúncios têm as próprias configurações. No Safari, uma configuração que depende só de cookies do navegador só consegue ligar uma compra a um clique enquanto o cookie existe.

O efeito cresce com a janela. Uma janela de 1 dia ou de 7 dias não é maior do que a vida de 7 dias de um cookie de script, a menos que o limite de 24 horas se aplique. Com uma janela de 28 dias, as compras do dia 8 em diante de compradores que não voltaram nesse intervalo dependem de outros dados.

Veja como dimensionar isso para uma loja. Os números são um exemplo; use os seus.

O que o ITP significa para o remarketing?

Os públicos de remarketing são montados a partir de eventos do navegador, como pessoas que viram um produto ou o adicionaram ao carrinho. No Safari, a plataforma não pode usar os cookies de terceiros dela, e o cookie first-party do pixel é apagado após 7 dias sem uma visita. Um visitante do Safari que volta depois de 8 dias parece novo para o pixel. As visualizações de produto anteriores dele já não estão vinculadas a ele no navegador.

Dois efeitos decorrem disso. Públicos com durações longas, como 30 ou 180 dias, mantêm menos visitantes do Safari do que a duração sugere. A sua ferramenta de análise também mostra mais visitantes novos e menos recorrentes do que você realmente tem. Os públicos de lista de clientes montados com e-mails com hash na sua loja ou na sua ferramenta de e-mail não dependem de cookies, então não são afetados da mesma forma.

O que ainda funciona no Safari?

Eventos server-side a partir dos pedidos

Uma compra enviada a partir dos dados de pedido da sua loja não depende de nenhum cookie no Safari. A loja registra o pedido, um servidor o envia à API da plataforma e a plataforma o recebe. O evento inclui o e-mail e o telefone com hash do pedido. A plataforma consegue associá-los a um dos seus usuários e consultar os próprios registros de cliques e visualizações de anúncios, dentro da sua própria janela de atribuição. Leia o que é o rastreamento server-side para ver o caminho completo dos dados.

IDs de clique capturados na entrada

O ID de clique está na URL da primeira página. Um script consegue lê-lo ali e enviá-lo ao seu servidor, onde ele é armazenado com o ID de visitante. A cópia do servidor não expira após 7 dias. O que expira é o cookie do navegador que liga uma visita de retorno àquele visitante armazenado. Outros dados ainda podem ligar um pedido a um clique armazenado, como um e-mail que o comprador informou antes em um formulário de cadastro ou o ID de clique na URL de entrada da sessão que fez o pedido.

Coleta first-party, com o limite de 7 dias

Servir o script de rastreamento e as requisições dele a partir do seu próprio domínio mantém a coleta first-party, o que também ajuda contra bloqueadores de anúncios. Isso, por si só, não faz os cookies durarem mais. Um subdomínio de rastreamento que aponta por um CNAME para outro domínio, ou que o WebKit vê como um endereço IP de terceiros, fica sujeito ao limite de 7 dias. Um subdomínio de rastreamento do ROASaurus reemite o ID de visitante como um cookie HTTP, mas o Safari ainda pode limitar esse cookie a 7 dias. O app proxy do Shopify mantém as requisições no domínio da sua loja, mas o Shopify remove os cookies das requisições e respostas do app proxy, então o ID de visitante ali é gravado por JavaScript e a regra de 7 dias se aplica.

O que o comprador conta a você

Os compradores podem contar como encontraram você, e essa resposta não depende de cookies. Uma pesquisa pós-compra pergunta depois do checkout. No ROASaurus, o modelo Total Impact combina a resposta com os dados de cliques e dá à pesquisa 50% do crédito quando também há cliques.

Como verificar o quanto o Safari afeta a sua loja

1. Descubra a parcela do Safari nos seus pedidos

   Na sua ferramenta de análise, agrupe as compras por navegador. Conte o Safari no Mac, no iPhone e no iPad.

2. Meça o tempo entre o clique e a compra

   Descubra quantos pedidos chegam mais de 7 dias depois do clique no anúncio. No relatório de atribuição do ROASaurus, compare as janelas de 7, 14 e 28 dias e veja quanto crédito se move.

3. Compare as compras do pixel com os pedidos

   Conte os eventos Purchase que o seu pixel enviou, separados por navegador se a sua plataforma permitir, e compare-os com os seus pedidos do mesmo período.

4. Confira os seus eventos de servidor

   Garanta que todo pedido pago seja enviado via server-side com e-mail e telefone com hash, e que as cópias do navegador e do servidor compartilhem um único ID de evento.

Se uma grande parte dos seus pedidos vem do Safari, e muitos deles chegam mais de 7 dias depois do clique, os cookies do navegador sozinhos vão subestimar os resultados dos seus anúncios. As compras enviadas a partir dos dados do pedido, com dados de clientes com hash, dão às plataformas de anúncios outra forma de associar esses pedidos. Você pode ver como o ROASaurus faz isso na página de rastreamento server-side e como ele atribui crédito aos cliques em atribuição.

Fontes

1. WebKit: Tracking Prevention in WebKit
2. WebKit: Intelligent Tracking Prevention 2.2
3. WebKit: CNAME Cloaking and Bounce Tracking Defense
4. WebKit: Private Browsing 2.0
5. Apple Developer: Prepare your network or web server for iCloud Private Relay

No ROASaurus

• Rastreamento server-side no ROASaurus
• Atribuição no ROASaurus
• Funis e domínios vinculados

Continue lendo