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

A Intelligent Tracking Prevention (ITP) do Safari limita durante quanto tempo um site consegue reconhecer um visitante que regressa. 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 server-side a partir dos dados da encomenda, os IDs de clique guardados quando o comprador chega e os dados de clientes com hash continuam a funcionar.

Este guia explica cada regra do ITP tal como o WebKit a documenta, o que as regras fazem às janelas de atribuição e ao remarketing e que métodos de tracking continuam a funcionar numa loja online. Termina com uma forma de verificar 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 no WebKit, o motor de navegador por trás do Safari no Mac, no iPhone e no iPad. O WebKit alargou-a muitas vezes e documenta as regras atuais na sua página Tracking Prevention.

Algumas regras do ITP aplicam-se a todos os sites. Outras aplicam-se apenas a domínios que o ITP classificou como tendo capacidades de tracking entre sites, com base no comportamento desses domínios nos sites que uma pessoa visita. O ITP está ativado por predefinição, por isso afeta todos os visitantes da sua loja que usam o Safari, e não apenas os mais atentos à privacidade.

Quais são os limites dos cookies no Safari ITP?

O limite de 7 dias nos cookies de script

A maioria dos pixels e das ferramentas de análise escreve os seus próprios cookies first-party com JavaScript. O pixel da Meta, por exemplo, guarda um ID de navegador num cookie chamado _fbp. No Safari, o ITP elimina os cookies e outro armazenamento criados por JavaScript após 7 dias sem interação do utilizador no seu site. O WebKit define interação do utilizador como um clique, um toque ou o premir de uma tecla. Deslocar a página não conta.

Na prática, um comprador que volta e usa o seu site em 7 dias costuma manter o cookie. Um comprador que se ausente mais de 7 dias volta sem ele e parece um visitante novo.

O limite de 24 horas depois de uma ligação decorada

As plataformas de anúncios acrescentam IDs de clique às ligações dos seus anúncios. O WebKit chama a isto decoração de ligações. Quando um domínio que o ITP classificou como tracker envia o visitante para a sua página, e o URL final tem uma query string ou um fragmento, os cookies que o JavaScript escreve nessa página de entrada ficam limitados a 24 horas. O limite aplica-se à página alcançada através dessa navegação, não ao site como um todo.

Cookies de terceiros

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

Disfarce por CNAME e por endereço IP

Uma solução comum é um subdomínio de tracking, como t.yourstore.com, que aponta para um servidor de tracking. Os cookies desse subdomínio são definidos na resposta HTTP, por isso não são cookies de script. O WebKit trata o subdomínio como disfarçado quando ele aponta através de um CNAME para um domínio diferente. Desde o Safari 17, trata-o também como disfarçado quando o seu endereço IP parece pertencer a uma entidade diferente do seu site, por exemplo quando os dois endereços estão em intervalos de rede claramente diferentes. Em ambos os casos, o ITP limita a 7 dias os cookies definidos na resposta. Quem é o dono do servidor não conta para estas regras.

Como trata o Safari os IDs de clique nas ligações?

Um ID de clique como o fbclid ou o gclid faz parte do URL de entrada. Na navegação normal, o Safari carrega o URL com os seus parâmetros, por isso um script na página de entrada consegue ler o ID de clique. O limite de 24 horas acima restringe durante quanto tempo dura um cookie escrito nessa página. Não retira o ID de clique do URL.

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

E o Private Relay e os endereços IP?

Segundo o WebKit, o Safari esconde por predefinição os endereços IP dos trackers conhecidos desde o Safari 15. Quem paga pelo iCloud+ pode também ativar o iCloud Private Relay. Este envia o tráfego do Safari por dois relays separados, geridos por operadores diferentes, para que os sites vejam um endereço IP de relay em vez do próprio do visitante. A Apple diz que o endereço do relay mantém a localização aproximada do visitante, ao nível da cidade, e que vários utilizadores da mesma zona podem partilhar um endereço.

Isto enfraquece o tracking que depende do endereço IP, como a associação de um visitante por endereço IP e navegador. Não afeta IDs de clique, emails com hash nem dados de encomendas. A ROASaurus usa uma correspondência por IP apenas como último recurso, e só quando exatamente um visitante recente com esse endereço IP e navegador se ajusta. Um endereço de relay partilhado costuma então levar a nenhuma correspondência.

O que significa o ITP 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 atribuída a esse clique. Na ROASaurus escolhe uma janela de lookback de 1 a 90 dias, com 7 dias por predefinição. As plataformas de anúncios têm as suas próprias definições. No Safari, uma configuração que dependa apenas de cookies do navegador só consegue ligar uma compra a um clique enquanto o cookie existir.

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

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

O que significa o ITP para o remarketing?

Os públicos de remarketing são construídos a partir de eventos do navegador, como as pessoas que viram um produto ou o adicionaram ao carrinho. No Safari, a plataforma não pode usar os seus cookies de terceiros, e o cookie first-party do pixel é eliminado após 7 dias sem uma visita. Um visitante do Safari que volta após 8 dias parece novo para o pixel. As suas visualizações de produtos anteriores deixam de estar ligadas a ele no navegador.

Daqui resultam dois efeitos. Os públicos com durações longas, como 30 ou 180 dias, retêm menos visitantes do Safari do que a duração sugere. A sua análise também mostra mais visitantes novos e menos recorrentes do que realmente tem. Os públicos de listas de clientes criados a partir de endereços de email com hash na sua loja ou ferramenta de email não dependem de cookies, por isso não são afetados da mesma forma.

O que ainda funciona no Safari?

Eventos server-side a partir das encomendas

Uma compra enviada a partir dos dados de encomenda da sua loja não depende de nenhum cookie no Safari. A loja regista a encomenda, um servidor envia-a para a API da plataforma e a plataforma recebe-a. O evento inclui o email e o número de telefone com hash da encomenda. A plataforma consegue associá-los a um dos seus utilizadores e consultar os seus próprios registos de cliques e visualizações de anúncios, dentro da sua própria janela de atribuição. Leia o que é o tracking server-side para ver o percurso completo dos dados.

IDs de clique captados à chegada

O ID de clique está no URL da primeira página. Um script pode lê-lo aí e enviá-lo para o seu servidor, onde fica guardado com o ID de visitante. A cópia do servidor não expira ao fim de 7 dias. O que expira é o cookie do navegador que liga uma visita de regresso a esse visitante guardado. Outros dados ainda podem ligar uma encomenda a um clique guardado, como um endereço de email que o comprador indicou antes num formulário de registo, ou o ID de clique no URL de entrada da sessão que fez a encomenda.

Recolha first-party, com o limite de 7 dias

Servir o script de tracking e os seus pedidos a partir do seu próprio domínio mantém a recolha first-party, o que também ajuda contra os bloqueadores de anúncios. Não faz, por si só, os cookies durarem mais. Um subdomínio de tracking que aponta através de 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 tracking da ROASaurus volta a emitir o ID de visitante como cookie HTTP, mas o Safari pode mesmo assim limitar esse cookie a 7 dias. O app proxy do Shopify mantém os pedidos no domínio da sua loja, mas o Shopify remove os cookies dos pedidos e das respostas do app proxy, por isso o ID de visitante aí é escrito por JavaScript e aplica-se a regra dos 7 dias.

O que o comprador lhe diz

Os compradores podem dizer-lhe como o encontraram, e essa resposta não depende de cookies. Um inquérito pós-compra pergunta depois do checkout. Na ROASaurus, o modelo Total Impact combina a resposta com os dados de cliques e dá ao inquérito 50% do mérito quando também há cliques.

Como verificar quanto o Safari afeta a sua loja

1. Descubra a percentagem de encomendas feitas no Safari

   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 quantas encomendas chegam mais de 7 dias depois do clique no anúncio. No relatório de atribuição da ROASaurus, compare as janelas de 7, 14 e 28 dias e veja quanto mérito se desloca.

3. Compare as compras do pixel com as encomendas

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

4. Verifique os seus eventos do servidor

   Confirme que cada encomenda paga é enviada server-side com email e telefone com hash, e que as cópias do navegador e do servidor partilham um ID de evento.

Se uma grande parte das suas encomendas vier do Safari, e muitas delas chegarem mais de 7 dias depois do clique, só com cookies do navegador os resultados dos seus anúncios ficam abaixo do real. As compras enviadas a partir dos dados da encomenda, com dados de clientes com hash, dão às plataformas de anúncios outra forma de associar essas encomendas. Pode ver como a ROASaurus o faz na página de tracking server-side e como atribui mérito aos cliques na 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

Na ROASaurus

• Tracking server-side na ROASaurus
• Atribuição na ROASaurus
• Funis e domínios ligados

Continue a ler