O que realmente aconteceu
(não foi o cookie)

O que realmente aconteceu
(não foi o cookie)

Existe uma narrativa confortável circulando há cinco anos: os cookies vão acabar, prepare-se. Ela tem um problema. Está errada, e a versão correta é pior.

O que o Google fez, na ordem

Em abril de 2025, o Google anunciou que não vai depreciar os cookies de terceiros no Chrome, mantendo a escolha com o usuário. Em outubro de 2025, encerrou a maior parte das APIs do Privacy Sandbox, o conjunto que existia justamente para substituir o cookie.

Ou seja: a profecia não se cumpriu, e o plano B foi cancelado. Se a sua estratégia de dados dos últimos anos foi "esperar o Sandbox", você esperou por nada.

E por que o problema continua, e piorou

Porque a perda de sinal nunca dependeu do Chrome. Ela é estrutural: vem de cinco frentes independentes, nenhuma delas sob controle do Google, e todas já em vigor hoje.

Nenhuma das cinco muda se o Chrome mudar de ideia outra vez. E há uma sexta, só do Brasil, que o capítulo 2 trata: o Pix.

O verdadeiro fim do client-side: o teto de sete dias

Se for para escolher um mecanismo — um só — que encerrou a era do client-side, é este.

O ITP trata de forma diferente dois cookies que, no papel, são a mesma coisa:

Agora pense no seu ciclo de recompra.

As consequências se espalham por tudo que você olha:

• Novo × recorrente vira ficção. Sua base fiel aparece como aquisição, e o CAC parece pior do que é em alguns canais e melhor em outros.
• Jornada multi-sessão desaparece. Quem viu um anúncio de topo hoje e comprou em duas semanas não tem mais fio ligando as duas visitas, a venda vai inteira para o último toque.
• Retargeting encolhe em silêncio. A lista some sozinha a cada sete dias, e ninguém recebe alerta.
• Teste A/B longo perde validade. O mesmo usuário cai em variantes diferentes em semanas diferentes.

É isso que "fim do client-side" significa de verdade. Não é uma data futura anunciada por big tech: é um comportamento já em produção no navegador de uma fatia grande dos seus clientes, e que independe do que o Chrome decidir.

A armadilha do "mas nós já usamos first-party"

Quase nunca resolve, porque confunde de quem é o cookie com quem escreveu o cookie.

O _ga é um cookie first-party. Ele é gravado no seu domínio. E ainda assim vive sete dias no Safari, porque foi escrito por JavaScript. O que muda o resultado não é o domínio: é a origem da escrita. Capítulo 4 desmonta essa confusão inteira.

O que isso não significa

Um material honesto precisa te dizer onde parar de se preocupar.

• Não significa que a sua medição é lixo. Significa que ela tem um viés conhecido, de tamanho estimável, e que hoje ninguém na sua empresa sabe o tamanho. Dado com viés medido é utilizável. Dado com viés desconhecido é o problema.
• Não significa que você precisa trocar de stack. A maior parte do ganho vem de mudar onde o evento nasce e quem escreve o cookie, não de trocar de ferramenta.
• Não significa urgência de prazo. Não há data-limite. Há um custo contínuo de decidir com um número que não fecha, e ele já está sendo pago.

Ninguém está mentindo. Cada plataforma está relatando o que conseguiu observar, e cada uma observou uma fatia diferente, com sobreposição. A soma passar do faturamento real não é fraude: é a assinatura matemática de três réguas independentes medindo o mesmo evento com janelas e critérios diferentes, cada uma cega em pontos distintos.

Onde vamos no resto do material

O capítulo 2 abre o evento e mostra os sete pontos onde ele morre, com o teste de detecção de cada um. O capítulo 3 traduz isso para decisão de verba. A Parte II define first-party e server-side sem folclore, incluindo o que server-side não faz. A Parte III desenha a arquitetura. A Parte IV entrega o plano de cinco fases e o protocolo que prova que funcionou.

Anatomia de um evento
que não chega

Anatomia de um evento
que não chega

Uma compra acontece. Entre o clique do cliente e a linha no seu relatório, existem sete lugares onde esse evento pode morrer, e em cada um ele morre de um jeito diferente, com um teste de detecção diferente.

A maior parte das conversas sobre "perda de dado" trata o problema como uma coisa só. Não é. Tratar como uma coisa só é o motivo pelo qual times compram server-side esperando resolver tudo e resolvem três dos sete.

Morte 1 · A tag não carrega

O cliente tem um bloqueador. O navegador nunca busca o script de medição. Não há evento perdido no caminho: não houve evento. Nenhum retry resolve, porque nada executou.

Isso vale para o container de tags, para o script da plataforma de mídia e, cada vez mais, para subdomínios de coleta reconhecidos: as listas de bloqueio incluem padrões de endpoint de vendor, então um subdomínio apontado para um fornecedor conhecido também entra na lista.

Como detectar: compare o volume de page_view da sua ferramenta de medição com o volume de requisições de página do seu servidor ou CDN, no mesmo período. A diferença percentual é o seu teto de bloqueio. É o teste mais barato de todos.

Morte 2 · O consentimento não veio

Banner recusado, ou fechado sem escolha. Conforme a configuração, a tag não dispara, ou dispara em modo sem armazenamento. Nos dois casos você perde a continuidade da identidade.

Como detectar: instrumente o próprio banner. Você precisa saber a taxa de aceite por dispositivo e por página de entrada. Se ninguém na sua empresa sabe essa taxa hoje, esse é o primeiro número a levantar. Ele determina o teto de tudo que vem depois.

Morte 3 · O cookie é capado

O capítulo 1 já detalhou: cookie escrito por JavaScript vive sete dias no Safari. O evento chega, mas chega desconectado do anterior. Você não perde a venda: perde a jornada que levou a ela.

Como detectar: proporção de usuários novos por navegador, comparando Safari e Chrome. E, se você tem login, a taxa de reconhecimento de cliente recorrente por navegador.

Morte 4 · A requisição não sai

O evento disparou no momento em que o usuário estava saindo da página: clicou em um link, voltou, fechou a aba. Se a requisição não usar um mecanismo resistente ao descarregamento da página, ela é abortada no meio.

Essa é a mais invisível das sete: não deixa rastro em lugar nenhum, nem no navegador, nem no servidor. Ela é mais comum justamente nos eventos que mais importam: cliques de saída, início de checkout, redirecionamento para pagamento.

Como detectar: compare a contagem de um evento de clique de saída com a contagem de chegadas no destino correspondente. E teste em rede lenta (throttling 3G no DevTools), o problema aparece muito mais em conexão ruim, que é a conexão de boa parte do Brasil.

Morte 5 · O evento nunca existiu

Esta é a maior do Brasil, e é a única que não tem nada a ver com navegador.

A sua medição client-side observa o que acontece nas páginas do seu site. Quando a conversão se conclui em outro lugar, não há tag nenhuma para disparar:

Com o Pix respondendo por uma fatia expressiva dos pagamentos no e-commerce brasileiro. Faixas públicas apontam entre 30% e 40%, com variação enorme por categoria e ticket, e o tamanho desse buraco não é marginal. E ele contamina tudo a jusante: relatório de canal, análise de CRO, otimização de campanha, cálculo de CAC.

Como detectar: receita por meio de pagamento no seu ERP contra receita por meio de pagamento na sua ferramenta de medição, mesmo período. Se o Pix aparece sub-representado na medição, você achou o buraco, e ele tem tamanho, não é opinião.

Morte 6 · Chegou sem a chave

O evento chegou. Está no relatório. E é inútil para reconciliar, porque não traz o identificador que permite ligá-lo ao pedido real.

Sem order_id ou transaction_id estável, você não consegue responder à pergunta que encerra toda discussão de divergência: quais pedidos exatamente estão na plataforma e não estão no ERP? Fica só com totais que não batem e nenhum jeito de investigar item a item.

Variações que aparecem em auditoria com frequência incomum:

• transaction_id que muda entre a página de obrigado e o webhook do pagamento, então o mesmo pedido existe duas vezes com chaves diferentes.
• ID do pedido no formato de exibição para o cliente, diferente do ID interno do ERP. Dois sistemas, duas verdades, nenhum join.
• Receita enviada com frete e imposto em umas fontes e sem em outras. A divergência é de definição, não de coleta, e é a causa mais comum de "não bate" que encontramos.

Morte 7 · O destino duplica ou descarta

Quando você passa a enviar o mesmo evento por dois caminhos, do navegador e do servidor, que é exatamente o desenho recomendado. Cada plataforma de destino precisa entender que são o mesmo evento. Isso se faz com um identificador de evento compartilhado entre os dois envios.

Sem ele, um de dois desastres:

• Duplicação: a plataforma conta duas conversões. O ROAS reportado sobe, ninguém reclama, e a verba é realocada sobre um número inflado. Duplicar é o pior dos dois, porque parece uma boa notícia.
• Descarte errado: a deduplicação por heurística derruba o envio que trazia mais informação e mantém o mais pobre.

Como detectar: a contagem de conversões da plataforma imediatamente antes e depois de ligar o segundo caminho de envio. Se subiu de forma abrupta e desproporcional, você está duplicando. É por isso que a fase de implementação prevê execução em paralelo com comparação, e não um corte seco.

O que a perda de sinal
faz com a decisão

O que a perda de sinal
faz com a decisão

Perda de dado custa em alocação de verba, não em relatório. E o prejuízo aparece onde ninguém procura.

Primeiro: as três verdades

Cada plataforma é juíza de si mesma e puxa a atribuição para o próprio lado. Não é má-fé: é o resultado de três réguas com janelas, critérios e cegueiras diferentes.

Quando os números não fecham, a realocação de verba acaba sendo feita por quem argumenta melhor na reunião, não por quem tem razão. O dado deixou de ser árbitro, e a decisão voltou a ser política.

Segundo: o canal de topo morre primeiro

Toda morte do capítulo 2 prejudica desproporcionalmente o canal que influencia sem fechar: anúncio de descoberta trabalha em janela longa e multi-sessão, que é exatamente o que o teto de sete dias apaga. O resultado é um ciclo que parece disciplina:

1. O topo aparece com desempenho ruim na régua enviesada.
2. A verba migra para o fundo, que mede bem porque está perto da conversão.
3. O fundo colhe a demanda que o topo gerou e reporta ainda melhor.
4. O topo recebe menos. A demanda futura encolhe.
5. Seis meses depois, o CAC subiu e ninguém sabe explicar.

Terceiro: a mesma pessoa comprada duas vezes

Com a identidade partida a cada sete dias, o cliente que você já tem no CRM volta a ser um desconhecido para a plataforma. Você o compra de novo, como aquisição, e paga preço de aquisição por uma recompra que ia acontecer. Nos relatórios, isso aparece como crescimento de base. É perda de margem.

Quarto: o CAC deixa de ser KPI e passa a ser trava

É aqui que problema de dado vira problema de conselho. Enquanto o CAC é um número que ninguém verifica, ele deixa de ser indicador e passa a ser o teto do quanto a empresa se permite crescer.

Quinto: a tag que quebrou há três semanas

As mortes do capítulo 2 são crônicas: acontecem sempre, num patamar estável. Existe uma categoria aguda, a coleta que funcionava e parou. Um deploy do front, uma troca de template, um plugin atualizado, uma alteração no checkout: a tag para de disparar e nada avisa. Os relatórios continuam saindo, com números menores, e a queda se confunde com sazonalidade.

Quase nenhuma operação mede o tempo entre a quebra e a descoberta, e é um dos números mais caros que existem: nessa janela você não só perdeu dado: otimizou campanha com dado errado. O lance automático aprendeu com o buraco.

Não se resolve com arquitetura, e sim com monitoramento: volume esperado de evento por hora, com faixa e alerta. Capítulo 11.

O que fazer com este capítulo

Não use nada disso como argumento de urgência. Use como lista de perguntas da sua próxima reunião de dados. Se as respostas vierem como opinião em vez de número, você já sabe onde está o trabalho:

First-party: o que é e o que
o mercado vende como se fosse

First-party: o que é e o que
o mercado vende como se fosse

"First-party" virou selo de qualidade e parou de significar coisa alguma. Três conceitos diferentes disputam o mesmo rótulo, e a confusão entre eles é a mais lucrativa do mercado de ferramentas de medição.

Os três "first-party"

O teste de três perguntas

Serve para qualquer ferramenta que se apresente como first-party. Responde em dois minutos:

1. Quem escreve o cookie de identidade, o navegador ou o servidor? Se for JavaScript, o teto de sete dias vale e o resto da conversa é decoração.
2. Para qual host o navegador envia o evento? Se for o domínio do fornecedor, não é coleta first-party — é um terceiro com discurso novo.
3. Se for um subdomínio meu, quem responde por ele? Subdomínio apontado por CNAME para a infra do fornecedor é tratado como o terceiro que é, com o teto de sete dias de volta.

O que a coleta first-party entrega, concretamente

E o que ela não entrega

• Não recupera quem bloqueou o carregamento inicial. Se o bloqueador impediu o script que envia o evento, não há evento. Coleta first-party reduz a superfície, não a elimina.
• Não dispensa consentimento. Base legal não é questão de topologia de rede. Capítulo 9.
• Não conserta dado que nasceu errado. Se o data layer manda a receita com frete em uma página e sem em outra, o servidor recebe as duas versões erradas com muito mais confiabilidade.

Uma nota sobre propriedade do dado

Há uma pergunta que costuma aparecer aqui e que não é técnica: se a minha coleta passa a rodar em infraestrutura de um fornecedor, o dado continua sendo meu?

É a pergunta certa. E a resposta honesta de qualquer fornecedor deveria ser verificável em contrato, não em slide. No nosso caso, a formulação é esta, e ela está escrita: a infraestrutura é nossa, o dado é seu. Você acessa a qualquer momento e, se sair, leva tudo.

Essa frase não diz que o dado fica no seu ambiente, a arquitetura é isolada por cliente, mas roda na nossa infraestrutura, e afirmar o contrário seria mentira que um head de TI derruba na primeira reunião. Ela diz onde está a propriedade e qual é o direito de saída. É a distinção que importa.

Server-side:
cinco coisas com o mesmo nome

Server-side:
cinco coisas com o mesmo nome

"Vamos para server-side" é uma frase que pode significar cinco projetos diferentes, com custos, prazos e resultados diferentes. Confundi-los é o motivo pelo qual tantos projetos entregam menos do que prometeram.

Como as cinco se encaixam

A ordem importa, e é contraintuitiva: a mais barata de implementar não é a primeira a fazer.

// A ordem que funciona
1. Contrato de evento    ← definir ANTES de mover qualquer coisa
2. Coleta first-party     ← subdomínio + cookie escrito pelo servidor
3. Container server-side  ← o navegador passa a falar só com você
4. APIs de conversão      ← com event_id compartilhado, em paralelo
5. Backend como fonte     ← onde o Pix para de ser invisível
6. Reconciliação contínua ← o que prova que os 5 acima funcionaram

// A ordem que se vê na prática, e por que falha
1. APIs de conversão      ← é a mais rápida de ligar…
2. …duplicação            ← …e sem event_id, infla o ROAS
3. …ninguém reclama       ← porque o número ficou melhor

O passo 1 é o que mais se pula e o que mais custa. Contrato de evento é o documento que define, para cada evento, o nome, quando dispara, quais campos são obrigatórios, qual é o tipo de cada campo e o que significa cada valor. Sem ele, cada destino recebe uma variação, e a divergência que você vai investigar seis meses depois nasceu aqui.

O que muda na prática, do ponto de vista do navegador

Os limites honestos
do server-side

Os limites honestos
do server-side

Este é o capítulo que vale mais que os outros na mesa de uma reunião técnica. Seis coisas que server-side não faz, e que são vendidas como se fizesse.

1 · Não contorna consentimento

Mover a coleta para o servidor não cria base legal. Se o usuário recusou o tratamento para finalidade publicitária, enviar o dado dele pelo servidor é o mesmo tratamento, com uma camada de indireção. Sob LGPD, a indireção não é defesa.

Server-side ajuda na conformidade por outro caminho, legítimo e melhor: centraliza a decisão sobre o que sai, e a regra passa a ser aplicada em um lugar em vez de doze tags.

2 · Não inventa dado que nunca foi coletado

Se o seu checkout nunca capturou a categoria do produto, nenhum servidor vai adicioná-la. Uma quantidade desconfortável de projetos descobre no meio do caminho que o problema era o data layer, e que o servidor só transportou o vazio com mais eficiência.

3 · Não derrota o ATT

O consentimento de rastreamento no iOS é sobre o identificador de publicidade do dispositivo. Não existe caminho de servidor que recupere um identificador que o sistema operacional não entrega. O que ajuda em app é outra coisa: enviar sinal de conversão de qualidade pelo SDK e pelo servidor, e aceitar que o pareamento será probabilístico e agregado.

4 · Não transforma correlação em causalidade

Esta é a confusão mais caveira, porque é a mais confortável de acreditar.

Server-side e coleta first-party fazem a sua régua ficar melhor: mais evento chega, com mais integridade, e a identidade dura. Régua melhor significa atribuição menos enviesada. Não significa que você passou a saber o que o anúncio causou.

5 · Não elimina divergência, e nem deveria

Depois de tudo implementado, plataforma e ERP continuam divergindo. Isso é correto, não é falha. Eles medem coisas diferentes:

• A plataforma conta conversões dentro da janela de atribuição dela, e credita a si mesma segundo o critério dela.
• O ERP conta pedido, ou pagamento aprovado, ou nota emitida: três números diferentes, em três momentos diferentes.
• Nenhum dos dois conta cancelamento e devolução do mesmo jeito.

O alvo é divergência explicada: um número estável, com causa conhecida, que você consegue reproduzir. Divergência de 8% que você sabe explicar é saudável. Divergência de 8% que ninguém sabe de onde vem é o mesmo problema de antes, com stack mais caro.

6 · Não é de graça, e o custo tem duas partes

Server-side tem custo de implantação e custo de operação. O segundo é o que aparece depois e surpreende:

• Infraestrutura por volume de evento. Todo evento agora passa por um servidor seu. A conta cresce com o tráfego, e cresce em pico de Black Friday, que é quando ela menos pode falhar.
• Manutenção de conector. Cada plataforma de destino muda a API dela sem te avisar. Alguém precisa acompanhar, testar e corrigir, continuamente.
• Sustentação de coleta. Todo deploy de front é um risco novo para o data layer. Sem alguém monitorando, você volta à morte aguda do capítulo 3.

Por que este capítulo existe

Porque a Precisian já errou por acreditar no contrário. Passamos seis meses tentando fazer agente de IA responder pergunta de negócio em cima de dado não modelado. Ele inventava. Não porque o modelo era ruim, porque não havia contrato de métrica, não havia auditoria do dado, e ele puxava de qualquer lugar.

A lição que ficou vale para server-side igual: camada de transporte melhor não conserta camada de significado ausente. Quem te vender o transporte e chamar de solução está te vendendo um terço do problema.

As três camadas:
coleta, transporte, destino

As três camadas:
coleta, transporte, destino

Toda arquitetura de dado que funciona tem as mesmas três camadas. Quando um projeto trava, é quase sempre porque alguém tratou duas delas como uma.

CAMADA 1 · COLETA          de onde o evento nasce
  navegador (data layer)  ──┐
  backend (ERP/OMS)       ──┤
  webhook do PSP          ──┼──►  endpoint no SEU domínio
  app (SDK)               ──┤          cookie escrito pelo SERVIDOR
  CRM / televendas        ──┘

CAMADA 2 · TRANSPORTE      o contrato e a identidade
  validação de schema     ──┐
  resolução de identidade ──┼──►  evento canônico, com event_id
  enriquecimento          ──┤
  regra de consentimento  ──┘

CAMADA 3 · DESTINO         quem consome
  ├─► plataformas de mídia   (CAPI, Events API, Enhanced Conv.)
  └─► armazém / lake       ← o único que guarda histórico

Camada 1 · Coleta, os dois detalhes que decidem tudo

O subdomínio precisa ser genuinamente seu

Não basta ter um subdomínio: ele precisa ser servido por infra que responde por você, com o seu certificado. Subdomínio que resolve por CNAME para o endpoint de um fornecedor é tratado como terceiro, e o teto de sete dias volta.

Escolha um nome que não pareça ferramenta de rastreamento: track, analytics, pixel e metrics estão em listas de bloqueio. Algo neutro e curto não é truque: é só não se anunciar ao bloqueador.

O cookie precisa vir do servidor

Nenhum outro detalhe desta arquitetura pesa tanto. O cookie de identidade tem que ser emitido pelo servidor, no cabeçalho HTTP:

Set-Cookie: _pid=<identificador-opaco>;
  Domain=.sualoja.com.br;   // o seu domínio, não o do fornecedor
  Path=/;
  Max-Age=34164000;         // ~13 meses; não é capado em 7 dias
  Secure; HttpOnly;         // HttpOnly: JS não lê, então JS não pode ser capado
  SameSite=Lax

Camada 2 · Transporte, o contrato de evento

Aqui mora o trabalho que ninguém quer fazer e que decide se o projeto envelhece bem: um documento versionado que define cada evento com precisão de API.

{
  "event": "purchase",
  "event_id": "ord_88421-1726500000",   // dedup entre navegador e servidor
  "event_time": 1726500000,               // quando o FATO ocorreu, não o envio
  "source": "backend",                    // browser | backend | psp_webhook | erp
  "identity": {
    "anonymous_id": "a1f…",             // cookie escrito pelo servidor
    "user_id": "cli_40192",             // ID do cliente no ERP, estável
    "email_sha256": "9c1…"              // normalizado antes do hash
  },
  "order": {
    "order_id": "88421",                // a MESMA chave do ERP
    "status": "paid",                   // created | paid | invoiced | canceled
    "revenue": 489.90,                  // definição declarada abaixo
    "revenue_basis": "net_no_shipping",  // ← o campo que evita 6 meses de briga
    "payment_method": "pix",
    "currency": "BRL"
  },
  "consent": { "ads": true, "analytics": true },
  "schema_version": "1.2.0"
}

Três campos deste exemplo faltam em quase toda implementação que revisamos:

• event_id, sem ele, navegador e servidor enviando o mesmo evento produzem duas conversões. É a morte 7.
• revenue_basis: declarar qual receita você envia (bruta, líquida, com ou sem frete e imposto) encerra a discussão mais comum de divergência. Custa um campo.
• status: distinguir pedido criado de pagamento aprovado é o que faz Pix e boleto serem contabilizáveis sem inflar.

Camada 3 · Destino, e a assimetria que decide arquitetura

Plataformas de mídia e o armazém não são dois destinos equivalentes:

Daí a regra: o armazém é o único destino em que você reconstrói o passado, e por isso não cabe em "fase 2". Sem ele, cada mudança de critério de uma plataforma apaga a sua série histórica, e você descobre no ano seguinte, quando precisar comparar.

Identidade e deduplicação:
a parte difícil

Identidade e deduplicação:
a parte difícil

Se você fizer tudo neste material e errar identidade, terá construído um transporte confiável para um dado que não se conecta a nada. É aqui que os projetos realmente falham.

Os três níveis, e qual deles é a âncora

A costura, em ordem

1. Visita anônima. O servidor emite o anonymous_id na primeira requisição. Todo evento subsequente carrega esse identificador.
2. Identificação. Login, checkout ou newsletter revelam a pessoa. Nesse momento — e só nesse — grava-se o vínculo anonymous_id → user_id, com data e hora.
3. Retroatividade. O vínculo permite reprocessar o histórico anônimo daquele dispositivo e atribuí-lo à pessoa. Isso só funciona se você guardou o histórico, de novo, o armazém.
4. Consolidação. Uma pessoa acumula vários anonymous_id (celular, desktop, aba anônima). A tabela de vínculo é o que transforma quatro visitantes em um cliente.

Normalização antes do hash, o detalhe que quebra o pareamento

Plataformas pareiam por hash do e-mail e do telefone. Se você normaliza diferente do que elas esperam, o hash não casa e a taxa de pareamento cai sem nenhum erro aparecer em log nenhum.

// e-mail
minúsculas → remover espaços nas pontas → SHA-256
"  Joao.Silva@Loja.com " → "joao.silva@loja.com" → 9c1a…

// telefone (Brasil), o que mais erra
só dígitos → com código do país → sem zero de operadora
"(11) 98765-4321" → "5511987654321" → 4f2b…

Teste de aceite: a própria plataforma reporta uma qualidade ou taxa de correspondência do evento. Esse indicador é o termômetro. Se ele não subir depois de ligar a API de conversão, a normalização está errada, não o volume.

Deduplicação: um identificador, dois caminhos

O desenho correto envia o evento importante duas vezes: do navegador e do servidor. Parece desperdício e não é: são duas chances de o evento sobreviver a mortes diferentes. O navegador morre por bloqueio; o servidor morre por falha de integração. Enviar pelos dois é redundância proposital.

O que faz isso funcionar em vez de duplicar é o event_id idêntico nos dois envios. Recomendação para e-commerce: derive-o de algo que já é único e estável.

// bom: determinístico, igual nos dois caminhos
event_id = "purchase_" + order_id

// ruim: gerado na hora, diferente em cada envio → duplica
event_id = uuid()

Onde isso conecta com o capítulo 3

"A mesma pessoa comprada duas vezes" é um problema de identidade, não de atribuição. O cliente do CRM aparece como desconhecido para a plataforma porque a costura de identidade não existe, então você paga aquisição por recompra. Resolver identidade devolve margem antes de devolver relatório.

Consentimento sem mitologia

Consentimento sem mitologia

Não é orientação jurídica. É a descrição de mecanismos técnicos e das escolhas que eles impõem, para você levar ao seu jurídico a pergunta certa, e não a genérica.

Os quatro sinais do Consent Mode v2

Os dois últimos foram a novidade da v2 e são justamente os que governam envio por API de conversão. Sem ad_user_data, o envio server-side de dado do cliente não deveria acontecer, e é exatamente esse envio que as implementações apressadas fazem sem checar.

Básico ou avançado, a escolha real

LGPD: as perguntas que valem levar ao jurídico

A LGPD não fala em cookie. Fala em tratamento de dado pessoal, finalidade e base legal. A tradução prática, e que tende a ser o enquadramento mais defensável:

• Medição própria (entender o uso do seu site, para o seu próprio relatório) tende a caber em legítimo interesse, desde que informada com clareza, minimizada e com opção real de oposição.
• Compartilhamento com plataforma de publicidade para personalização é outra finalidade, e tende a exigir consentimento específico.
• A finalidade precisa estar declarada antes do tratamento. Coletar para uma finalidade e usar para outra é o problema, independentemente da tecnologia.

Note que a distinção não é técnica — é de finalidade. Duas empresas com arquitetura idêntica podem estar em situações jurídicas diferentes por causa do que declaram e do que fazem com o dado.

O desenho que se defende sozinho

1. O sinal de consentimento viaja no evento. O campo consent do contrato do capítulo 7 não é enfeite — é o que permite aplicar a regra no servidor.
2. A regra mora em um lugar. O servidor decide, por destino, o que sai. Doze tags com doze lógicas de consentimento é doze pontos de falha e uma auditoria impossível.
3. Registre a decisão, não só o dado. Guardar qual consentimento estava vigente no momento do evento é o que responde à pergunta de um titular ou de um regulador meses depois.
4. Minimização por destino. Nem todo destino precisa de todo campo. Enviar menos é mais defensável e reduz superfície de risco.

Plano de implementação
em cinco fases

Plano de implementação
em cinco fases

Ordem importa mais que velocidade. Cada fase tem um entregável verificável, uma coisa que costuma quebrar, e um critério de saída. Quem pula a fase 0 não consegue provar nada depois.

Fase 0 · Inventário e linha de base

~2 semanas. A fase que todo mundo quer pular e é a única que não pode faltar.

• Entregável: inventário de tudo que dispara hoje (tag, pixel, script de terceiro, endpoint de destino) e um documento de linha de base com os seis números do capítulo 3, medidos hoje.
• O que quebra: aparecem tags que ninguém sabe quem instalou, e normalmente algumas de fornecedor antigo ainda enviando dado. É achado comum e é bom: dívida que se paga aqui.
• Critério de saída: a divergência atual entre plataforma e ERP está escrita, com a definição de receita declarada. Sem número de "antes", não existe prova de melhora, só sensação.

Fase 1 · Contrato de evento e data layer

~2 a 3 semanas. O trabalho menos glamouroso e o de maior retorno.

• Entregável: o contrato versionado (modelo no capítulo 7), implementado no data layer, com os campos obrigatórios presentes em todas as páginas de conversão.
• O que quebra: descobre-se que a receita é calculada de formas diferentes em páginas diferentes, e que o transaction_id não é o ID do ERP. Corrigir isso é a fase.
• Critério de saída: validação automática de schema passando em 100% das páginas de conversão, e o order_id do data layer casando com o do ERP em amostra.

Fase 2 · Coleta first-party

~2 semanas. Pouco código, e é onde o teto de sete dias morre.

• Entregável: subdomínio de coleta servido pela sua infraestrutura, com o seu certificado, emitindo o cookie de identidade via Set-Cookie conforme o capítulo 7.
• O que quebra: CSP. A política de segurança de conteúdo do site frequentemente não libera o novo endpoint, e o navegador bloqueia em silêncio, a requisição nem sai. É a falha mais comum desta fase, e a mais fácil de não perceber, porque não gera erro visível para o usuário.
• Critério de saída: proporção de usuários novos no Safari converge para a do Chrome. Esse é o teste, e ele é inequívoco.

Fase 3 · Server-side em paralelo

~3 a 4 semanas. 🔴 Em paralelo, nunca em substituição.

• Entregável: container server-side recebendo do endpoint da fase 2 e distribuindo para os destinos, com API de conversão ligada nas plataformas principais e event_id compartilhado.
• O que quebra: duplicação (morte 7) e pareamento ruim por normalização errada de e-mail e telefone (capítulo 8). Os dois aparecem nos primeiros dias, e os dois têm indicador próprio na plataforma.
• Critério de saída: a contagem de conversões da plataforma se mantém coerente com a contagem de pedidos do ERP, e o indicador de qualidade de correspondência da plataforma sobe. Se o volume subiu e a qualidade não, você duplicou.

Fase 4 · O backend como fonte

~3 a 4 semanas. A fase em que o Pix para de ser invisível.

• Entregável: o evento de pedido passa a nascer do backend — do webhook do provedor de pagamento e do ERP — e não da página de obrigado. Inclui estados: pedido criado, pagamento aprovado, cancelado, devolvido.
• O que quebra: a contagem sobe e parece erro. Não é: você passou a ver o que não via. Por isso a linha de base da fase 0 é indispensável, sem ela, esse salto é indistinguível de bug, e há uma chance real de alguém reverter a fase que mais funcionou.
• Critério de saída: receita por meio de pagamento na medição converge com a do ERP, Pix incluído. É o teste final de todo o material.

Fase 5 · Reconciliação e monitoramento contínuos

Permanente. É a operação, não uma fase de projeto. É o que impede que tudo isso volte ao estado anterior em seis meses.

• Entregável: um painel de reconciliação (plataforma × medição × ERP, com a divergência e a causa), mais monitoramento de volume de evento com faixa esperada e alerta.
• O que quebra: nada. É aqui que se descobre o que quebrou em outro lugar. Que é exatamente o objetivo.
• Critério de saída: não há. Se existir data de término, o projeto regride.

Como verificar que funcionou

Como verificar que funcionou

Implementação que não termina em número é opinião com nota fiscal. Este é o protocolo, e ele começa antes de comparar qualquer coisa.

Passo 1 · Declarar a definição, antes de olhar o número

A maior parte da divergência que se atribui a falha técnica é, na verdade, definicional. Antes de comparar, escreva:

Duas pessoas comparando os mesmos sistemas com definições diferentes chegam a divergências diferentes, e discutem por semanas achando que discutem de técnica.

Passo 2 · A régua de três colunas

                   PLATAFORMA   MEDIÇÃO    ERP        Δ vs ERP
pedidos                  1.284      1.402    1.451        −11,5%  /  −3,4%
receita (líq., s/frete)  R$ …       R$ …     R$ …          …
  ├─ cartão              …          …        …            ← costuma fechar
  ├─ Pix                 …          …        …            ← o buraco mora aqui
  └─ boleto              …          …        …            ← defasagem de dias
novos × recorrentes      …          …        …            ← testa identidade

Quebrar por meio de pagamento é o que transforma "não bate" em um achado localizado. Divergência concentrada no Pix é morte 5. Divergência espalhada por igual é definição ou janela. Divergência só em novo × recorrente é identidade.

Passo 3 · As sete verificações

Passo 4 · O monitoramento que resolve a morte aguda

O capítulo 3 falou da tag que quebrou há três semanas. Isto é o conserto:

1. Para cada evento crítico, estabeleça o volume esperado por hora do dia e dia da semana, porque tráfego de e-commerce tem forma, e comparar com a média diária mascara a queda.
2. Defina uma faixa de tolerância baseada na variação histórica, não em palpite.
3. Alerta quando sair da faixa por duas janelas consecutivas. Uma janela é ruído; duas é evento.
4. O alerta vai para quem pode agir. Alerta que chega em canal que ninguém lê é ruído com custo de implementação.

Comprar ou construir

Comprar ou construir

Nós vendemos a versão comprada disso. Então o capítulo é escrito com a conta aberta dos dois lados, e com a parte em que construir é a resposta certa dita em voz alta.

O que construir exige de verdade

A conta que quase sempre é subestimada é a de sustentação, porque implantação acaba e sustentação não.

Essa frase é o resumo do capítulo. O trabalho é dividido em duas naturezas bem diferentes: manter encanamento e produzir decisão. Só a segunda é vantagem competitiva, e é a primeira que consome o time.

Quando construir é a resposta certa

Sem rodeio. Construa se:

• Você já tem engenharia de dados com capacidade ociosa e quer manter a competência dentro de casa como ativo estratégico.
• Sua operação tem uma particularidade que nenhum fornecedor modela bem, e você sabe nomear qual é.
• Você tem uma regra de residência ou de tratamento de dado que exige controle total da infraestrutura.
• O volume é grande o suficiente para que a economia de escala da sua própria infra supere a de um fornecedor.

Quando comprar é a resposta certa

• O time que existe é de análise, não de engenharia de dado, e você prefere que ele analise.
• Você já paga por três ou quatro ferramentas que fazem pedaços disso, sem integração.
• Já existe um data lake pela metade. (É o caso mais comum que encontramos: começou, o patrocinador saiu, ficou a 50%, e a 50% ele custa igual e entrega pouco.)
• O gargalo é tempo até a decisão, não capacidade técnica.

Uma coisa que a versão comprada deveria incluir e raramente inclui

Perguntar isso a qualquer fornecedor separa quem vende projeto de quem vende plataforma: quando uma tag quebrar, de quem é o problema?

Se a resposta for "abre um ticket e a gente orça", você comprou implantação, não sustentação, e a morte aguda do capítulo 3 continua sendo sua. A formulação que usamos, e que está em contrato: enquanto você é cliente, a saúde do seu tracking é responsabilidade nossa. Se uma tag quebrar, o problema é nosso antes de ser seu.

A fronteira

A fronteira

Este material te dá um mapa de onde o dado morre e a ordem de conserto. Existe uma linha a partir da qual nenhum material consegue te ajudar, e ela é fácil de nomear.

Não é modéstia retórica: quantificar perda exige um contrafactual. Exige saber o que teria acontecido com a coleta correta, e isso não se estima de fora, com benchmark de mercado. Se estimássemos, seria chute com casa decimal, e você não teria como nos contestar. É justamente o tipo de número que este material se recusa a produzir.

As perguntas que só o seu dado interno responde

• Qual é, em reais, a divergência entre o que as plataformas reportam e o seu ERP, e ela está crescendo ou estável?
• Quanto da sua receita de Pix nunca apareceu em relatório de canal?
• Quanto do seu investimento está alocado sobre um número que ninguém consegue verificar?
• Quanto tempo se passa, hoje, entre uma tag quebrar e alguém descobrir?
• Quantos dos seus "novos clientes" do último trimestre eram recompra que a régua não reconheceu?

O que fazer a seguir, em ordem de custo

1. Custo zero, hoje: responda as seis perguntas do capítulo 3. Algumas horas de um analista, e respondem se o problema na sua operação é grande ou pequeno.
2. Custo baixo, esta semana: escreva a linha de base da fase 0. Divergência atual, com a definição de receita declarada. É o documento que vai te permitir provar qualquer melhora futura, e sem ele, nenhum projeto de coleta é auditável.
3. Custo de decisão: escolha entre comprar e construir usando o capítulo 12. Com a linha de base na mão, essa conversa deixa de ser sobre tecnologia e passa a ser sobre onde você quer o seu time.