Atribuição de cliques após o ITP do Safari: o que ainda funciona em 2026

A Apple lançou a primeira versão do Intelligent Tracking Prevention em setembro de 2017. Foi apresentada como uma funcionalidade de privacidade, o que é correto. Foi também um desmantelamento sistemático de cada alternativa que o setor de tecnologia publicitária havia criado desde que o ecossistema de cookies de terceiros começou a fragmentar-se por volta de 2013. Cada nova versão do ITP fechava a saída de emergência que os profissionais de marketing tinham encontrado na versão anterior. Quando o ITP 2.3 foi lançado em 2019, a sequência de bloqueios tinha sido suficientemente completa que os únicos caminhos de atribuição ainda a funcionar de forma fiável no Safari eram aqueles que nunca tinham dependido de rastreamento entre sites.

Esta publicação percorre essa sequência por ordem cronológica: o que cada versão bloqueou, qual alternativa foi especificamente concebida para fechar, e onde isso deixa a atribuição em 2026. A publicação complementar Atribuição sem cookies explicada abrange o panorama mais amplo entre navegadores; esta foca-se especificamente no Safari e no padrão de cadeia de redirecionamento que sobrevive a tudo isso.

Resumo#

• O ITP 2.0 (2018) bloqueou todo o acesso a armazenamento de terceiros em domínios entre sites, acabando com o caminho de atribuição padrão por pixel publicitário no Safari.
• O ITP 2.1 (2019) limitou os cookies de primeira parte definidos via JavaScript a 7 dias, acabando com janelas de atribuição de um ano definidas por gestores de tags.
• O ITP 2.2 e 2.3 removeram parâmetros de decoração de links e desclassificaram cabeçalhos de referência, fechando as últimas alternativas baseadas em query strings.
• Um link curto no seu próprio domínio define um cookie de primeira parte no lado do servidor no momento do redirecionamento - este é o único padrão que sobrevive ao ITP em todas as suas versões e oferece uma janela de atribuição fiável de 7 dias no Safari.

A cronologia do ITP: análise versão a versão#

O ITP não chegou já formado. Foi lançado de forma incremental, com cada versão visando uma classe específica de alternativa que o setor havia desenvolvido em resposta à versão anterior. Compreender a sequência é importante porque o formato técnico do que sobrevive é definido pelo que foi fechado e como.

ITP 1.0 - setembro de 2017. O primeiro lançamento classificou domínios como "rastreadores entre sites" com base na frequência de bounce e em sinais de interação do utilizador. Os domínios classificados como rastreadores tinham os seus cookies particionados - podiam ser definidos, mas apenas lidos num contexto entre sites se o utilizador tivesse interagido diretamente com o domínio do rastreador nas últimas 24 horas. Para um domínio como um pixel de análise padrão para o qual os utilizadores nunca navegam diretamente, a janela de 24 horas era um bloqueio de facto.

ITP 1.1 - março de 2018. Os anunciantes responderam ao 1.0 encaminhando a atribuição através de cadeias de redirecionamento que tocavam o domínio do rastreador como uma página de chegada de primeira parte antes de saltar para o destino. Isto dava aos utilizadores uma "visita direta" ao domínio do rastreador, o que reiniciava o contador de interação. O ITP 1.1 identificou este padrão - conhecido como rastreador de bounce - e removeu o crédito de interação gerado por cadeias de redirecionamento de bounce. Os domínios que pareciam existir apenas para o padrão de bounce e redirecionamento perderam o seu estatuto de interação.

O que o ITP 2.0 bloqueou#

O ITP 2.0 foi lançado em setembro de 2018. Foi a quebra estrutural. Onde o 1.x havia particionado cookies de terceiros, o 2.0 foi mais longe: removeu completamente o acesso a armazenamento de terceiros para domínios classificados. Cookies, localStorage, IndexedDB, dados em cache - tudo foi bloqueado para qualquer domínio que o ITP classificasse como rastreador entre sites.

O efeito prático na tecnologia publicitária foi significativo. O Facebook Pixel, a tag de conversão do Google Ads e a maioria dos pixels de retargeting dependem da leitura de um cookie entre sites para associar um clique a uma conversão. No Safari após o ITP 2.0, essa leitura falhou. Os próprios relatórios da Meta na época indicavam uma lacuna de 15-25% na cobertura de eventos no tráfego do Safari - cliques e conversões que o pixel via no Chrome ou Firefox simplesmente não apareciam nos utilizadores do Safari.

O bloqueio de armazenamento não se limitou a cookies. Scripts que tentavam persistir identificadores no localStorage sob um domínio classificado como rastreador, ou usar Service Workers para persistência, eram igualmente bloqueados. A intenção do 2.0 era tornar a camada de armazenamento de terceiros estruturalmente indisponível para fins de rastreamento, não apenas quebrar uma técnica específica.

O que o ITP 2.1 bloqueou#

Se o 2.0 matou a atribuição de terceiros, o ITP 2.1 (março de 2019) visou a alternativa que havia crescido em resposta a ele: atribuição por cookie de primeira parte via injeção de gestor de tags.

A lógica era sólida. Se o pixel de terceiros estava bloqueado, ainda se podia persistir a atribuição escrevendo um cookie de primeira parte no próprio domínio do anunciante via JavaScript - tipicamente injetado por um gestor de tags como o GTM. O cookie era de primeira parte e, portanto, não sujeito às restrições de armazenamento de terceiros do ITP. Muitas equipas tinham migrado para janelas de atribuição de um ano definidas desta forma, argumentando que uma escrita document.cookie de primeira parte era segura.

O ITP 2.1 limitou todos os cookies definidos via document.cookie - independentemente do estatuto de primeira ou terceira parte - a um máximo de 7 dias. O limite aplicava-se especificamente a cookies definidos por scripts; cookies definidos via o cabeçalho de resposta HTTP Set-Cookie não foram afetados pelo 2.1. A distinção é precisa e consequente: document.cookie = "..." em JavaScript está limitado a 7 dias. Set-Cookie: ...; Max-Age=31536000 de uma resposta de servidor não está.

A vítima imediata foi a configuração de atribuição baseada em GTM. O GTM escreve cookies através de JavaScript na página. Esses cookies, independentemente da sua data de expiração declarada, passaram a expirar em 7 dias no Safari. Um utilizador que clicasse num link de campanha numa terça-feira e convertesse na quarta-feira seguinte estava fora da janela de atribuição. A janela de atribuição de cookie de primeira parte de um ano para a qual as equipas tinham migrado após o ITP 2.0 tinha desaparecido.

O que o ITP 2.2 bloqueou#

O ITP 2.2 restringiu duas áreas. Em primeiro lugar, reduziu o limite de cookies JavaScript para 24 horas no caso específico em que a página de destino era ligada a partir de um domínio que o ITP havia classificado como rastreador entre sites. Se um utilizador clicasse num link de uma página de domínio classificado, os cookies de primeira parte no site de destino definidos via JavaScript estavam limitados a 24 horas - não 7 dias. O limite de 7 dias manteve-se para caminhos de referência não rastreados, mas o limite de 24 horas aplicava-se quando a cadeia de cliques incluía um domínio classificado.

Em segundo lugar, e mais amplamente notado, o ITP 2.2 introduziu limites na decoração de links. As plataformas publicitárias e as ferramentas de análise tinham desenvolvido um padrão de acrescentar identificadores de atribuição como parâmetros de query a URLs de destino - gclid para o Google Ads, fbclid para a Meta, msclkid para o Microsoft Advertising. Em determinadas condições, se o domínio de ligação fosse classificado como rastreador, o ITP começou a remover esses parâmetros antes do carregamento da página ou a limitar os cookies que podiam ser definidos em resposta à sua presença.

Este foi um ataque direto ao caminho de atribuição baseado em gclid para o qual as equipas tinham pivotado após o 2.0 e o 2.1. O raciocínio era explícito: a Apple considerava que o rastreamento de utilizadores baseado em parâmetros de query era equivalente em impacto de privacidade ao rastreamento baseado em cookies, e as mesmas restrições deveriam aplicar-se.

O que o ITP 2.3 bloqueou#

O ITP 2.3 (setembro de 2019) fechou duas lacunas restantes.

A primeira foi o rebaixamento de referência em navegação entre sites. Onde as versões anteriores se tinham focado em armazenamento e parâmetros de links, o 2.3 abordou o cabeçalho de referência - o valor Referer que uma página recebe quando um utilizador navega para ela a partir de outro site. Para navegações entre sites a partir de domínios classificados, o ITP 2.3 rebaixou a referência para apenas a origem: https://dominio-classificado.com/ em vez do completo https://dominio-classificado.com/caminho?campanha=primavera&fonte=email. O caminho e a query string, que frequentemente continham contexto de atribuição, foram removidos.

A segunda mudança alargou a lógica de limitação de armazenamento. Para além do limite de 7 dias em cookies JavaScript, o ITP 2.3 aplicou um limite de armazenamento após um único clique entre sites a partir de um domínio classificado: todo o armazenamento do lado do cliente no site de destino - cookies, localStorage, IndexedDB - ficou sujeito a limitação. A intenção era fechar uma classe de padrões de atribuição com estado onde o simples facto de ser ligado a partir de um domínio classificado iniciaria uma contagem decrescente na capacidade do destino de persistir dados.

Em conjunto, o 2.2 e o 2.3 fecharam as três principais rotas que as equipas tinham usado após o 2.0 e o 2.1: parâmetros de decoração de links, atribuição baseada em referência e acumulação de armazenamento através de cadeias de cliques entre sites.

O que sobrevive#

A sequência do ITP foi metódica, mas estava direcionada para o rastreamento entre sites. Os padrões que sobrevivem são aqueles genuinamente de primeira parte - onde os dados de atribuição são capturados no seu próprio domínio, definidos pelo seu próprio servidor e nunca passam pelo armazenamento de um domínio de terceiros.

Cookies de primeira parte definidos no servidor. O limite de cookies do ITP 2.1 aplica-se a escritas document.cookie via JavaScript. Os cookies definidos por um servidor via o cabeçalho de resposta HTTP Set-Cookie mantêm a sua data de expiração declarada. A restrição principal é que o cookie deve ser definido no domínio que o servidor controla.

Encaminhamento de eventos no lado do servidor. Se o identificador de clique é capturado no momento do redirecionamento e armazenado no lado do servidor, a pesquisa de atribuição no momento da conversão é uma operação servidor a servidor. Nenhum cookie de browser precisa de sobreviver 7 dias; o ID de clique está na sua base de dados. Esta é a arquitetura por detrás do rastreamento de conversões no lado do servidor e a abordagem que Meta CAPI, GA4 Measurement Protocol e TikTok Events API foram todos concebidos para suportar.

Correspondência determinística via e-mail ou telefone com hash. Quando um utilizador está autenticado ou submeteu um endereço de e-mail, a conversão pode ser correspondida ao clique original por hash de e-mail em vez de identidade de cookie. Este caminho é completamente independente do ITP - nunca dependeu de armazenamento do browser. A limitação é a cobertura: só funciona para utilizadores que se identificaram dentro da janela de atribuição.

O contexto técnico completo para estes padrões está em Atribuição sem cookies explicada.

O padrão de redirecionamento de link curto#

Links curtos no seu próprio domínio - não num domínio de encurtador partilhado - oferecem o caminho de cookie definido no servidor de uma forma que funciona naturalmente com tráfego de campanha.

O mecanismo é simples. Quando um utilizador clica num link de campanha apontando para go.acme.example/primavera26, o pedido atinge um handler de borda em go.acme.example. O handler de borda captura o evento de clique, gera um ID de clique e define um cabeçalho Set-Cookie na resposta de redirecionamento - um cookie de primeira parte definido no servidor em acme.example. Em seguida, emite o 302 para o URL de destino com o ID de clique acrescentado como parâmetro de query.

Como o cookie é definido via Set-Cookie pelo servidor no momento do redirecionamento, o limite de 7 dias de JavaScript do ITP 2.1 não se aplica. O cookie mantém a data de expiração que o servidor definiu. No Safari, com o ITP 2.3 totalmente ativo, um cookie definido no servidor em go.acme.example sobrevive durante toda a janela configurada. No Elido, definimos uma expiração de 7 dias por padrão porque isso corresponde à restrição mais restritiva do ITP para cookies definidos via JS de qualquer forma, e o cookie definido no servidor mantém-se durante todos os 7 dias.

A página de destino lê então o ID de clique do cookie ou do parâmetro de query (o que estiver disponível), escreve-o nos atributos do carrinho ou da encomenda, e o evento de conversão transporta-o no lado do servidor no momento da compra. Nenhum domínio entre sites está envolvido. O cookie está no seu domínio. A pesquisa de atribuição é uma operação no lado do servidor. O ITP não tem nada a bloquear.

É por isso que o suporte de domínio personalizado num link curto é importante para a atribuição: não apenas para a marca, mas para a classificação de cookie de primeira parte. Um domínio de encurtador partilhado como bit.ly ou short.io tem uma origem diferente do seu website. Um cookie definido em bit.ly é um cookie de terceiros em acme.example; o ITP 2.0 bloqueia-o. Um cookie definido em go.acme.example é de primeira parte; nada no ITP o toca. A página soluções/marketers cobre o fluxo de atribuição de campanha de ponta a ponta.

Para um contexto mais aprofundado sobre RGPD relativamente aos dados de clique que um encurtador pode processar legalmente e como configurar a minimização de dados no esquema de eventos de clique, consulte RGPD para encurtadores de URL.

O que ainda não funciona#

A honestidade é mais barata do que vender em excesso uma solução parcial.

Atribuição view-through entre domínios. Se um utilizador vê um anúncio em publisher.example sem clicar e converte posteriormente em advertiser.example, não existe um caminho seguro para o ITP para essa atribuição. A atribuição view-through requer inerentemente um sinal entre sites da impressão para a conversão. O Safari bloqueia-a, e as abordagens de encaminhamento no lado do servidor acima são iniciadas por clique - requerem o clique para definir o cookie de primeira parte ou escrever o ID de clique.

Ligação em tempo real para utilizadores não autenticados. Se um utilizador converte sem nunca ter iniciado sessão ou submetido um endereço de e-mail, o único identificador disponível é o ID de clique do cookie ou parâmetro de query. Se o cookie expirou (mais de 7 dias após o primeiro clique, ou 24 horas se o limite mais restrito do 2.2 se aplicar), a ligação é perdida. O armazenamento de ID de clique no lado do servidor resolve isto para conversões dentro da janela. Não resolve para conversões que chegam após o encerramento da janela.

Janelas de atribuição superiores a 7 dias no Safari para primeiro toque. Se o seu negócio tem um ciclo de compra medido em semanas ou meses - comum em SaaS B2B, comércio eletrónico de alto valor, serviços financeiros - a janela de 7 dias nos cookies de primeira parte do Safari significa que uma fração substancial de conversões não será atribuível ao clique de origem. Para estes modelos de negócio, o caminho determinístico de hash de e-mail é a única opção; a atribuição probabilística no Safari não é suficientemente fiável para agir.

Fingerprinting como substituto. O fingerprinting de canvas, fingerprinting de áudio e enumeração de fontes são alternativas que tentam re-identificar utilizadores entre sessões sem cookies. A Apple avançou explicitamente para reduzir a superfície de fingerprinting no Safari. As notas de lançamento do ITP 2.3 referem "proteção adicional contra outras formas de rastreamento entre sites", e essa direção continuou em cada lançamento subsequente do Safari. O fingerprinting também acarreta um risco legal material ao abrigo do RGPD Artigo 6, conforme explorado em RGPD para encurtadores de URL. Não é um substituto viável para os padrões descritos acima.

Ponto de partida prático#

O padrão de redirecionamento funciona. Configure um domínio personalizado no seu espaço de trabalho de link curto (go.oseudominio.example), encaminhe o tráfego de campanha através dele e configure a sua página de destino para ler o parâmetro de query elido_click ou o cookie de primeira parte e escrevê-lo nos atributos da sua encomenda ou carrinho antes que o utilizador converta. Em seguida, encaminhe as conversões no lado do servidor para as plataformas publicitárias via a API de conversões. A janela de 7 dias cobre a maioria dos caminhos de clique para conversão para a maioria dos tipos de campanha.

Para a configuração de encaminhamento de conversões - Meta CAPI, GA4 Measurement Protocol, a semântica de repetição e o formato de desduplicação - rastreamento de conversões no lado do servidor é o complemento técnico desta publicação. Para a superfície do produto, funcionalidades de rastreamento de conversões é o ponto de partida.

O ITP não matou a atribuição. Matou uma arquitetura específica de atribuição - a construída sobre armazenamento persistente entre sites e acumulação indiferenciada de dados em domínios que não controla. A arquitetura que a substituiu é mais defensável, não menos.