Atribuição sem cookies explicada: o que ainda funciona em 2026

A stack de atribuição de marketing que a maioria das equipas construiu entre 2012 e 2019 dependia de duas coisas: um cookie de terceiros colocado pela plataforma publicitária na página de chegada, e um pixel de browser que disparava na página de conversão e correspondia a esse cookie. Ambas as metades desse par estão agora degradadas. Nenhuma delas irá recuperar.

Esta publicação não é um lamento pelo cookie. É um mapa do que realmente funciona em 2026 - quais os caminhos de atribuição que sobreviviram, quais foram apresentados como soluções sem na realidade o serem, e como é que uma stack funcional se parece na prática para equipas que gerem aquisição paga para tráfego europeu.

Resumo#

• O ITP 2.3 da Apple, a Proteção Melhorada contra Rastreamento do Firefox, e a eliminação progressiva de cookies de terceiros do Chrome em curso significam em conjunto que 60–70% do tráfego web europeu bloqueia ou limita severamente os cookies de terceiros por omissão.
• Dois caminhos de atribuição ainda funcionam: identificadores no lado do servidor passados através de um ID de clique, e criação de cookies de primeira parte via uma cadeia de redirecionamento controlada pelo seu domínio.
• Sem cookies não significa sem consentimento. A Diretiva ePrivacy 2002/58/CE e o RGPD ainda exigem consentimento para análises não essenciais, independentemente do mecanismo de armazenamento.
• A ligação probabilística por fingerprint não é uma alternativa conforme na EU; a correspondência determinística por hash de e-mail combinada com um ID de clique no lado do servidor é a única abordagem que resiste tanto à precisão como ao escrutínio regulatório.

O que mudou: uma breve cronologia#

O Safari começou a restringir cookies de terceiros em 2017 com o ITP 1.0. As restrições escalaram rapidamente. O ITP 2.3, lançado em setembro de 2019, limitou o tempo de vida dos cookies de primeira parte definidos por script a sete dias, e a vinte e quatro horas quando a cadeia de referência incluía um rastreador entre sites conhecido. Essa mudança por si só quebrou a transferência padrão de ID de clique para cookie da qual a maioria dos fornecedores de atribuição dependia.

A Proteção Total de Cookies do Firefox foi lançada para todos os utilizadores em 2022, particionando cada cookie de terceiros por site de nível superior. Um cookie definido por pixel.example.com na sua página de checkout e na página de checkout do seu concorrente são agora dois cookies completamente separados - a correlação entre sites desapareceu por construção.

A cronologia do Chrome mudou várias vezes desde que a Google a anunciou em 2019. A posição atual, documentada no site do Privacy Sandbox (consultado em 2026-05-12), tem a depreciação a avançar para um subconjunto de utilizadores com um lançamento completo ainda em curso. Independentemente da data final do Chrome, o panorama europeu já está definido: Safari e Firefox juntos representam a maioria do tráfego móvel e de desktop privacidade-consciente nos mercados europeus. As estratégias de atribuição que requerem cookies de terceiros já estão quebradas para uma grande parte da sua audiência europeia.

O efeito combinado medido em contas típicas de marketing de performance europeu: a atribuição de pixel do lado do browser está a subestimar as conversões em 25–45% dependendo da mistura de tráfego, com verticais com predominância iOS (moda, beleza, apps, serviços de subscrição) na extremidade superior desse intervalo.

Os dois caminhos de atribuição sobreviventes#

Caminho 1: identificadores no lado do servidor#

O mecanismo central é simples. Quando um utilizador clica no seu anúncio, a plataforma publicitária acrescenta um identificador de clique ao URL de chegada - fbclid para Meta, gclid para Google, e assim por diante. Esse identificador existe no URL, não num cookie, por isso o ITP e o particionamento de cookies não o afetam.

A sua página de chegada lê o ID de clique do URL e escreve-o num cookie de primeira parte no seu próprio domínio, ou passa-o para o seu carrinho e eventualmente para o registo da encomenda. Quando o utilizador converte, o seu back-end lê o ID de clique da encomenda e envia a conversão servidor a servidor para a API de conversões da plataforma publicitária - API de Conversões da Meta, GA4 Measurement Protocol, o endpoint de eventos no lado do servidor do Mixpanel.

Este caminho funciona porque nunca toca cookies de terceiros. O ID de clique está na query string do URL no momento da chegada. O seu cookie de primeira parte no seu próprio domínio não está restrito pelo ITP da mesma forma que os cookies de terceiros (embora esteja sujeito ao limite de 7 dias em cookies definidos por script se a cadeia de referência for suspeita - mais sobre isso abaixo). O evento de conversão flui servidor a servidor, completamente fora do browser.

Os pontos fracos são reais. Se o utilizador limpar os cookies entre a chegada e a conversão, o ID de clique desaparece. Se a conversão acontecer noutro dispositivo, não existe ligação entre dispositivos a menos que tenha um utilizador com sessão iniciada com um endereço de e-mail conhecido. E o iOS 17 introduziu a Proteção de Rastreamento de Links na Navegação Privada e no Mail, que remove parâmetros de ID de clique conhecidos dos URLs - fbclid, gclid, msclkid estão na lista de remoção. Um utilizador que chega via a aplicação Mail com a proteção de rastreamento de links ativada não vai transportar o ID de clique para o seu site de forma alguma.

Caminho 2: cadeia de redirecionamento de primeira parte#

O segundo caminho sobrevivente usa um redirecionamento que controla como superfície de atribuição. Em vez do ID de clique da plataforma publicitária, gera o seu próprio identificador persistente no momento do redirecionamento no seu próprio domínio.

Quando um utilizador clica num link no seu domínio - seja um link curto, um redirecionamento de campanha, ou um deep link com marca - o handler de redirecionamento na sua borda corre antes das restrições de privacidade do browser serem aplicadas. Pode:

1. Definir um cookie de primeira parte com um ID de clique gerado pelo servidor no seu domínio.
2. Acrescentar o ID de clique como parâmetro de URL ao URL de destino.
3. Registar o evento de clique no lado do servidor com o contexto técnico completo (IP, user-agent, referência, timestamp) no momento do clique em vez de no momento do carregamento da página.

Como este é o seu domínio e o seu cookie no lado do servidor, fica fora das restrições de cookies de terceiros que o ITP visa. O cookie é definido pelo seu servidor via um cabeçalho de resposta Set-Cookie na resposta de redirecionamento - os cookies definidos pelo servidor não estão sujeitos ao limite de 7 dias do ITP que se aplica às escritas de document.cookie a partir de JavaScript.

Esta é a superfície de atribuição que um encurtador de URL fornece e que um pixel de browser não pode. O redirecionamento resolve no domínio do encurtador. Se esse domínio for o seu próprio domínio com marca, o seu ID de clique é de primeira parte, definido pelo servidor e arquiteturalmente posicionado antes de qualquer restrição de privacidade do lado do browser ser executada.

Como um link curto se torna a superfície de atribuição#

O fluxo de redirecionamento funciona assim. O URL de destino do seu anúncio é um link curto com marca - por exemplo, go.acme.example/saldo-verao. O utilizador clica. O pedido de redirecionamento chega ao handler de borda do Elido, que:

• Pesquisa o URL de destino.
• Gera um identificador elido_click e regista o evento de clique no lado do servidor.
• Define um Set-Cookie: elido_click=<id>; Domain=go.acme.example; SameSite=Lax; Secure; Max-Age=604800 de primeira parte na resposta de redirecionamento.
• Acrescenta ?elido_click=<id> ao URL de destino antes de encaminhar.

A página de destino recebe o ID de clique na query string. O seu gestor de tags ou código de tema lê-o e armazena-o no registo do carrinho ou da encomenda. Quando a conversão acontece, faz POST /v1/conversions com o ID de clique e os detalhes da encomenda - o Elido trata o hash SHA-256 dos identificadores do cliente e o fan-out no lado do servidor para Meta CAPI, GA4 Measurement Protocol e Mixpanel.

O ID de clique nunca viveu num cookie de terceiros. Foi definido pelo servidor, de primeira parte, registado antes de a camada de privacidade do browser ter tido oportunidade de interferir. Para a mecânica completa do passo de encaminhamento no lado do servidor, rastreamento de conversões no lado do servidor via links curtos cobre a desduplicação, os requisitos de hash e a semântica de repetição em detalhe.

Para a questão mais ampla de como o ITP degrada especificamente a atribuição de cliques e o que a cadeia de redirecionamento de link curto faz a esse respeito, atribuição de cliques após o ITP do Safari é o complemento operacional desta publicação.

Ligação de identidade: o que funciona e o que não funciona#

Os IDs de clique no lado do servidor resolvem o problema de atribuição para utilizadores que clicam num link e convertem na mesma sessão de browser no mesmo dispositivo, sem limpar cookies, sem que a proteção de rastreamento de links remova o parâmetro. Isso ainda cobre a maioria das conversões de comércio eletrónico. Mas não cobre tudo, e as abordagens que as equipas usam para preencher a lacuna restante variam significativamente tanto em precisão como em exposição legal.

A correspondência determinística funciona. Se o utilizador tem sessão iniciada, ou fornece o seu endereço de e-mail em qualquer ponto do funil (captura de e-mail, subscrição de newsletter, checkout), pode criar um hash desse endereço de e-mail com SHA-256 e incluí-lo no evento de conversão. Meta CAPI, GA4 e Mixpanel aceitam e-mail com hash como sinal de correspondência juntamente com ou em substituição de um ID de clique. A taxa de correspondência para tráfego com e-mail conhecido é alta - a Meta reporta internamente taxas de correspondência acima de 90% quando um e-mail normalizado com hash está presente. Este é o mecanismo de ligação principal que sobrevive à depreciação de cookies intato.

O par de desduplicação é importante aqui. Cada evento de conversão precisa de um event_id (para Meta) ou transaction_id (para GA4) que seja idêntico entre o envio do pixel do lado do browser e o envio no lado do servidor. Sem isso, ambos os eventos são ingeridos e a conversão é contada em duplicado. O ID da encomenda é a chave de desdup padrão para eventos de compra.

O fingerprinting probabilístico não funciona - e não é legal na UE. O fingerprinting do browser monta um identificador único a partir da combinação de resolução de ecrã, fontes instaladas, fuso horário, user-agent, fingerprint de renderização de canvas e sinais similares. O identificador é probabilístico - atribui uma correspondência de alta confiança entre dois eventos sem um cookie partilhado ou início de sessão. Alguns fornecedores de atribuição oferecem isto como uma solução de "medição sem cookies".

Na UE, esta abordagem tem um problema legal específico. A Diretiva ePrivacy 2002/58/CE, Artigo 5(3), requer consentimento para aceder ou armazenar informação no equipamento terminal de um utilizador. A posição do EDPB, repetida em várias decisões de autoridades de supervisão desde 2022, é que o fingerprinting se enquadra no âmbito do Artigo 5(3) independentemente de o identificador ser tecnicamente um "cookie". O DSB austríaco, a CNIL francesa e o Garante italiano emitiram cada um ações de execução sobre fingerprinting sem consentimento. O argumento "não usamos cookies, usamos fingerprinting" não é um argumento de conformidade; é o argumento que convida a um escrutínio mais próximo.

Mesmo fora da exposição legal, o fingerprinting probabilístico degrada-se em precisão à medida que a entropia do browser diminui. Os browsers modernos focados em privacidade reduzem ativamente a entropia normalizando a saída do canvas e limitando a resolução das APIs de temporização. A qualidade do sinal cai precisamente na população - privacidade-consciente, com predominância iOS - onde mais precisa de medição precisa.

A ligação entre dispositivos via CRM é a lacuna restante. Para utilizadores que convertem noutro dispositivo do que aquele em que clicaram, a correspondência determinística de e-mail é a única abordagem que funciona. Se o utilizador tem sessão iniciada em ambos os dispositivos, o ID de utilizador é a ligação. Se não tem sessão iniciada, o ID de clique no dispositivo A e a conversão no dispositivo B não podem ser ligados sem que o utilizador forneça voluntariamente um identificador (e-mail, telefone) que possa criar um hash e fazer corresponder. Esta lacuna não pode ser fechada no lado do servidor. É um limite de atribuição real no mundo sem cookies.

A sobreposição de conformidade#

O enquadramento da "atribuição sem cookies" pode levar as pessoas a pensar que, como não estão a ser definidos cookies, não é necessário consentimento. Não é isso que a lei diz.

A Diretiva ePrivacy 2002/58/CE, Artigo 5(3), aplica-se a qualquer armazenamento ou acesso a informação no equipamento terminal de um utilizador - não apenas a cookies. Um cookie de primeira parte definido para fins de análise requer o mesmo consentimento que um cookie de terceiros definido para fins de rastreamento, se esse cookie for não essencial. O cookie de ID de clique definido pelo servidor descrito acima é adjacente à análise; pode ou não requerer consentimento dependendo da avaliação da finalidade pelo responsável pelo tratamento e da implementação nacional aplicável da Diretiva.

O que a abordagem no lado do servidor faz - e esta é a sua verdadeira vantagem de conformidade - é deslocar o processamento para fora do dispositivo do utilizador e para o servidor. O registo de eventos de clique, o encaminhamento de eventos de conversão, a ligação de identidade: tudo isto acontece no seu back-end e no back-end do Elido, não num script de browser. Isso significa que os bloqueadores de anúncios não os intercetam, as funcionalidades de privacidade do browser não os particionam, e a postura de minimização de dados é controlável por si em vez de depender do que uma tag de terceiros decide enviar.

A questão da base legal do RGPD é separada da questão da ePrivacy. Mesmo com atribuição no lado do servidor, precisa de uma base legal ao abrigo do Artigo 6 do RGPD para processar dados de clique em sujeitos europeus identificáveis. Para análises a nível de campanha, a maioria dos responsáveis pelo tratamento baseia-se no interesse legítimo ao abrigo do Artigo 6(1)(f) após uma Avaliação de Interesse Legítimo. Para criação de perfis individuais ou retargeting, a base é mais difícil. O cornerstone RGPD para encurtadores de URL cobre a análise dos Artigos 6, 28 e 30 em detalhe; o resumo aqui é que sem cookies ≠ sem consentimento, e a sobreposição de conformidade não desaparece porque o mecanismo de armazenamento mudou.

Os padrões de eventos de clique do Elido refletem uma postura de minimização de dados: os IPs são truncados para /24 (IPv4) antes de persistir, as strings completas de user-agent são analisadas e descartadas. Os dados de resolução completa estão disponíveis por espaço de trabalho se o seu caso de uso o exigir, mas o padrão é a configuração conservadora. Isso é importante para a conversa sobre o adendo DPA com os seus compradores. Para mais informações sobre essa conversa, soluções/marketers cobre os pontos de contacto de aquisição para equipas de marketing.

O que abre mão#

A contabilidade honesta é importante. A atribuição no lado do servidor sem cookies recupera a maioria do sinal perdido para a degradação do lado do browser, mas não recupera tudo.

Identidade entre dispositivos em tempo real. Como referido acima: se um utilizador clica no móvel e converte no computador sem um evento de início de sessão que ligue os dois, a atribuição está perdida. Não existe uma correção no lado do servidor que seja conforme para isto. A lacuna é estrutural.

Atribuição view-through precisa. A atribuição view-through - creditar uma campanha por uma conversão que se seguiu a uma impressão de anúncio, não a um clique - requer que a plataforma publicitária tenha correspondido o utilizador em ambos os eventos. As APIs de conversões no lado do servidor tratam bem a atribuição baseada em cliques; o view-through depende do próprio grafo entre dispositivos da plataforma, que por si próprio degrada proporcionalmente à perda de sinal. Espere que os relatórios de view-through sejam mais ruidosos e menos fiáveis do que os números baseados em cliques.

Janelas de lookback longas. A maioria dos endpoints de API de conversões no lado do servidor impõe um limite de lookback sobre quanto tempo atrás um clique pode ser atribuído a uma conversão. O lookback padrão do Meta CAPI é de 7 dias para click-through. A janela de atribuição do GA4 Measurement Protocol varia por canal. Estes limites são mais curtos do que as janelas de 28 dias ou 90 dias que algumas equipas usavam no mundo baseado em cookies. Produtos de subscrição e compras ponderadas com longos ciclos de pesquisa verão mais conversões cair fora da janela atribuível.

Dominância do último clique. Sem um grafo de identidade multi-toque, a atribuição no lado do servidor assume por padrão o último clique - o ID de clique mais recente na cadeia recebe o crédito. Para campanhas de notoriedade de marca que impulsionam conversões assistidas ao longo de um longo período, a atribuição de último clique no lado do servidor irá sistematicamente subvalorizar o investimento no topo do funil. A mitigação é a ligação CRM via e-mail com hash: se o e-mail de cada utilizador com sessão iniciada está em cada evento de conversão, pode reconstruir uma sequência multi-toque para a parte com sessão iniciada da sua audiência. Para utilizadores anónimos, o último clique é o teto.

Uma stack prática#

Dadas as restrições acima, aqui está a stack de atribuição que funciona para uma equipa de marketing de performance que gere tráfego europeu em 2026.

ID de clique de link curto como ponto de entrada. Todos os destinos de anúncios são links curtos com marca no seu domínio. O redirecionamento define um cookie de primeira parte no lado do servidor e acrescenta o ID de clique ao URL de destino. Isto dá-lhe um identificador persistente, definido pelo servidor, que sobrevive ao ITP e ao particionamento de cookies para a sessão.

Encanamento do carrinho e da encomenda. O ID de clique é escrito num atributo de carrinho no carregamento da página (a partir do parâmetro de URL ou do cookie de primeira parte). Na criação da encomenda, o ID de clique está nos atributos personalizados da encomenda. Esta é a transferência durável - uma vez que o ID de clique está na encomenda, não expira.

CAPI no lado do servidor para a Meta. Após o pagamento da encomenda, o seu back-end (ou a funcionalidade de encaminhamento de conversões) faz POST para Meta CAPI com o ID de clique, o e-mail com hash SHA-256, e os identificadores fbc/fbp dos cookies de primeira parte. O event_id é o ID da encomenda, correspondendo ao pixel do lado do browser. A Meta deduplica dentro da janela de correspondência de 48 horas.

Measurement Protocol no lado do servidor para GA4. Simultaneamente, é enviado um evento no lado do servidor GA4 com transaction_id igual ao ID da encomenda. O client_id é o valor do cookie _ga do GA4 se disponível, o ID de clique como alternativa. O GA4 deduplica em transaction_id dentro da janela de sessão.

Ligação de hash de e-mail CRM. Para qualquer conversão onde o ID de clique esteja em falta (orgânico, direto, pesquisa de marca), o endereço de e-mail com hash é o sinal de atribuição. Isto preenche o segmento de "utilizador conhecido" da sua atribuição e suporta a reconstrução multi-toque básica para clientes com sessão iniciada.

Importação de conversões offline para lookback longo. Para produtos de subscrição ou pipelines B2B onde a conversão acontece semanas após o clique, a importação de conversões offline via a API em lote da plataforma (os eventos offline da API de Conversões da Meta, conversões offline do Google Ads) permite enviar eventos de atribuição para além da janela de lookback em tempo real. A chave de correspondência é ainda e-mail ou telefone com hash; a janela de tempo é alargada. Isto não resolve a atribuição de ciclo longo anónima, mas fecha o ciclo para a parte da sua audiência que forneceu um endereço de e-mail.

A stack acima não requer uma CDP. Requer um encurtador de URL que gere e persiste IDs de clique no lado do servidor, um back-end que leva o ID de clique até à encomenda, e uma camada de encaminhamento de conversões que trata o hash e o fan-out da API. Para a implementação técnica da camada de fan-out, rastreamento de conversões no lado do servidor via links curtos tem os formatos de payload, a mecânica de desduplicação e a semântica de repetição. Para onde isto se encaixa num fluxo completo de UTM de campanha, veja soluções/marketers.

A versão desta stack que não funciona: aquela que depende do próprio grafo entre dispositivos da plataforma publicitária para resolução de identidade, espera que os utilizadores iOS tenham o App Tracking Transparency ativado de uma forma que beneficie a sua medição, ou usa fingerprinting probabilístico para preencher as lacunas. O primeiro está fora do seu controlo. O segundo é ilusório. O terceiro é uma responsabilidade de conformidade na UE.

Trabalhe com o que se mantém.