Como a sincronização de cookies cruza IDs de anúncios entre sites

O que é sincronização de cookies?

Empresas de ad tech usam a sincronização de cookies para casar o ID que uma empresa guarda no seu navegador com o ID que uma segunda empresa guarda para o mesmo navegador, para que as duas possam tratar os dois registros como uma única pessoa. Cada empresa define o próprio cookie de terceiros a partir do próprio domínio, e o navegador não deixa um domínio ler o cookie de outro. A sincronização de cookies contorna isso passando o ID em uma URL em vez de ler o cookie diretamente.

O Google explica o motivo no guia do Authorized Buyers: "the security model of internet browsers restricts one from reading a cookie set by another domain." O serviço de cookie matching dele existe para que um bidder possa casar o próprio cookie com "a corresponding bidder-specific Google User ID", que o Google descreve como "an encrypted form of the doubleclick.net cookie." O mercado chama a mesma coisa de cookie matching, ID syncing ou user matching.

Se você tem um site, a sincronização de cookies acontece nas suas páginas sempre que você carrega uma tag de anúncio, um pixel de retargeting ou um contêiner de gerenciador de tags que puxa um dos dois. O seu próprio analytics nunca vê os IDs casados. As empresas de anúncios veem.

Como a sincronização de cookies funciona, passo a passo?

A sincronização de cookies funciona por meio de uma cadeia de requisições HTTP que um pixel inicia e um redirecionamento conclui, com o ID de usuário de uma empresa escrito na URL que o navegador segue. O guia de cookie matching do Google documenta o fluxo para os parceiros de Real-Time Bidding, e outras redes de anúncios seguem o mesmo padrão:

1. Uma tag de correspondência carrega. Uma página que o visitante abre inclui uma tag de pixel de um bidder que aponta o navegador para o Cookie Matching Service do Google. O navegador envia ao Google o cookie doubleclick.net junto com essa requisição.
2. O Google redireciona. O Google responde com um redirecionamento HTTP 302 para a URL de cookie matching do bidder e coloca o Google User ID específico daquele bidder em um parâmetro google_gid.
3. O bidder lê os dois IDs. O navegador segue o redirecionamento até o domínio do bidder, que recebe o próprio cookie nos cabeçalhos da requisição e o ID do Google na URL.
4. O par vai para uma tabela de correspondência. O bidder guarda o mapeamento na própria tabela de correspondência, ou envia ao Google o próprio ID em um parâmetro google_hm para que o Google hospede a tabela.
5. As requisições de lance carregam a correspondência. As requisições de lance seguintes para aquele navegador incluem os dados casados do bidder, então o bidder sabe que a impressão pertence a um usuário de quem ele tem um perfil.

O Google também roda o fluxo no sentido inverso com um parâmetro google_push, em que o Google coloca a tag e o bidder redireciona de volta para o Google para concluir a correspondência. O visitante não vê nada disso. O pixel é uma imagem 1x1 ou uma requisição invisível, o mesmo bloco de construção descrito no guia sobre spy pixels.

Por que as empresas de ad tech precisam da sincronização de cookies?

As empresas de ad tech precisam da sincronização de cookies porque cada uma só reconhece um navegador pelo próprio cookie, e um leilão em tempo real exige que comprador e vendedor concordem sobre quem é o visitante em milissegundos. Imagine que um data broker conhece um navegador como a91f, uma exchange o conhece como 7c2e e um bidder o conhece como 55d0. Sem uma tabela de correspondência, o bidder não consegue saber que a impressão oferecida pertence à pessoa que abandonou um carrinho em outro site ontem.

Cada sincronização acrescenta mais uma empresa que guarda um ID para o mesmo navegador. É por isso que a sincronização de cookies fica no centro do rastreamento entre sites e que o guia sobre como os data brokers coletam informações pessoais a lista ao lado de pixels e SDKs como fonte de dados de comportamento online. Uma tag de sincronização em uma página de notícias se espalha para todos os parceiros com quem o dono da tag sincroniza, e cada um deles passa a conhecer o mesmo navegador pela mesma chave.

O que o Safari e o Firefox fizeram com a sincronização de cookies?

O Safari e o Firefox quebraram a sincronização de cookies na base ao cortar o cookie de terceiros de que cada etapa da cadeia de redirecionamentos depende. A correspondência só funciona se o próprio cookie do bidder chegar com a requisição redirecionada, e os dois navegadores impedem isso por padrão.

O WebKit chama o padrão de redirecionamento de "tracker collusion." Quando um domínio é classificado como rastreador, "a check is made to see which other domains have previously redirected to" ele, "and all of them get classified too." Um domínio classificado com o qual o usuário não interagiu como first-party nos últimos 30 dias de uso do navegador tem todos os dados de site apagados.

A Mozilla descreve a abordagem do Firefox em termos mais simples: qualquer cookie que um site ou um conteúdo incorporado define "is confined to the cookie jar assigned to only that website." Um bidder ainda recebe um cookie, mas é um cookie diferente em cada site, o oposto do que uma sincronização precisa. O guia de cookies particionados CHIPS mostra como o Chrome oferece o mesmo modelo particionado aos sites que optam por ele.

A sincronização de cookies ainda funciona no Chrome?

A sincronização de cookies ainda funciona no Chrome para todo usuário que não bloqueou os cookies de terceiros, porque o Google decidiu manter os cookies de terceiros como uma configuração do usuário. Em um post de 22 de abril de 2025, o líder do Privacy Sandbox no Google, Anthony Chavez, escreveu que o Chrome iria "maintain our current approach to offering users third-party cookie choice in Chrome, and will not be rolling out a new standalone prompt for third-party cookies." Os usuários escolhem uma opção nas configurações de Privacidade e segurança do Chrome, e a página de ajuda do Chrome diz "by default, third-party cookies are blocked in Incognito mode."

Depois, o Google aposentou a maior parte da tecnologia substituta. Uma atualização de 17 de outubro de 2025 listou as APIs do Privacy Sandbox que seriam aposentadas, entre elas Topics, Protected Audience, a Attribution Reporting API e os Related Website Sets, citando "their low levels of adoption." CHIPS e FedCM continuam.

Para o dono de um site, qualquer tag de anúncio ou de retargeting que você carrega no Chrome ainda pode sincronizar IDs com os parceiros dela. Remover a tag é a única forma de impedir isso nas suas páginas.

Como o dono de um site pode ver a sincronização de cookies nas próprias páginas?

O dono de um site vê a sincronização de cookies abrindo o painel de rede do navegador na própria página e procurando cadeias de redirecionamentos entre domínios de anúncios que levam IDs na query string. Carregue no Chrome uma página com anúncios ou tags de retargeting, com os cookies de terceiros permitidos, abra o DevTools, filtre por "Img" ou "Doc" e ordene por domínio.

Sinais de uma sincronização:

• Uma requisição a um domínio de anúncios que retorna status 302 com um cabeçalho Location apontando para outro domínio de anúncios.
• Parâmetros de query com nomes como uid, gid, buyeruid, partner_uid ou google_gid contendo um valor aleatório longo.
• Um GIF 1x1 ou uma resposta vazia no fim da cadeia.
• A mesma cadeia disparando a cada visualização de página, e não uma vez por visita.

Depois, repita a verificação no Safari. O Relatório de Privacidade do Safari lista os rastreadores conhecidos que ele impediu de criar um perfil do visitante, e o guia do relatório de privacidade do Safari explica como lê-lo. A diferença entre os dois navegadores mostra quantos parceiros as suas tags trazem.

Por que o analytics first-party não precisa da sincronização de cookies?

O analytics first-party não precisa da sincronização de cookies porque só conta visitas ao site em que está instalado, então não existe uma segunda empresa cujo ID ele precise casar. Uma visualização de página, um referenciador, uma meta e uma compra pertencem todos a um único site. A ferramenta de analytics precisa distinguir uma sessão de outra naquele site, e não reconhecer o mesmo navegador em um blog de receitas e em uma loja de sapatos.

O Flowsery foi construído para esse trabalho mais restrito. O script de tracking do Flowsery roda sem cookies, com um hash de visitante que muda todo dia, e não coleta dados pessoais. No modo sem cookies, os IDs de visitante mudam diariamente, então o Flowsery não liga um visitante anônimo entre dias ou dispositivos. O Flowsery afirma que nunca vende nem compartilha dados de analytics e que não coleta impressões digitais de navegador. Para usuários logados, a chamada identify() do Flowsery anexa o ID de usuário que você já tem, e a atribuição de receita liga um pagamento do Stripe, Paddle, Polar, Lemon Squeezy ou Shopify à sessão que converteu. Nenhuma das duas etapas envolve o ID de um parceiro de anúncios. A página da solução de tracking sem cookies mostra como as sessões são agrupadas com hashes com salt.

Perguntas frequentes

Sincronização de cookies é o mesmo que cookie matching?

Sim. A documentação do Authorized Buyers do Google a chama de cookie matching, e o mercado também usa ID syncing e user matching. Os quatro nomes descrevem a mesma troca de IDs por redirecionamento entre dois domínios de ad tech.

A sincronização de cookies precisa de cookies de terceiros?

Sim, o fluxo clássico de redirecionamento precisa que o cookie de terceiros do bidder chegue com a requisição redirecionada. O Safari bloqueia todos os cookies de terceiros e o Firefox os particiona por site, então o bidder recebe nenhum cookie ou um cookie específico daquele site. O Chrome ainda envia cookies de terceiros para os usuários que não os bloquearam.

Posso impedir a sincronização de cookies no meu site?

Você impede a sincronização de cookies nas suas páginas removendo as tags de anúncios, de retargeting e de data brokers que a iniciam. Um banner de consentimento que bloqueia essas tags até o visitante aceitar também impede as sincronizações para os visitantes que recusam. A sua ferramenta de analytics não tem nenhuma configuração que desligue a sincronização em tags que ela não controla.

A sincronização de cookies conta como dado pessoal pelo GDPR?

Um ID sincronizado é um identificador online que distingue um navegador entre sites, o que faz dele um dado pessoal pelo GDPR. Na UE, definir e ler os cookies por trás dele exige consentimento pelas regras de ePrivacy. Compartilhá-lo com parceiros também exige uma base legal para cada destinatário.

O Chrome bloqueou os cookies de terceiros?

Não. O post do Google de 22 de abril de 2025 diz que o Chrome vai continuar oferecendo a escolha sobre cookies de terceiros nas configurações e não vai lançar um aviso separado. O Chrome bloqueia cookies de terceiros por padrão apenas no modo Incognito.

O Flowsery sincroniza cookies com redes de anúncios?

Não. O Flowsery mede o tráfego do seu próprio site, afirma que nunca vende nem compartilha dados de analytics, e o modo sem cookies dele usa um hash de visitante que muda todo dia, sem dados pessoais. O Flowsery não tem IDs de parceiros de anúncios para casar.

O que é uma tabela de correspondência na sincronização de cookies?

Uma tabela de correspondência é a lista onde uma empresa de ad tech guarda qual ID seu pertence a qual ID de um parceiro. O bidder a monta depois do redirecionamento, quando viu o próprio cookie e o ID do parceiro na mesma requisição. No fluxo do Google, o bidder também pode devolver seu ID em um parâmetro google_hm para que o Google hospede a tabela.

Como verifico se meu site faz sincronização de cookies?

Abra o DevTools no Chrome com cookies de terceiros permitidos, carregue uma página com tags de anúncios ou de retargeting e filtre por "Img" ou "Doc". Procure uma resposta 302 cujo cabeçalho Location aponte para outro domínio de anúncios, e parâmetros como uid, gid ou google_gid com um valor aleatório longo. Um GIF de 1x1 no fim da cadeia é mais um sinal de sincronização.

O Safari bloqueia a sincronização de cookies?

O Safari bloqueia o cookie de que a sincronização depende. O ITP do WebKit bloqueia todos os cookies de terceiros sem exceções, então o redirecionamento chega ao bidder sem o cookie dele e não há o que casar. O Safari também classifica domínios que redirecionam entre rastreadores, o que coloca todos os domínios da cadeia na classificação.

A sincronização de cookies funciona no modo Anônimo?

A ajuda do Chrome diz que os cookies de terceiros são bloqueados por padrão no modo Anônimo. O cookie do bidder então não chega com a requisição redirecionada, e a sincronização clássica não tem o que casar enquanto o usuário não mudar essa configuração.