O pixel do browser é a parte da atribuição que quebra primeiro. O Intelligent Tracking Prevention da Apple limita os cookies de terceiros e degrada o referrer; os bloqueadores de anúncios eliminam a chamada de rede do pixel antes de sair da página; o App Tracking Transparency do iOS 14.5 reduziu a qualidade do sinal da Meta no tráfego de iPhone o suficiente para que a própria Meta trate agora o pixel do browser como backup.
O rastreamento de conversões server-side é a resposta com a qual todos concordam. A implementação é o que as pessoas erram. Este artigo mostra a arquitetura como se apresenta quando um encurtador de URL é dono do click_id - o que o encurtador faz, o que o seu back-end faz, o que as plataformas de anúncios esperam no seu lado, e a forma de deduplicação que o impede de contar em dobro quando tanto eventos de browser como de servidor são disparados.
As três plataformas para as quais a maioria das equipas reencaminha: Meta CAPI, GA4 Measurement Protocol, TikTok Events API. O Mixpanel, o Klaviyo e o Pinterest aceitam a mesma forma com nomes de campos específicos do fornecedor. Vou ser específico sobre a Meta e o GA4 porque são os que impulsionam a maior parte do orçamento; os outros seguem o mesmo modelo.
Por que server-side#
A versão curta: o browser já não é uma fonte de sinal confiável. A versão mais longa vale a pena compreender porque molda a forma como configura a deduplicação.
Três coisas degradam as conversões do lado do browser:
Particionamento de cookies e limites de vida útil. O ITP do Safari particiona os cookies por site de nível superior e limita os cookies de primeira parte definidos por script a 7 dias (24 horas depois de um rastreador cross-site conhecido ser detetado). A Total Cookie Protection do Firefox faz particionamento semelhante. O Brave e o coorte de extensões de privacidade vão ainda mais longe. O fluxo de atribuição por cookie de primeira parte que funcionava em 2018 não funciona em 2026.
Bloqueadores de anúncios. O uBlock Origin, AdBlock Plus, Pi-hole, NextDNS e os bloqueadores a nível de rede incluem regras padrão para connect.facebook.net, googletagmanager.com, analytics.tiktok.com e o resto da superfície de tags de marketing. O pixel nunca dispara; a conversão nunca é registada.
iOS App Tracking Transparency e as alterações de rastreamento de hiperligações do iOS 17. O ATT reduziu a qualidade do sinal da Meta. A Link Tracking Protection do iOS 17 estendeu isso a parâmetros de consulta em navegação privada e no Mail, removendo fbclid, gclid e uma lista de outros antes de a hiperligação ser aberta.
O efeito cumulativo numa loja Shopify típica com tráfego maioritariamente iOS: 25-40% das conversões são perdidas pelos pixels do lado do browser. O número exato depende do seu mix de tráfego; as marcas de beleza e vestuário com heavy iOS ficam no extremo superior. A aritmética de receita recuperada é o que justifica o trabalho de engenharia - para uma loja a fazer €10M/ano de receita com uma lacuna de atribuição de pixel de 30%, recuperar mesmo metade dessa lacuna são €1,5M de receita atribuível reencaminhada de volta para as plataformas que a impulsionaram.
O reencaminhamento de conversões server-side fecha a maior parte da lacuna. Não fecha tudo - há conversões onde o click_id nunca foi capturado (orgânico, direto, pesquisa de marca) que nenhuma quantidade de CAPI irá recuperar - mas fecha a lacuna que veio do bloqueio no lado do browser.
A arquitetura#
O fluxo de dados tem quatro saltos: anúncio → hiperligação curta → site → reencaminhamento server-side.
Plataforma de anúncios → hiperligação curta. O destino do criativo Meta ou Google Ads é uma hiperligação curta. O utilizador clica; o handler de edge da hiperligação curta captura o evento de clique e redireciona para o URL de destino com um click_id adicionado.
Hiperligação curta → site. O URL de destino tem ?elido_click=<id> adicionado (configurável por workspace). O gestor de tags do site ou o código do tema lê-o e escreve-o num cookie de primeira parte ou, mais importante, no atributo personalizado do carrinho ou encomenda.
Site → encomenda. Quando o utilizador finaliza uma encomenda (carrinho Shopify submetido, encomenda WooCommerce criada, carrinho headless convertido), o click_id está nos atributos/metadados da encomenda. Este é o ponto de entrega durável - uma vez que o click_id está na encomenda, não está sujeito a expiração de cookies ou tempo de vida de sessão do browser.
Encomenda → reencaminhamento server-side. O webhook de encomenda paga é disparado a partir da sua plataforma de comércio. O seu back-end (ou o Elido, se lhe delegou) lê o click_id, procura as credenciais de reencaminhamento de conversão, e faz POST da conversão para cada plataforma de anúncios conectada. As plataformas recebem a conversão e creditam a campanha de origem.
O papel do encurtador é o click_id no salto 2 mais a orquestração no salto 4. O primeiro é simples; o segundo é onde a integração prova o seu valor.
Deduplicação: a coisa que ninguém menciona até à produção#
O maior incidente de produção que vejo mais frequentemente é a contagem dupla. O pixel do lado do browser ainda está na página (a equipa não o desativou porque queria fallback de browser para tráfego não-Safari), e o reencaminhamento server-side também dispara. A Meta ingere ambos os eventos. A conversão é contada em dobro, o alocador de orçamento puxa em excesso, a próxima revisão de orçamento de campanha nota "espera, por que é que o nosso ROAS reportado é 3× a receita?".
A correção é o identificador de deduplicação. A Meta CAPI aceita um event_id. O GA4 Measurement Protocol aceita um client_id e um transaction_id. O TikTok Events aceita um event_id. Se tanto o browser como o servidor enviarem o mesmo evento com o mesmo ID de dedup, a plataforma credita um e ignora o segundo.
O ID de dedup tem de ser o mesmo valor em ambos os lados. O ID da encomenda funciona para eventos de compra - tanto o pixel do lado do browser como o reencaminhamento server-side veem-no. O click_id funciona para eventos upstream (lead, add-to-cart, view-content) onde a encomenda ainda não existe.
A documentação de deduplicação da Meta apresenta a janela de correspondência: eventos recebidos nas últimas 48 horas entre si com o mesmo event_id são tratados como duplicados. A dedup baseada em client_id do GA4 é semelhante em princípio, embora mais escassa em documentação.
A regra operacional: cada conversão server-side tem de transportar o ID de dedup, e o ID de dedup tem de ser o mesmo que o pixel do lado do browser emitiu. Saltar isto é a diferença entre uma integração CAPI a funcionar e uma que infla silenciosamente os seus números reportados durante três meses até alguém notar.
Requisitos de hashing#
Tanto a Meta CAPI como o TikTok Events requerem que os identificadores de email e telefone sejam hasheados com SHA-256 antes da transmissão. O GA4 não o requer estritamente, mas aceita-o. O hashing é sobre os identificadores do cliente - em (email), ph (telefone), fn (primeiro nome), ln (apelido), ge (género), db (data de nascimento), ct (cidade), st (estado), zp (código postal), country (país) - não sobre os metadados do evento.
Dois pontos a ter em atenção. Primeiro, o formato tem de ser normalizado antes do hashing - minúsculas, sem espaços, código de país removido do telefone, traços removidos. Fazer hash de [email protected] produz um valor diferente de fazer hash de [email protected]; as plataformas esperam o segundo. A página de requisitos de parâmetros da Meta lista as regras de normalização por campo.
Segundo, o hash tem de ser hexadecimal em minúsculas sem espaços. SHA256("[email protected]") produz a3b6...; a API espera a3b6..., não A3B6... e não \xa3\xb6.... A maioria dos SDKs de linguagem devolve hexadecimal em maiúsculas por padrão; tem de colocar o resultado em minúsculas.
Se estiver a encaminhar através do endpoint POST /v1/conversions do Elido, o hashing é tratado no lado da plataforma - faz POST do email/telefone em bruto, o Elido faz a normalização e o hashing por requisito da plataforma, e reencaminha. O benefício é um conjunto de regras de normalização para o seu back-end manter em vez de três. O custo é que está a confiar no Elido com o PII em bruto no momento do reencaminhamento; o pedido é encriptado em trânsito e não é persistido no servidor, mas o modelo de confiança vale a pena compreender antes de o ligar.
Um POST Meta CAPI exemplificado#
O que a plataforma realmente quer. O endpoint é POST https://graph.facebook.com/v21.0/{pixel_id}/events. O corpo é JSON.
{
"data": [
{
"event_name": "Purchase",
"event_time": 1716480000,
"event_id": "order-acme-2026-05-23-001847",
"action_source": "website",
"event_source_url": "https://acme.example/checkout/thanks?order=001847",
"user_data": {
"em": ["a3b6...sha256 of email"],
"ph": ["c4d7...sha256 of phone"],
"client_user_agent": "Mozilla/5.0 ...",
"client_ip_address": "203.0.113.42",
"fbc": "fb.1.1716470000.AbCdEf",
"fbp": "fb.1.1716470000.987654321"
},
"custom_data": {
"currency": "EUR",
"value": 89.5,
"content_ids": ["sku-spring-jeans-32-blue"],
"content_type": "product",
"num_items": 1
}
}
],
"test_event_code": "TEST12345",
"access_token": "EAAxxxxxxx"
}
Três coisas que vale a pena notar:
O event_id é a chave de dedup. Defina-o para o seu ID de encomenda; o pixel Purchase do lado do browser define o mesmo valor. A Meta deduplica dentro da janela de correspondência de 48 horas.
fbc e fbp são os identificadores de cookie da Meta. fbc é o identificador de clique (fbclid do URL de destino, prefixado); fbp é o identificador do browser do cookie _fbp. Ambos são de primeira parte da perspetiva do seu domínio e podem ser capturados server-side depois de os ter persistido fora da página de destino. Se não os tiver, a taxa de correspondência da Meta cai; se os tiver, a taxa de correspondência é excelente.
test_event_code permite disparar eventos de teste que não contam para o relatório de produção. Ligue sempre isto primeiro; verifique nos Test Events do Events Manager antes de ativar o tráfego de produção.
O equivalente na API do Elido: POST /v1/conversions com {click_id, event_name: "Purchase", value, currency, order_id, customer: {email, phone}}. O Elido normaliza e faz hash de acordo com a especificação da Meta, procura o fbc/fbp do workspace a partir do evento de clique, e constrói o payload CAPI.
Um POST GA4 Measurement Protocol exemplificado#
O formato de transmissão do GA4 tem forma semelhante, mas os nomes dos campos diferem. Endpoint: POST https://www.google-analytics.com/mp/collect?measurement_id=G-XXX&api_secret=xxx.
{
"client_id": "click-id-as-fallback-if-no-ga4-cookie",
"user_id": "user-acme-12847",
"events": [
{
"name": "purchase",
"params": {
"transaction_id": "order-acme-2026-05-23-001847",
"value": 89.5,
"currency": "EUR",
"items": [
{
"item_id": "sku-spring-jeans-32-blue",
"item_name": "Spring Jeans 32 Blue",
"quantity": 1,
"price": 89.5
}
],
"engagement_time_msec": 1
}
}
]
}
Notas:
client_id é o valor _ga do cookie GA4, se presente; se não, o click_id é um fallback utilizável (porque o GA4 criará uma sessão contra ele).
transaction_id é a chave de dedup - defina-o para o seu ID de encomenda, o mesmo valor que o evento purchase do browser do gtag, o GA4 deduplica dentro da sua janela de sessão.
engagement_time_msec tem de estar presente e positivo para que o evento conte para atribuição; defini-lo para 1 satisfaz o requisito.
api_secret é ao nível do workspace. A documentação do GA4 MP cobre a configuração das credenciais.
Semântica de retry#
As plataformas aceitam retries; o que não pode fazer é tentar novamente cegamente. Três padrões resistem ao tempo.
Idempotência no ID de dedup. Se o event_id / transaction_id da plataforma é o ID da encomenda, e faz retry do mesmo payload, a plataforma deduplica - o segundo envio é silenciosamente ignorado. Seguro.
Backoff exponencial em 5xx. Tanto a Meta como o GA4 ocasionalmente devolvem 5xx. Tente novamente com backoff (1s, 2s, 4s, 8s até 60s, depois desista). Os retries devem preservar o mesmo event_id para que a plataforma deduplique quaisquer casos de sucesso parcial.
Não tente novamente em 4xx. Uma resposta 4xx significa que o payload está malformado ou as credenciais estão erradas. Tentar novamente não irá corrigir; o retry apenas queima o orçamento de limite de taxa. Registe, alerte, corrija o problema upstream.
Se estiver a encaminhar através do Elido, o retry/backoff é tratado - POST /v1/conversions retorna imediatamente e o fan-out para as plataformas acontece em segundo plano, com o estado de retry observável via GET /v1/conversions/{id}. Se estiver a fazer o seu próprio, a camada de fila (RabbitMQ, Kafka, AWS SQS) é onde a forma de retry vive.
Modo de teste e dry-run#
O maior erro que as equipas cometem é saltar o dry-run.
A Meta tem Test Events. Define test_event_code no payload, os eventos aparecem no painel de Test Events em segundos, verifica a forma e a deduplicação. Os eventos de produção passam pelo mesmo endpoint mas sem o test_event_code.
O GA4 tem DebugView. Define debug_mode: 1 nos parâmetros do evento, os eventos aparecem no DebugView, verifica antes de ativar o tráfego de produção.
O TikTok tem um modo de teste semelhante na interface do Events Manager.
A lista de verificação de verificação é curta. Faça uma encomenda de teste, observe o webhook de encomenda paga, observe o disparo do reencaminhamento de conversão, observe-o aterrar no painel de teste da plataforma. Confirme que o event_id corresponde ao valor do pixel do lado do browser. Confirme que o value, currency e content_ids estão corretos. Depois desative o modo de teste e observe as primeiras dez encomendas de produção.
Se saltar isto, fica a saber que a integração está quebrada três dias depois quando os relatórios estão planos. Saltar o dry-run é o modo de falha único mais comum que vejo.
Modos de falha comuns#
Click_id ausente na encomenda. O mais comum. Já abordado no cornerstone de ecommerce; a correção é canalizar o click_id através do carrinho para a encomenda.
Incompatibilidade de hash. [email protected] hasheado sem normalização produz um valor diferente de [email protected]. As plataformas rejeitam a correspondência, a conversão chega sem correspondência de identificador, e o relatório da Meta atribui-a a "unmatched". A correção são as regras de normalização na documentação de parâmetros da Meta CAPI; a resposta mais limpa é delegar o hashing ao encurtador para que as regras vivam num único lugar.
fbc não capturado. Quando o utilizador chega de um anúncio da Meta, o URL contém fbclid; a página tem de capturá-lo e persistir (tipicamente num cookie de primeira parte ou no atributo do carrinho). Sem fbc, a taxa de correspondência da Meta cai materialmente. A correção é o passo do gestor de tags na página de destino que escreve fbc num cookie de primeira parte ou no atributo do carrinho.
ID de dedup inconsistente. O pixel do lado do browser usa o ID da encomenda; o servidor usa um UUID gerado no momento do reencaminhamento. Ambos os eventos são ingeridos, nenhum é deduplicado. A correção é garantir que o reencaminhamento server-side usa o mesmo valor de event_id que o pixel do lado do browser emitiu - o ID da encomenda para compras é a resposta padrão.
Incompatibilidade de moeda. O browser envia USD (porque a configuração do gtag tem padrão USD); o servidor envia EUR (porque a encomenda está em EUR). O GA4 e a Meta tratam a moeda como parte da assinatura do evento em alguns contextos de correspondência, e as conversões chegam mas não agregam de forma limpa. A correção é obter a moeda da encomenda, não da configuração a nível de página.
Onde isto vive no data plane#
O reencaminhamento de conversões é uma peça do pipeline de atribuição mais amplo. O cornerstone para o pipeline circundante é Como rastrear campanhas UTM end-to-end sem um CDP - esse artigo cobre o modelo UTM do workspace, as substituições ao nível da campanha, a importação em massa e o passo de verificação do dry-run em detalhe. Este artigo é a análise mais aprofundada do fan-out server-side que fecha o ciclo.
Para o guia operacional, a documentação de reencaminhamento de conversões é o passo a passo. Para o detalhe arquitetural de como o Elido distribui sem exceder os limites de taxa das plataformas, o artigo sobre arquitetura de ingestão de cliques cobre o pipeline fire-and-forget.
Leia o cluster#
Artigos irmãos no cluster de features: Smart links explicados (o cornerstone), Webhooks para eventos de hiperligações (a forma de evento mais ampla), e Reencaminhar conversões para a Meta CAPI (a análise mais aprofundada específica da Meta). Para a versão orientada a persona, a solutions/marketers é a página; a página de funcionalidade de rastreamento de conversões é a superfície do produto.
Relacionados no blog#
Experimente Elido
Cole uma URL, obtenha um link curto
Sem cadastro. O link vive 30 dias. Cadastre-se para mantê-lo para sempre.
Grátis, sem necessidade de registo · 2 por dia