Atribuicao first-party: segue os visitantes sem cookies de terceiros

Lanças uma campanha, vês 400 visitantes no Google Analytics, 12 inscrições… e és incapaz de dizer quais vêm de que origem. Bem-vindo à atribuição pós-cookies de terceiros, onde 30 a 50 % do teu tráfego se tornou invisível. A boa notícia: não precisas de GA nem de pixels de terceiros. Um pixel servido pelo teu próprio domínio basta para reconstruir a cadeia visita → inscrição → receita, e sobrevive a tudo o que parte os trackers clássicos.

Porque é que as soluções clássicas se desmoronam

Os pixels de terceiros (Meta Pixel, o `gtag.js` da Google, Hotjar…) põem um cookie ou leem um identificador a partir de um domínio diferente do teu. É exatamente o que os navegadores decidiram matar. Três forças convergem e já as estás a sofrer:

• Safari / ITP: um cookie posto por JavaScript (`document.cookie`) está limitado a 7 dias, e a 24 h se o visitante chega através de um link com parâmetros de tracking. A tua atribuição a 30 dias está morta antes de começar.
• Cookies de terceiros bloqueados: o Safari e o Firefox bloqueiam-nos por omissão há anos. O Chrome recuou na remoção total em 2024, mas generalizou um opt-out que esvazia o reservatório na mesma.
• Consentimento estrito (RGPD): sem banner aceite, o GA e os pixels de marketing não devem carregar. Resultado: um buraco enorme nos teus dados, e um buraco que não é aleatório (as recusas correlacionam com certos perfis).

O ponto comum destas três ruturas: visam o terceiro. Se o identificador vem do teu domínio e só te serve a ti, a maioria destas regras não se aplica da mesma forma.

O princípio: um pixel first-party + um visitor_id anónimo

A ideia cabe em três peças. Serves um endpoint de recolha no teu próprio domínio (idealmente um subdomínio como `t.tuaapp.com`, não um domínio de tracking externo). Na primeira visita, geras um `visitor_id` aleatório e guarda-lo num cookie first-party, HttpOnly, Secure. Em cada página vista, o navegador devolve esse cookie ao teu servidor, que regista o evento. O detalhe que muda tudo: o cookie é posto por uma resposta HTTP `Set-Cookie` do lado do servidor, não por `document.cookie` em JavaScript. É essa nuance que contorna o limite de 7 dias do ITP — o limite visa os cookies postos em JS, não os postos pelo servidor em first-party. E `HttpOnly` torna-os ilegíveis por qualquer script, logo inexploráveis para roubo via XSS.

# Réponse de ton endpoint /t/collect servi sur t.tonapp.com
HTTP/1.1 204 No Content
Set-Cookie: vid=8f3c1a9e-...; Max-Age=63072000; Path=/;
  Domain=.tonapp.com; HttpOnly; Secure; SameSite=Lax

// pixel.js côté client (~10 lignes) :
// fetch("https://t.tonapp.com/t/collect", {
//   method: "POST", credentials: "include", keepalive: true,
//   headers: { "Content-Type": "application/json" },
//   body: JSON.stringify({ path: location.pathname,
//     ref: document.referrer, utm: location.search, ts: Date.now() }) });

A fusão: do visitor_id anónimo à identidade provada

Enquanto o visitante é anónimo, acumulas eventos ligados a um `visitor_id` opaco. A magia acontece no momento da inscrição: o utilizador prova o seu email (link de confirmação ou OTP), e fazes o stitching — ligas o `visitor_id` do cookie à conta acabada de criar. Nesse instante, toda a história anónima de antes (primeira visita, origem, páginas vistas) liga-se retroativamente a uma identidade real.

1. No momento do signup, lê o cookie `vid` do lado do servidor no mesmo pedido.
2. Escreve uma linha `identity(visitor_id, user_id, email_verified_at)` — o email provado, não apenas escrito.
3. Recola todos os eventos anónimos que levam esse `visitor_id` ao `user_id`. Obténs o percurso completo: Twitter → /pricing → /signup → email confirmado.
4. Bónus: se o mesmo email se voltar a ligar a partir de outro dispositivo, funde dois `visitor_id` sob um único `user_id`.

O que ganhas face ao Google Analytics e aos pixels de terceiros

• Atribuição de longa duração: o teu cookie de servidor pode visar 2 anos em vez de 24 h. Para um funil B2B onde a decisão demora 3 semanas, é a diferença entre atribuir uma venda e perdê-la no ruído.
• Dados completos: registas do lado do servidor, por isso os bloqueadores (uBlock, Brave) que comem o `gtag.js` não te tocam. Vês o teu tráfego real, não a versão esburacada pelas extensões.
• Junção direta com a tua receita: o `visitor_id` está na tua base de dados, ao lado das tuas tabelas `users` e `subscriptions`. Fazes um `JOIN` SQL entre uma origem e MRR real — impossível com o agregado anonimizado do GA4.
• Conformidade mais fácil de enquadrar: um identificador estritamente first-party, com finalidade de medição interna, é mais fácil de justificar do que despejar os dados para a Google e a Meta. A validar com o teu advogado, mas o âmbito é radicalmente mais nítido.
• Sem amostragem nem limiar de cardinalidade: o GA4 faz amostragem e oculta os segmentos < ~50 utilizadores. Nos teus próprios logs, cada linha existe.

As armadilhas que partem o setup em produção

• Servir o pixel a partir de um subdomínio mesmo teu: um CNAME para um domínio de tracking conhecido (do tipo `.analytics-vendor.com`) é requalificado como terceiro pelo ITP, que reimpõe o limite de 7 dias. O subdomínio deve resolver para a tua* infraestrutura.
• `SameSite=Lax` no mínimo: com `None` sem razão, reintroduzes comportamento de terceiro. `Lax` cobre o caso normal (clique para o teu site).
• Idempotência do stitching: um mesmo `visitor_id` pode chegar duas vezes (duplo envio, retry). Chave única em `(visitor_id, user_id)`.
• Apagar a PII dos logs em bruto: não registes o IP em claro eternamente. Trunca ou faz hash; guarda o IP só o suficiente para o geo/anti-fraude.
• O caso "nunca se inscreveu": 95 % dos visitantes nunca se vão fundir. É normal. Guardas o agregado anónimo para o topo do funil, a fusão só diz respeito aos convertidos.

Começa pequeno: um endpoint, um cookie `Set-Cookie` HttpOnly servido no teu subdomínio, uma tabela `events(visitor_id, path, ref, ts)` e uma tabela `identity(visitor_id, user_id)` preenchida quando o email está provado. Terás numa tarde uma atribuição que sobrevive ao Safari, aos bloqueadores e ao consentimento — e que se liga diretamente ao teu MRR. Quando estiver a funcionar, acrescenta o multi-dispositivo e a contagem das origens. O resto é SQL.