HTTP, o protocolo por trás de toda navegação na web, é stateless — não tem memória entre uma requisição e outra. Cada vez que você clica num link, é como se o servidor nunca tivesse falado com você antes. A analogia mais usada é a de um peixinho dourado: ele esquece tudo instantaneamente.
Cookies existem para resolver exatamente isso. Pense numa cafeteria: você pede um espresso com dois açúcares, e o caixa anota sua identidade e preferência num cartão, que entrega a você. Na próxima visita, você mostra o cartão e o caixa já sabe quem você é e o que você gosta, sem perguntar de novo. O cookie é esse cartão — um pequeno dado que fica guardado no seu navegador e é reapresentado ao site a cada nova visita, dando “memória” a um protocolo que originalmente não tem nenhuma.
Quatro fatos estruturais sobre cookies
Antes de chegar ao atributo que mudou tudo, valem quatro pontos que explicam por que cookies funcionam do jeito que funcionam:
- Cookies adicionam “estado de sessão” a um protocolo que originalmente não guarda memória nenhuma entre requisições.
- Ficam armazenados no navegador do cliente, não no servidor — o site precisa pedir o cookie de volta a cada visita.
- Navegadores isolam cookies por site — e é exatamente esse isolamento que determina a diferença entre cookie de primeira parte e de terceira parte.
- Um punhado de atributos controla todo o comportamento do cookie:
Domain,SameSite,Secure,HttpOnly, além de nome e valor.
Primeira parte × terceira parte: o que o Domain define
O atributo Domain define para qual site o navegador deve reenviar aquele cookie. Se o cookie foi criado pelo domínio que você está visitando, é primeira parte. Se foi criado por um domínio diferente — carregado dentro da página através de um pixel, script ou iframe de outra empresa —, é terceira parte.
O cookie de terceira parte é a base técnica do rastreamento cross-site clássico: uma rede de anúncios coloca o mesmo cookie em milhares de sites diferentes, e como o navegador reenvia esse cookie sempre que reconhece o domínio de origem — não importa em qual site ele esteja embutido —, a rede consegue reconstruir seu histórico de navegação entre sites completamente diferentes.
SameSite: o atributo que muda o jogo
O atributo SameSite controla se um cookie é enviado em requisições que atravessam de um site para outro — exatamente o mecanismo que sustenta o rastreamento cross-site. Ele tem três valores possíveis:
| Valor | Comportamento | Efeito prático |
|---|---|---|
| Strict | Cookie nunca é enviado em navegação vinda de outro site | Mais restritivo — pode quebrar fluxos legítimos, como voltar de um link externo já logado |
| Lax | Cookie é enviado em navegação de nível superior (clicar num link), mas não em recursos incorporados (imagem, iframe, script de terceiro) | Bloqueia o rastreamento clássico via pixel/script de terceiros, mantendo fluxos normais de navegação |
| None | Cookie é enviado em qualquer contexto, incluindo cross-site — exige o atributo Secure junto | Comportamento antigo, permite rastreamento cross-site completo |
O marco que mudou o mercado: em fevereiro de 2020, o Chrome tornou SameSite=Lax o padrão para qualquer cookie que não especificasse esse atributo explicitamente. Antes dessa mudança, a ausência do atributo se comportava como None — permissivo por padrão. Depois, passou a se comportar como Lax — restritivo por padrão, a menos que o site declare explicitamente SameSite=None; Secure para manter o comportamento antigo.
Por que isso é o “fim do cookie de terceiros” na prática
A frase “fim do cookie de terceiros” costuma ser tratada como uma política vaga de privacidade, mas a causa raiz é um atributo técnico específico e verificável. Antes de 2020, um cookie de rastreamento cross-site funcionava sem exigir nada especial do site que o criava. Depois da mudança de padrão do Chrome, esse mesmo cookie deixou de ser enviado em contexto de terceiro a menos que fosse explicitamente marcado como SameSite=None; Secure — o que expõe a intenção de rastreamento de forma muito mais visível e sujeita a bloqueio por outras camadas de proteção do navegador.
Entender que a restrição é um atributo técnico — não uma política de negócio abstrata — muda a forma de avaliar as alternativas que o mercado oferece:
- Server-side tagging contorna a restrição de fato, porque move a coleta de dado para fora do navegador, onde a lógica de SameSite não se aplica da mesma forma — o servidor conversa com outro servidor, não há cookie de terceiro cruzando domínio no navegador do usuário.
- Dado de primeira parte (first-party data) contorna a restrição porque o cookie pertence ao mesmo domínio que o usuário está visitando — SameSite não impede nada aqui, o cookie nunca precisou atravessar domínios.
- Customer Data Platform (CDP) não contorna SameSite diretamente — é uma camada de organização do dado de primeira parte já coletado, então seu valor depende de a coleta em si já estar correta.
Sem entender o mecanismo, é fácil comprar uma solução que apenas “adia” o problema — por exemplo, um pixel de terceiro que ainda depende de cookie cross-site e vai continuar perdendo precisão conforme mais navegadores reforçam a restrição.
HttpOnly: o outro atributo que costuma passar despercebido
Um segundo atributo com implicação direta para quem opera tag manager e scripts de analytics é o HttpOnly. Um cookie marcado com esse atributo fica inacessível a JavaScript — só pode ser lido e enviado pelo próprio navegador nas requisições HTTP, nunca por um script rodando na página.
Isso significa que cookies de sessão de login, por exemplo, costumam ser marcados como HttpOnly justamente para reduzir risco de roubo via script malicioso (XSS) — mas também significa que nenhuma tag de analytics ou pixel de marketing consegue ler esse cookie, mesmo que quisesse. Se uma integração promete “ler o cookie de sessão para identificar o usuário” via JavaScript, e esse cookie é HttpOnly, a promessa simplesmente não é tecnicamente possível — vale confirmar isso antes de contratar.
Expires e Max-Age: por quanto tempo o cartão fica válido
Voltando à analogia da cafeteria: o cartão de fidelidade não dura para sempre — em algum momento expira, e o cliente precisa de um novo. Os atributos Expires (uma data absoluta) e Max-Age (um número de segundos a partir de agora) controlam exatamente isso para um cookie. Um cookie sem nenhum dos dois é chamado de cookie de sessão: ele desaparece assim que o navegador é fechado, em vez de persistir por um período definido.
Isso tem implicação direta em atribuição de marketing: uma campanha que depende de um cookie de sessão para rastrear a jornada de um visitante perde essa informação assim que a pessoa fecha a aba ou o navegador, mesmo que volte ao site horas depois. Um cookie com Max-Age configurado para 30 dias, por outro lado, sobrevive ao fechamento do navegador e permite reconectar a visita de retorno à sessão original — desde que os demais atributos, sobretudo Domain e SameSite, permitam que ele seja reenviado naquele contexto específico.
Secure: o requisito básico que ainda falha
O atributo Secure garante que o cookie só trafegue por conexão HTTPS, nunca por HTTP sem criptografia. Parece óbvio no ambiente atual, mas ainda aparece como falha em auditorias — sobretudo em subdomínios ou ambientes de staging esquecidos rodando HTTP puro, onde um cookie sem o atributo Secure pode ser interceptado em uma rede não confiável.
O que perguntar ao avaliar uma ferramenta de rastreamento
Diante de qualquer fornecedor que prometa “rastreamento preciso entre sites” ou “atribuição cross-domain”, a pergunta que revela se a solução ainda depende do mecanismo restringido é:
“Isso depende de cookie de terceiro com SameSite=None, ou funciona inteiramente com dado de primeira parte e/ou processamento server-side?”
Se a resposta for a primeira opção, a solução está numa base que cada atualização de navegador torna mais frágil — o que já aconteceu de forma acelerada desde 2020, com Safari e Firefox bloqueando cookies de terceiro de forma ainda mais agressiva que o Chrome.
Safari e Firefox: quem já foi além do Chrome
Vale reforçar que a mudança de padrão do Chrome em 2020 não foi o ponto mais restritivo do mercado — apenas o mais visível, por ser o navegador mais usado. Safari, através do seu recurso Intelligent Tracking Prevention (ITP), já bloqueava cookies de terceiro por padrão desde antes dessa mudança, com uma política ainda mais agressiva. Firefox, através do Enhanced Tracking Protection, seguiu caminho semelhante.
Isso significa que, na prática, qualquer estratégia de marketing que dependa pesadamente de cookie de terceiro já vinha perdendo alcance de rastreamento em parte da base de usuários — a de Safari e Firefox — bem antes da mudança do Chrome se consolidar. Medir a distribuição de navegador da própria audiência é um exercício rápido e revelador: se uma parcela relevante do público acessa via Safari (comum em audiência de iOS), o impacto real da restrição de cookie de terceiro já é maior do que muitos times de marketing percebem, porque calculam o problema só em relação ao Chrome.
Próximos passos para auditar seus cookies
A ação concreta: abra as ferramentas de desenvolvedor do navegador na página inicial do seu site, veja a aba de cookies, e confira quantos deles têm SameSite=None configurado — esses são os que dependem do comportamento antigo e mais restringido. Depois, confirme com o time técnico ou com a agência quais desses são realmente necessários versus quais são vestígios de uma integração de rastreamento que já não funciona como deveria.
Se sua operação de marketing ainda depende fortemente de atribuição baseada em cookie de terceiro, esse é o momento de priorizar a migração para dado de primeira parte — não como tendência de mercado, mas porque o atributo técnico que sustentava a abordagem antiga já não existe mais por padrão nos principais navegadores.
