- O tracking server-side envia eventos de conversão, como as compras, a partir de um servidor para a API da plataforma de anúncios, em vez de os enviar apenas a partir de um pixel no navegador.
- Quando a compra é enviada a partir dos dados da encomenda da sua loja, os bloqueadores de anúncios e uma página de agradecimento que nunca carrega deixam de causar vendas perdidas.
- O navegador continua a ser necessário para guardar o ID de clique na página de entrada, e o pixel pode funcionar a par do servidor com o mesmo event_id, para que cada compra conte uma só vez.
- O tagging server-side, como um contentor de servidor do Google Tag Manager, continua a partir de eventos do navegador, por isso não consegue recuperar compras que o navegador nunca enviou.
- O tracking server-side não é uma forma de contornar o consentimento: as regras de privacidade aplicam-se aos dados qualquer que seja o caminho que seguem.
O tracking server-side significa que os eventos de conversão, como uma compra, são enviados para as plataformas de anúncios a partir de um servidor, e não apenas a partir de um script no navegador do comprador. Numa loja online, o servidor envia cada encomenda para a Meta, o TikTok ou o Google através das respetivas APIs, por isso a venda é reportada mesmo quando o pixel do navegador está bloqueado ou nunca carrega.
Este guia explica a diferença entre um pixel do navegador e o tracking server-side, segue os dados desde o clique no anúncio até à plataforma de anúncios e mostra o que contém um evento do servidor. Aborda também a eliminação de duplicados, o tagging server-side, o consentimento e como perceber se a sua loja precisa disto. Para a configuração no Shopify em si, leia tracking server-side no Shopify.
Pixel do navegador vs tracking server-side
Um pixel do navegador é um pedaço de JavaScript da plataforma de anúncios. Corre nas suas páginas e envia eventos do dispositivo do comprador diretamente para a plataforma: uma visualização de página, um adicionar ao carrinho, uma compra na página de agradecimento. Só funciona se o script carregar, correr e chegar à plataforma antes de o comprador sair da página.
O tracking server-side passa o envio para um servidor. O evento pode partir de dados que a sua loja já tem, como uma encomenda paga, e o servidor envia-o para a API da plataforma. A Meta chama a esta API Conversions API e o TikTok chama-lhe Events API. O Google Ads usa as conversões avançadas, que acrescentam dados de clientes com hash a uma conversão.
- Corre no navegador do comprador
- Envia eventos diretamente para a plataforma de anúncios
- Define e lê cookies first-party, como o _fbp da Meta
- Não envia nada quando o script é bloqueado ou a página não carrega
- Corre num servidor controlado por si ou por um prestador de serviços
- Envia eventos para a API da plataforma
- Pode partir do registo da encomenda na sua loja
- Não depende de a página de agradecimento carregar
Usar ambos 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 partilhado garante que a plataforma conta cada compra uma só vez.
Como funciona o tracking server-side?
O tracking server-side de uma loja online tem duas metades. A primeira acontece no navegador: quando um comprador chega através de um anúncio, um script guarda o ID de clique do URL. A segunda acontece no servidor: quando a encomenda é paga, o servidor associa esse ID de clique à encomenda e envia a compra.
Captar o clique
As plataformas de anúncios acrescentam um ID de clique ao URL da página de entrada: fbclid para a Meta, ttclid para o TikTok, gclid para o Google Ads e msclkid para o Microsoft Ads. O ID de clique é a ligação mais forte entre uma venda e o anúncio que a provocou, por isso tem de ser guardado 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 num formato controlado por si.
Associar a encomenda
O servidor precisa então de saber que visitante fez a encomenda. A ligação mais fiável é um valor que viaja com o carrinho até à encomenda, como um ID de visitante guardado no carrinho. Os outros métodos são mais fracos: um endereço de email que o visitante introduziu antes no site, ou o mesmo endereço IP e navegador vistos pouco antes da encomenda. Cada plataforma de loja online oferece opções diferentes. O nosso guia para outras lojas online lista os métodos que a 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 da encomenda, o ID de clique e dados do cliente que ajudam a plataforma a encontrar a pessoa que clicou. Se uma plataforma estiver em baixo ou devolver um erro, uma boa configuração tenta de novo mais tarde, para que a compra não se perca.
O que contém um evento do servidor?
Cada plataforma tem os seus próprios nomes de campos, mas um evento de compra traz os mesmos tipos de dados em todo o lado. Eis um exemplo resumido para a Conversions API da 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 a encomenda foi feita | Não |
| Valor e moeda | O valor da encomenda que a plataforma usa para o ROAS e para o bidding baseado em valor | Não |
event_id | Um ID único por evento, igual no navegador e no servidor, para a eliminação de duplicados | Não |
| Email, telefone, nome, morada | Dados do cliente a partir da encomenda, normalizados e com hash SHA-256 | Sim |
| ID de clique (fbc, ttclid, gclid) | O ID do clique no anúncio, guardado 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 email numa cadeia fixa de carateres. O mesmo endereço dá sempre a mesma cadeia, mas a cadeia não revela o endereço. A plataforma usa os valores com hash apenas para procurar uma correspondência entre os seus próprios utilizadores. É 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 eliminação de duplicados?
Quando o pixel e o servidor enviam a mesma compra, a plataforma tem de a contar uma só vez. Ambas as cópias trazem o mesmo nome de evento e o mesmo ID de evento, por exemplo order-1042. A Meta compara o par e mantém uma cópia, desde que a segunda chegue nas 48 horas seguintes à 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 diferem, por isso conta duas vezesA maior parte das contagens em duplicado vem de dois emissores que não partilham IDs. Um caso típico é a app de loja da própria plataforma e uma ferramenta de tracking separada, que enviam ambas compras com os seus próprios IDs. O nosso artigo de ajuda sobre como evitar a contagem em duplicado lista as causas habituais e as soluções.
Tagging server-side vs envio a partir dos dados da encomenda
O termo tracking server-side é usado para duas configurações diferentes. Ambas enviam eventos a partir de um servidor, mas começam em sítios diferentes.
Tagging server-side, como os contentores de servidor do Google Tag Manager
Com o tagging server-side, o navegador envia os seus eventos para o seu próprio servidor em vez de os enviar a cada fornecedor. O contentor de servidor do Google Tag Manager é um exemplo conhecido. Corre no seu próprio projeto do Google Cloud ou noutro ambiente à sua escolha. Recebe pedidos do navegador e as suas tags reencaminham os dados para o Google Analytics, a Meta e outros fornecedores. Decide que dados vão para onde, e o servidor pode correr num subdomínio do seu site.
Os eventos continuam a começar no navegador. Se a tag no navegador for bloqueada, ou se a página de agradecimento nunca carregar, o contentor de servidor não tem nada para reencaminhar. Além disso, tem de gerir, pagar e atualizar o servidor por sua conta.
Envio a partir dos dados da encomenda
A segunda abordagem faz a compra partir do registo da encomenda na sua loja. A loja comunica a encomenda paga ao servidor através de um webhook ou de uma API, e o servidor envia-a para todas as plataformas ligadas. O navegador só é necessário antes, para guardar o ID de clique quando o comprador chega.
| Tagging server-side | Envio a partir dos dados da encomenda | |
|---|---|---|
| Onde a compra começa | Uma tag no navegador | A encomenda paga na sua loja |
| Página de agradecimento fechada cedo demais | Compra perdida | Compra enviada |
| Tag bloqueada no navegador | Compra perdida, a menos que o endpoint first-party passe | Compra enviada |
| Pagamento contra reembolso e páginas de pagamento externas | Depende da página de agradecimento | Enviada quando a encomenda é criada ou paga |
| Eventos de navegação (visualizações de página, adicionar ao carrinho) | Sim | Precisa de um coletor separado no navegador |
| Quem gere o servidor | A sua equipa: alojamento e atualizações | A sua equipa ou um prestador de serviços |
As duas abordagens podem ser combinadas. Muitas lojas recolhem as visualizações de página e os eventos de adicionar ao carrinho no navegador e enviam a compra a partir dos dados da encomenda. A compra é o evento que as plataformas de anúncios usam para reportar o ROAS e otimizar o bidding, por isso é o que mais precisa de estar completo.
O que o tracking server-side resolve e o que não resolve?
- Compras perdidas porque um bloqueador de anúncios travou o pixel
- Compras perdidas porque a página de agradecimento não carregou
- Compras de métodos de pagamento que terminam fora do seu site
- Correspondência fraca, ao acrescentar dados de clientes com hash a cada evento
- Consentimento: um visitante que recusou continua a ser um visitante que recusou
- Janelas e modelos de atribuição diferentes por plataforma
- Emissores duplicados que usam IDs de evento diferentes
- IDs de clique que nunca foram guardados na página de entrada
O consentimento continua a aplicar-se
O tracking server-side é uma forma de entregar dados, não uma forma de contornar as regras de privacidade. Quando a lei exige consentimento para cookies de marketing ou para tracking, essa exigência abrange os dados que recolhe, seja qual for o caminho que seguem até à plataforma. Passar um rastreador para o seu servidor não muda aquilo com que o visitante concordou.
A atribuição continua a ser específica de cada plataforma
Cada plataforma continua a atribuir o mérito das compras com as suas próprias janelas e regras. Os eventos do servidor dão a cada plataforma dados melhores, mas os totais da Meta, do TikTok e do Google podem continuar a somar mais do que a receita da sua loja. Para comparar canais com um único conjunto de regras, use um só modelo de atribuição em todos eles, como os modelos da atribuição da ROASaurus.
A sua loja precisa de tracking server-side?
Uma loja que investe um orçamento significativo em anúncios pagos nas redes sociais ou na pesquisa costuma 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 as encomendas web da sua loja. O nosso guia sobre bloqueadores de anúncios e tracking mostra como medir esta 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 tracking de anúncios.
- Os compradores compram muitas vezes dias depois do primeiro clique no anúncio.
- O pagamento termina fora do seu site, ou as encomendas são pagas mais tarde, como no pagamento contra reembolso ou na transferência bancária.
- Otimiza as campanhas para compras ou para valor de compra, por isso a plataforma precisa de todas as vendas para aprender.
Eis como uma diferença muda as decisões na prática. Uma loja de exemplo tem 1,000 encomendas web num mês. O pixel da Meta reportou 820 eventos Purchase, por isso 18% das encomendas nunca chegaram à Meta a partir do navegador.
O ROAS de break-even da loja é 2.5, e o Ads Manager mostra um ROAS de 2.3 com os dados do pixel. Com estes números, as campanhas dão prejuízo. Se as encomendas vindas de anúncios fossem perdidas à mesma taxa de 18%, o ROAS real é de cerca de 2.3 ÷ 0.82 = 2.8, acima do break-even. É uma estimativa no limite superior, porque nem todas as encomendas em falta vieram de um anúncio. Mesmo assim, mostra como uma diferença no tracking pode fazer uma campanha rentável parecer um prejuízo.
O tracking server-side importa menos para uma loja que não anuncia, ou que investe muito pouco em anúncios.
Como a ROASaurus envia eventos server-side
A ROASaurus capta 19 IDs de clique e seis campos UTM na página de entrada e guarda-os com um ID de visitante first-party. Envia cada compra das encomendas pagas da sua loja para 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 funcionar a par dos eventos do servidor com o mesmo ID de evento, e a Meta, o TikTok, o Snapchat, o Pinterest, o Reddit, o OpenAI Ads, a AppLovin e o Spotify eliminam os duplicados. Cada entrega e a resposta da plataforma estão listadas no Event log.
Saiba mais na página de tracking 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