- O rastreamento server-side envia eventos de conversão, como compras, de um servidor para a API da plataforma de anúncios, em vez de apenas de um pixel no navegador.
- Quando a compra é enviada a partir dos dados de pedido da sua loja, bloqueadores de anúncios e uma página de agradecimento que nunca carrega deixam de causar vendas perdidas.
- O navegador ainda é necessário para salvar o ID de clique na chegada, e o pixel pode rodar ao lado do servidor com o mesmo event_id, para que cada compra conte uma só vez.
- O tagging server-side, como um contêiner de servidor do Google Tag Manager, ainda parte de eventos do navegador, então não consegue recuperar compras que o navegador nunca enviou.
- O rastreamento server-side não é um jeito de contornar o consentimento: as regras de privacidade valem para os dados qualquer que seja o caminho que eles percorram.
Rastreamento server-side significa que os eventos de conversão, como uma compra, são enviados às plataformas de anúncios por um servidor, em vez de apenas por um script no navegador do comprador. Em uma loja online, o servidor envia cada pedido ao Meta, ao TikTok ou ao Google por meio das APIs deles, então a venda é informada mesmo quando o pixel do navegador está bloqueado ou nunca carrega.
Este guia explica a diferença entre um pixel do navegador e o rastreamento server-side, acompanha os dados do clique no anúncio até a plataforma de anúncios e mostra o que um evento do servidor contém. Ele também aborda deduplicação, tagging server-side, consentimento e como saber se a sua loja precisa disso. Para a configuração no Shopify em si, leia rastreamento server-side no Shopify.
Pixel do navegador vs rastreamento server-side
Um pixel do navegador é um trecho de JavaScript da plataforma de anúncios. Ele roda nas suas páginas e envia eventos do dispositivo do comprador direto para a plataforma: uma visualização de página, um item adicionado ao carrinho, uma compra na página de agradecimento. Ele só funciona quando o script carrega, roda e chega à plataforma antes de o comprador sair da página.
O rastreamento server-side transfere o envio para um servidor. O evento pode partir de dados que a sua loja já tem, como um pedido pago, e o servidor o envia para a API da plataforma. O Meta chama essa API de Conversions API e o TikTok a chama de Events API. O Google Ads usa conversões otimizadas, que adicionam dados de clientes em hash a uma conversão.
- Roda no navegador do comprador
- Envia eventos direto para a plataforma de anúncios
- Define e lê cookies first-party, como o _fbp do Meta
- Não envia nada quando o script é bloqueado ou a página não carrega
- Roda em um servidor que você ou um prestador de serviço controla
- Envia eventos para a API da plataforma
- Pode partir do registro do pedido na sua loja
- Não depende de a página de agradecimento carregar
Usar os dois dá à plataforma os dados mais completos. O evento do navegador acrescenta cookies e contexto da página. O evento do servidor chega mesmo quando o navegador falha. Um ID de evento compartilhado garante que a plataforma conte cada compra uma única vez.
Como funciona o rastreamento server-side?
O rastreamento server-side de uma loja online tem duas metades. A primeira acontece no navegador: quando um comprador chega de um anúncio, um script salva o ID de clique da URL. A segunda acontece no servidor: quando o pedido é pago, o servidor liga esse ID de clique ao pedido e envia a compra.
Capturando o clique
As plataformas de anúncios adicionam um ID de clique à URL de entrada: fbclid para o Meta, ttclid para o TikTok, gclid para o Google Ads e msclkid para o Microsoft Ads. O ID de clique é o vínculo mais forte entre uma venda e o anúncio que a causou, por isso precisa ser salvo na primeira visualização de página. Os parâmetros UTM acrescentam os nomes da campanha, do conjunto de anúncios e do anúncio em um formato que você controla.
Associando o pedido
O servidor então precisa saber qual visitante fez o pedido. A ligação mais confiável é um valor que viaja com o carrinho até o pedido, como um ID de visitante salvo no carrinho. Os outros métodos são mais fracos: um endereço de e-mail que o visitante informou antes no site, ou o mesmo endereço IP e navegador vistos pouco antes do pedido. Cada plataforma de loja online oferece opções diferentes. Nosso guia para outras lojas online lista os métodos que o ROASaurus usa em cada plataforma.
Envio do evento
Por fim, o servidor envia a compra para a API de cada plataforma. O evento inclui o valor do pedido, o ID de clique e os dados do cliente que ajudam a plataforma a encontrar a pessoa que clicou. Se uma plataforma está fora do ar ou devolve um erro, uma boa configuração tenta de novo mais tarde, para que a compra não se perca.
O que um evento do servidor contém?
Cada plataforma tem os próprios nomes de campos, mas um evento de compra carrega os mesmos tipos de dados em qualquer lugar. Aqui está um exemplo resumido para a Conversions API do Meta:
{
"data": [{
"event_name": "Purchase",
"event_time": 1793009700,
"event_id": "order-1042",
"action_source": "website",
"event_source_url": "https://yourstore.com/checkout/thank-you",
"user_data": {
"em": ["8c87b489ce35cf2e2f39f80e282cb2e804932a56a213983eeeb428407d43b52d"],
"ph": ["6d420c869d4eb97fe7de4576c9d04bb34d1a5788e0b3a657f61d7be020d8ead0"],
"client_ip_address": "203.0.113.24",
"client_user_agent": "Mozilla/5.0 (iPhone; CPU iPhone OS 18_6 like Mac OS X) ...",
"fbc": "fb.1.1792832531000.IwAR2xExampleClickId",
"fbp": "fb.1.1792832529000.1234567890"
},
"custom_data": { "currency": "USD", "value": 84.00 }
}]
}| Campo | O que é | Com hash? |
|---|---|---|
| Nome e hora do evento | Purchase, e quando o pedido foi feito | Não |
| Valor e moeda | O valor do pedido que a plataforma usa para o ROAS e para lances baseados em valor | Não |
event_id | Um ID único por evento, o mesmo no navegador e no servidor, para a deduplicação | Não |
| E-mail, telefone, nome, endereço | Dados do cliente vindos do pedido, normalizados e com hash SHA-256 | Sim |
| ID de clique (fbc, ttclid, gclid) | O ID do clique no anúncio, salvo quando o comprador chegou | Não |
| Endereço IP e user agent | Ajudam a plataforma a associar o evento a um dispositivo | Não |
O hash transforma um endereço de e-mail em uma sequência fixa de caracteres. O mesmo endereço sempre gera a mesma sequência, mas a sequência não revela o endereço. A plataforma usa os valores com hash apenas para procurar uma correspondência entre os próprios usuários. É assim que uma compra pode ser associada à pessoa que viu ou clicou no anúncio, mesmo quando o navegador dessa pessoa bloqueou o pixel.
Como funciona a deduplicação?
Quando o pixel e o servidor enviam a mesma compra, a plataforma precisa contá-la uma só vez. As duas cópias têm o mesmo nome de evento e o mesmo ID de evento, por exemplo order-1042. O Meta compara o par e mantém uma cópia, desde que a segunda chegue em até 48 horas depois da primeira.
Purchase event_id=order-1042 browserRecebido do pixelPurchase event_id=order-1042 serverMesmo nome e ID: contado uma vezPurchase event_id=order-1043 serverO pixel foi bloqueado: a cópia do servidor é a únicaPurchase event_id=1044 serverO navegador enviou order-1044: os IDs são diferentes, então conta duas vezesA maior parte da contagem em duplicidade vem de dois remetentes que não compartilham IDs. Um caso típico é o app de loja da própria plataforma e uma ferramenta de rastreamento separada que enviam compras, cada um com os seus IDs. Nosso artigo de ajuda sobre como evitar a contagem em duplicidade lista as causas e correções mais comuns.
Tagging server-side vs envio a partir dos dados do pedido
O termo rastreamento server-side é usado para duas configurações diferentes. As duas enviam eventos de um servidor, mas começam em lugares diferentes.
Tagging server-side, como os contêineres de servidor do Google Tag Manager
Com o tagging server-side, o navegador envia os eventos para o seu próprio servidor, em vez de para cada fornecedor. O contêiner de servidor do Google Tag Manager é um exemplo conhecido. Ele roda no seu próprio projeto do Google Cloud ou em outro ambiente que você escolher. Ele recebe as requisições do navegador, e as suas tags repassam os dados ao Google Analytics, ao Meta e a outros fornecedores. Você decide quais dados vão para onde, e o servidor pode rodar em um subdomínio do seu site.
Os eventos ainda começam no navegador. Se a tag no navegador é bloqueada ou a página de agradecimento nunca carrega, o contêiner de servidor não tem nada para repassar. Além disso, você mesmo opera, paga e atualiza o servidor.
Envio a partir dos dados do pedido
A segunda abordagem faz a compra partir do registro do pedido na sua loja. A loja informa o pedido pago ao servidor por um webhook ou uma API, e o servidor o envia a todas as plataformas conectadas. O navegador só é necessário antes, para salvar o ID de clique quando o comprador chega.
| Tagging server-side | Envio a partir dos dados do pedido | |
|---|---|---|
| Onde a compra começa | Uma tag no navegador | O pedido pago na sua loja |
| Página de agradecimento fechada antes da hora | Compra perdida | Compra enviada |
| Tag bloqueada no navegador | Compra perdida, a menos que o endpoint first-party passe | Compra enviada |
| Pagamento na entrega e páginas de pagamento externas | Depende da página de agradecimento | Enviado quando o pedido é criado ou pago |
| Eventos de navegação (visualizações de página, adições ao carrinho) | Sim | Precisa de um coletor separado no navegador |
| Quem opera o servidor | Você: hospedagem e atualizações | Você ou um prestador de serviço |
As duas abordagens podem ser combinadas. Muitas lojas coletam visualizações de página e eventos de adição ao carrinho no navegador e enviam a compra a partir dos dados do pedido. A compra é o evento que as plataformas de anúncios usam para informar o ROAS e otimizar os lances, por isso é o que mais precisa estar completo.
O que o rastreamento server-side resolve e o que ele não resolve?
- Compras perdidas porque um bloqueador de anúncios barrou o pixel
- Compras perdidas porque a página de agradecimento não carregou
- Compras de formas de pagamento que terminam fora do seu site
- Correspondência fraca, ao adicionar dados de clientes em hash a cada evento
- Consentimento: um visitante que recusou continua sendo um visitante que recusou
- Janelas e modelos de atribuição diferentes em cada plataforma
- Remetentes duplicados que usam IDs de evento diferentes
- IDs de clique que nunca foram salvos na chegada
O consentimento continua valendo
O rastreamento server-side é uma forma de entregar dados, não uma forma de contornar as regras de privacidade. Onde a lei exige consentimento para cookies de marketing ou rastreamento, essa exigência cobre os dados que você coleta, qualquer que seja o caminho até a plataforma. Mover um rastreador para o seu servidor não muda aquilo com que o visitante concordou.
A atribuição continua específica de cada plataforma
Cada plataforma ainda credita as compras com as próprias janelas e regras. Os eventos de servidor dão dados melhores a todas as plataformas, mas os totais de Meta, TikTok e Google ainda podem somar mais do que a receita da sua loja. Para comparar os canais com um único conjunto de regras, use um só modelo de atribuição para todos eles, como os modelos da atribuição do ROASaurus.
A sua loja precisa de rastreamento server-side?
Uma loja que gasta um orçamento relevante em anúncios pagos em redes sociais ou de busca costuma se beneficiar. O caso é mais forte quando vários destes pontos são verdadeiros:
- A plataforma de anúncios recebe claramente menos eventos de compra do que a sua loja tem de pedidos na web. Nosso guia sobre bloqueadores de anúncios e rastreamento mostra como medir essa diferença.
- Muitos dos seus visitantes usam o Safari no iPhone ou no Mac, onde os cookies definidos por scripts duram no máximo 7 dias. Veja Safari ITP e rastreamento de anúncios.
- Os compradores costumam comprar dias depois do primeiro clique no anúncio.
- O pagamento termina fora do seu site, ou os pedidos são pagos depois, como no pagamento na entrega ou na transferência bancária.
- Você otimiza campanhas para compras ou valor de compra, então a plataforma precisa de todas as vendas para aprender.
Veja como uma diferença muda as decisões na prática. Uma loja de exemplo tem 1,000 pedidos na web em um mês. O pixel do Meta dela informou 820 eventos Purchase, então 18% dos pedidos nunca chegaram ao Meta pelo navegador.
O ROAS de equilíbrio da loja é 2.5, e o Ads Manager mostra um ROAS de 2.3 nos dados do pixel. Com esses números, as campanhas dão prejuízo. Se os pedidos vindos de anúncios foram perdidos na mesma proporção de 18%, o ROAS real é de cerca de 2.3 ÷ 0.82 = 2.8, acima do equilíbrio. Essa é uma estimativa no limite superior, porque nem todo pedido ausente veio de um anúncio. Ainda assim, mostra como uma diferença de rastreamento pode fazer uma campanha lucrativa parecer um prejuízo.
O rastreamento server-side importa menos para uma loja que não anuncia ou que gasta muito pouco com anúncios.
Como o ROASaurus envia eventos server-side
O ROASaurus captura 19 IDs de clique e seis campos UTM na chegada e os salva com um ID de visitante first-party. Ele envia cada compra a partir dos pedidos pagos da sua loja ao Meta, TikTok, Snapchat, Pinterest, Reddit, X, Microsoft Ads, Taboola, LinkedIn, OpenAI Ads, Spotify, AppLovin, Criteo, AdRoll e Outbrain. No Shopify, as conversões do Google Ads são enviadas a partir do checkout do Shopify. Os pixels do navegador podem rodar ao lado dos eventos do servidor com o mesmo ID de evento, e o Meta, o TikTok, o Snapchat, o Pinterest, o Reddit, o OpenAI Ads, o AppLovin e o Spotify os deduplicam. Cada envio e a resposta da plataforma aparecem no Event log.
Saiba mais na página de rastreamento server-side, ou encontre a sua loja online na página de integrações.
Fontes
- Meta for Developers: Conversions API
- Meta for Developers: Handling Duplicate Pixel and Conversions API Events
- Meta for Developers: Customer Information Parameters
- Google for Developers: An introduction to server-side tagging
- Google Ads Help: About enhanced conversions
No ROASaurus
- Rastreamento server-side no ROASaurus
- Consentimento e privacidade
- Como evitar a contagem em duplicidade