Rastreamento de Conversão do Lado do Servidor

Pixels de navegador perdem uma parte grande e imprevisível de conversões para prevenção de rastreamento do iOS, bloqueadores de anúncios, limites de tempo de vida de cookies e saltos entre domínios. O relatório do lado do servidor corrige o relatório, que é o que o modelo de lances da plataforma de anúncios aprende. Esta habilidade cobre o modelo, a ordem de configuração e como verificá-lo.

Quando usar

• Relatórios da plataforma de anúncios mostram menos compras do que a loja/banco de dados realmente registrou
• O CPA parece ter piorado logo após uma mudança de rastreamento, sem mudança nas vendas reais
• Configurando um novo funil que receberá tráfego pago
• Perguntado sobre CAPI / Events API / importação de conversão offline / passagem de ID de clique
• Desacordos de atribuição entre plataformas ("Facebook alega 40 vendas, Google alega 30, tivemos 45 pedidos")

O modelo, na ordem em que deve ser construído

Errar esta ordem é o motivo usual para uma "configuração do lado do servidor" ainda sub-relatar.

1. Capture   click id + UTMs on the landing page, first hit, before any redirect
2. Persist   attach them to the visitor's session, server-side
3. Carry     keep them across every funnel step, including cross-domain hops
4. Attach    write them onto the order record at purchase
5. Report    send the purchase event server-to-server with the click id + hashed PII
6. Dedupe    give the browser event and the server event the same event id
7. Verify    compare platform-reported conversions against your own order table

Pular os passos 1-4 e fazer apenas o passo 5 produz eventos de servidor sem ID de clique, que as plataformas então precisam corresponder apenas por e-mail com hash - isso é uma correspondência materialmente pior, e é a falha mais comum em uma configuração de "já fazemos CAPI".

Passo 1-2: capturar e persistir

Capture também, no mesmo primeiro hit: utm_source, utm_medium, utm_campaign, utm_content, utm_term, a URL completa de destino, referenciador, user agent e o IP do cliente como visto pelo servidor. A qualidade da correspondência da CAPI do Facebook depende de client_ip_address e client_user_agent, e eles devem ser do visitante, não do seu servidor - atrás de um proxy ou CDN, leia-os dos cabeçalhos encaminhados.

Armazene do lado do servidor, com chave para uma sessão de primeira parte. Não confie em um cookie do lado do cliente que sobreviva até o checkout: no iOS, o armazenamento gravável por script pode ser limitado a 7 dias ou menos, e um salto entre domínios o quebra completamente.

Passo 3: transportar entre etapas

• Etapas no mesmo domínio: o cookie de sessão é suficiente se a sessão for do lado do servidor.
• Etapas entre domínios (página de destino em um domínio, checkout em outro): os identificadores devem ser encaminhados explicitamente no redirecionamento, e então re-persistidos no domínio receptor. É aqui que a maioria dos funis perde silenciosamente a atribuição.
• Cadeias de redirecionamento: cada salto deve preservar a string de consulta. Um redirecionamento de rastreamento que descarta ?fbclid=... destrói a atribuição para toda essa campanha.

Passo 4: anexar ao pedido

O registro do pedido deve carregar os IDs de clique, UTMs e URL de destino. É isso que torna o resto possível: transforma a atribuição em um join de banco de dados em vez de uma suposição do navegador, sobrevive a repetições e backfills, e permite reconciliar os números da plataforma contra a realidade.

Passo 5: relatar de servidor para servidor

Envie com o evento: nome do evento, hora do evento, ID do evento (para deduplicação), valor do pedido + moeda, o ID do clique e identificadores de cliente com hash (e-mail, telefone) usando a normalização exigida pela plataforma - minúsculas, sem espaços extras, SHA-256 e E.164 para números de telefone. Errar a normalização degrada silenciosamente a taxa de correspondência sem nenhum erro.

Envie de uma fila com retentativas, não inline na solicitação de checkout. Um pagamento nunca deve falhar porque a API de uma plataforma de anúncios está lenta, e um evento perdido deve ser retentado em vez de perdido.

Passo 6: deduplicar

…