Identity Resolution e First-Party ID Graph: A Engenharia de Unificação de Dados e Grafos de Identidade para Performance

A fragmentação de identificadores de navegação reduziu a precisão da atribuição digital em campanhas de mídia paga. A solução definitiva não reside em hacks client-side, mas na construção de um First-Party ID Graph resiliente hospedado na infraestrutura proprietária da empresa.

Neste guia técnico, você aprenderá a arquitetar pipelines de resolução determinística de identidade. Exploraremos a modelagem matemática de grafos, o desacoplamento de cookies via Edge Computing e a sincronização com o Meta Conversions API (CAPI) e Google Enhanced Conversions.

O que é Identity Resolution e por que os cookies de terceiros colapsaram?

A resolução de identidade consiste em unificar múltiplos identificadores dispersos em um único perfil consolidado de cliente. Esse processo tornou-se imperativo após os navegadores bloquearem cookies de terceiros e imporem restrições estritas a cookies gravados via JavaScript.

O protocolo Apple WebKit Intelligent Tracking Prevention (ITP) exemplifica esse colapso estrutural. Scripts client-side que gravam identificadores via document.cookie sofrem limitação de tempo de vida útil para apenas 7 dias.

Se o tráfego contiver parâmetros de rastreamento de cliques como fbclid ou gclid, o ITP reduz a persistência para 24 horas. Essa degradação impede a mensuração correta de jornadas de compra longas em janelas padrão de 7 ou 28 dias.

+-------------------------------------------------------------------------+
|                  Impacto do Safari ITP no Ciclo de Vida                 |
+-------------------------------------------------------------------------+
| Cookie Client-Side (JS)   | Expiração: 1 a 7 dias   | Atribuição Perfeita? ❌ |
| CNAME Cloaking Externo    | Expiração: 7 dias       | Atribuição Perfeita? ❌ |
| Edge First-Party HttpOnly | Expiração: 365+ dias    | Atribuição Perfeita? ✔️ |
+-------------------------------------------------------------------------+

Quando um usuário pesquisa um produto no celular e converte dias depois no computador, as plataformas de anúncios enxergam duas sessões desconectadas. O resultado direto é a subnotificação de conversões e lances algorítmicos ineficientes.

Casamento determinístico versus probabilístico: como escolher o método de unificação?

O casamento determinístico utiliza chaves primárias exclusivas e verificadas para conectar identidades com certeza absoluta. O método probabilístico infere correlações estatísticas entre sessões com base em padrões de comportamento e assinaturas de rede.

Em operações de alta performance e e-commerce, o método determinístico é o padrão exigido pelas APIs de conversão. Ele opera a partir de dados fornecidos voluntariamente pelo usuário em checkouts, formulários de captura e logins.

Para garantir a integridade do casamento determinístico, cada dado primário precisa passar por higienização e normalização criptográfica estrita antes de compor o grafo.

// Exemplo de normalização de e-mail e telefone em TypeScript
import { createHash } from "node:crypto";

export function normalizeAndHashEmail(rawEmail: string): string {
  let cleaned = rawEmail.trim().toLowerCase();
  const [localPart, domain] = cleaned.split("@");
  
  if (domain === "gmail.com" || domain === "googlemail.com") {
    const strippedUser = localPart.replace(/\./g, "").split("+")[0];
    cleaned = `${strippedUser}@${domain}`;
  }
  
  return createHash("sha256").update(cleaned).digest("hex");
}

export function normalizeAndHashPhone(rawPhone: string): string {
  const digitsOnly = rawPhone.replace(/\D/g, "");
  const e164 = digitsOnly.startsWith("55") ? `+${digitsOnly}` : `+55${digitsOnly}`;
  return createHash("sha256").update(e164).digest("hex");
}

O tratamento de e-mails deve respeitar o padrão IETF RFC 5322 e telefones devem seguir a norma ITU-T E.164. O hash SHA-256 resultante preserva a privacidade do cliente enquanto permite o cruzamento exato nas plataformas de mídia.

Como modelar matematicamente um First-Party ID Graph?

Um First-Party ID Graph é estruturado matematicamente como um grafo não direcionado ponderado G = (V, E). Os vértices representam identificadores heterogêneos e as arestas registram co-ocorrências verificadas em eventos de navegação.

O conjunto de vértices V é particionado em categorias funcionais: V = V_{anon} \cup V_{user} \cup V_{email} \cup V_{phone} \cup V_{device}. Cada tipo de vértice armazena seu identificador criptografado e carimbo de criação.

As arestas E representam conexões observadas em uma mesma transação ou sessão autenticada. Cada aresta e = (u, v) carrega três atributos fundamentais:

• Peso de Confiança w(e) \in (0, 1]: arestas determinísticas possuem peso 1.0, enquanto conexões heurísticas recebem pesos inferiores.
• Timestamp de Atualização t_{last}: registra a data e hora do último evento em que ambos os identificadores foram observados juntos.
• Time-To-Live (TTL): define o tempo limite de validade da aresta antes da desconexão por inatividade.

Para consolidar os múltiplos nós em identidades individuais, aplicamos o algoritmo de Componentes Conectados (Connected Components) com Union-Find. Esse algoritmo agrupa todos os nós interligados em uma partição disjunta que define o Unified Customer ID.

-- Modelagem dbt / BigQuery de Componentes Conectados para ID Graph
WITH RECURSIVE id_graph_edges AS (
  SELECT source_node, target_node, confidence_weight, last_seen_at
  FROM analytics_raw.identity_cooccurrences
  WHERE confidence_weight >= 0.90
    AND last_seen_at >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 180 DAY)
),
connected_subgraphs AS (
  SELECT source_node AS node_id, target_node AS root_id
  FROM id_graph_edges
  UNION ALL
  SELECT e.source_node AS node_id, c.root_id
  FROM id_graph_edges e
  JOIN connected_subgraphs c ON e.target_node = c.node_id
)
SELECT node_id, MIN(root_id) AS unified_profile_id
FROM connected_subgraphs
GROUP BY node_id;

Essa modelagem permite que o Data Warehouse reconstrua todo o grafo de clientes diariamente, associando eventos anônimos passados a compras confirmadas no presente.

Como preservar cookies first-party contra o Safari ITP usando Edge Computing?

A preservação de identificadores de longo prazo exige que os cookies sejam gerados na camada HTTP de um servidor ou worker de borda no mesmo Apex Domain do site. Cookies emitidos via cabeçalho Set-Cookie com a flag HttpOnly não são limitados a 7 dias pelo Safari.

Técnicas antigas de CNAME Cloaking que apontavam subdomínios para servidores terceiros são detectadas e bloqueadas pelo mecanismo de defesa contra CNAME Cloaking do WebKit. O tráfego precisa ser processado na mesma zona DNS e bloco IP.

[Navegador Safari] 
       │ 
       ▼ (Requisição HTTPS com subdomínio próprio: api.seudominio.com.br)
[Cloudflare Edge Worker / AWS CloudFront]
       │
       ├─► 1. Verifica presença do cookie `__mvid`
       ├─► 2. Se ausente, gera UUID v4 criptográfico
       ├─► 3. Emite `Set-Cookie: __mvid=...; Max-Age=31536000; HttpOnly; Secure; SameSite=Lax`
       └─► 4. Despacha evento de tracking server-side para o CAPI Gateway

Abaixo está o código funcional de um Cloudflare Worker para interceptar eventos de telemetria, injetar o cookie primário de identidade e repassar o payload para a infraestrutura server-side:

// Cloudflare Worker: Edge Identity Resolution & First-Party Cookie Engine
export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const url = new URL(request.url);
    const cookies = request.headers.get("Cookie") || "";
    const existingId = cookies.match(/(?:^|;\s*)__mvid=([^;]+)/)?.[1];
    
    const masterId = existingId || crypto.randomUUID();
    const response = await fetch(request);
    const newResponse = new Response(response.body, response);
    
    if (!existingId) {
      newResponse.headers.append(
        "Set-Cookie",
        `__mvid=${masterId}; Domain=.${url.hostname.replace(/^[^.]+\./, "")}; Path=/; Max-Age=31536000; HttpOnly; Secure; SameSite=Lax`
      );
    }
    
    return newResponse;
  }
};

Com essa arquitetura de borda, o identificador __mvid permanece válido por 365 dias, permitindo que o ID Graph conecte todas as sessões de um mesmo dispositivo ao longo de meses.

Como sincronizar o ID Graph com o Meta CAPI e Google Enhanced Conversions?

A ativação do ID Graph consiste em enriquecer os eventos de conversão disparados para as plataformas de mídia com a totalidade dos identificadores resolvidos para aquele usuário. Esse enriquecimento maximiza a métrica de Event Match Quality (EMQ).

No ecossistema do Meta Ads, o índice EMQ varia de 0 a 10 e reflete a capacidade dos servidores da Meta de atribuir a conversão a uma conta real no Instagram ou Facebook. O envio isolado de dados anônimos atinge médias medíocres entre 4.0 e 5.5.

Quando o evento é enriquecido com os vértices resolvidos no First-Party ID Graph, o guia de pontuação de EMQ da Meta indica que a nota ultrapassa rotineiramente 8.5 / 10.

No Google Ads, o uso do Google Ads Enhanced Conversions recupera conversões que não foram registradas devido a restrições de cookies. Documentações da Google confirmam um ganho incremental de até 17% em conversões reportadas.

{
  "event_name": "Purchase",
  "event_time": 1756728000,
  "action_source": "website",
  "user_data": {
    "em": ["f660ab912ec121d1b1e928a0bb4bc61b15f5ad44d5efdc4e1c92a25e99b8e44a"],
    "ph": ["942a77f9859f77f0a82b86be0b9bfef7343e80f979854ef48ab4da867b360216"],
    "external_id": ["cust_984712"],
    "fbp": "fb.1.1756700000.1234567890",
    "fbc": "fb.1.1756700000.IwAR2X_example_click_id",
    "client_ip_address": "201.86.120.45",
    "client_user_agent": "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7)..."
  },
  "custom_data": {
    "currency": "BRL",
    "value": 1450.00
  }
}

O envio completo dos dados acima garante que os algoritmos de Value-Based Bidding recebam o sinal de receita com o menor ruído estatístico possível.

Como gerenciar privacidade, consentimento e conformidade com a LGPD?

A centralização de identificadores em um grafo de dados primários exige governança rigorosa para atender à Lei Geral de Proteção de Dados (LGPD - Lei nº 13.709/2018) e ao Marco Civil da Internet.

O tratamento de dados pessoais para publicidade direcionada apoia-se nas bases legais de legítimo interesse ou consentimento expresso. A arquitetura de dados deve obedecer às diretrizes do W3C Privacy Community Group sobre armazenamento transparente.

+-------------------------------------------------------------------------+
|                  Fluxo de Governança e Exclusão LGPD                     |
+-------------------------------------------------------------------------+
| Solicitação de Exclusão (Art. 18 LGPD)                                  |
|   │                                                                     |
|   ▼                                                                     |
| Identificação do nó `V_{user}` no Data Warehouse                       |
|   │                                                                     |
|   ├─► 1. Cascata de remoção de arestas no ID Graph                      |
|   ├─► 2. Expurgo de identificadores nos backups                         |
|   └─► 3. Sincronização de lista de supressão nas APIs de Mídia          |
+-------------------------------------------------------------------------+

As três diretrizes mandatórias para uma operação de agência de alto padrão são:

1. Pseudonimização na Origem: dados PII nunca devem trafegar em texto claro. Toda conversão de hash deve ocorrer no ambiente seguro de Edge ou backend antes de qualquer persistência.
2. Integração com Consent Mode v2: o ID Graph só pode correlacionar sessões com finalidade de anúncios se o usuário conceder permissão para as tags ad_storage e ad_user_data.
3. Mecanismo de Direito ao Esquecimento: quando o titular solicitar a exclusão de seus dados, o pipeline deve expurgar o nó correspondente e todas as suas arestas, desmantelando a árvore de correlações daquela identidade.

A construção de um First-Party ID Graph proprietário não apenas protege sua operação de marketing contra futuras mudanças de navegadores, mas estabelece o ativo mais valioso de uma empresa: o controle soberano e inteligente sobre seus próprios dados de clientes.

Próximos Passos e Implementação

Para implementar uma arquitetura de resolução de identidade e First-Party ID Graph em sua empresa:

• Auditoria de Coleta: Mapeie todos os pontos de contato autenticados (checkouts, logins, formulários) e verifique se as variáveis de e-mail e telefone estão sendo devidamente normalizadas.
• Edge Worker de Identidade: Configure um worker em seu provedor de CDN para gravar cookies de identidade HttpOnly no domínio principal.
• Estruturação do ID Graph: Desenvolva modelos de dados no dbt ou Data Warehouse para consolidar conexões determinísticas entre IDs anônimos e compras reais.
• Integração CAPI e Enhanced Conversions: Enriqueça os disparos de conversão com os hashes unificados e monitore a elevação do Event Match Quality semanalmente.

Com esse pipeline em produção, suas campanhas de mídia adquirem uma vantagem competitiva sustentável, alimentando os algoritmos de lances com máxima densidade de dados e retorno sobre o investimento.