GTM Server Side Tagging

Entenda o tagging do lado do cliente antes do tagging do lado do servidor

Para realmente entender o tagging do lado do servidor, primeiro você precisa entender o tagging do lado do cliente.

A configuração de tagging (que vou chamar aqui de "marcação") que é executada em um ambiente do lado do cliente é chamada de marcação do lado do cliente.

O ambiente do lado do cliente representa um navegador que dispara códigos de marcação ou pixels de anúncios para se comunicar diretamente com os servidores de fornecedores terceirizados, geralmente por meio de uma solução de gerenciamento de tags (como o GTM).

É por isso que a marcação do lado do cliente também é conhecida como marcação baseada em navegador.

Exemplos de servidores de fornecedores terceirizados: servidores do Google Analytics, servidores do Google Ads, servidores do Facebook Ads etc.

A marcação no lado do cliente é a configuração mais comum para coleta de dados. No caso de marcação do lado do cliente, você executa um código JavaScript de terceiros (também conhecido como pixels) em seu site.

Quando este código JavaScript é executado, ele configura cookies de terceiros nos navegadores dos seus usuários.

Esses cookies de terceiros enviam os dados dos usuários do seu site diretamente para os servidores de fornecedores terceirizados (como Google, Facebook, LinkedIn etc.).

Portanto, ao configurar a marcação do lado do cliente para o Google Analytics, você executa o Google Analytics nos navegadores dos usuários.

Ao configurar a marcação do lado do cliente para anúncios do Google, você aciona as tags do Google Ads nos navegadores dos usuários.

Da mesma forma, ao configurar a marcação do lado do cliente para anúncios do Facebook, você aciona os pixels do Facebook nos navegadores dos usuários.

Limitações da marcação no lado do cliente

No caso da marcação no lado do cliente, os cookies de terceiros enviam os dados dos usuários do seu site diretamente para os servidores de fornecedores terceirizados (como Google, Facebook, LinkedIn etc.).

No entanto, os navegadores (como o Safari) e os bloqueadores de anúncios controlam, em última instância, o comportamento e o destino desses cookies de terceiros.

Por exemplo, eles definem regras sobre como os cookies podem ser configurados, como definir uma data máxima de expiração de 7 dias.

Os Ad Blockers (bloqueadores de anúncios) também podem controlar o comportamento de cookies de terceiros.

Eles podem impedir que o código JavaScript de terceiros seja executado no navegador do usuário.

E quando o código JavaScript não é executado, nenhum cookie de terceiros é definido e nenhum dado é enviado aos servidores terceirizados.

Ao usar a marcação do lado do cliente, você corre o risco de ficar inseguro, pois depende dos usuários do seu site e dos navegadores que utilizam.

Introdução à marcação no lado do servidor

A configuração de marcação (tagging) que é executada em um ambiente do lado do servidor é chamada de marcação do lado do servidor.

O lado do servidor (Server-side) é geralmente referido como SS.

O ambiente do lado do servidor

O ambiente do lado do servidor representa um servidor de tags que dispara códigos de tags ou pixels de anúncios para se comunicar diretamente com os servidores de fornecedores terceirizados, geralmente por meio de uma solução de gerenciamento de tags (como o GTM).

Por isso, a marcação no servidor também é conhecida como marcação servidor-para-servidor (server-to-server).

Exemplos de ambientes do lado do servidor: Google Cloud Platform, Amazon Web Services etc.

Nota: O ambiente do lado do servidor também é chamado de server environment ou server endpoint.

Como funciona a marcação do lado do servidor?

No caso da marcação do lado do servidor, você NÃO executa código JavaScript de terceiros (também conhecido como pixels) em seu site. Você não configura cookies de terceiros nos navegadores de seus usuários.

Você executa tags e pixels de marketing a partir dos seus servidores, em vez de executá-los no navegador dos usuários.

Portanto, ao configurar a marcação no servidor para o Google Analytics, você não executa mais o Google Analytics no navegador dos usuários.

Em vez disso, você executa o Google Analytics a partir do seu servidor.

Da mesma forma, ao configurar a marcação no servidor para o Google Ads, você não executa mais as tags do Google Ads nos navegadores dos usuários.

Em vez disso, você executa as tags do Google Ads a partir do seu servidor.

No entanto, há uma exceção.

Ao configurar a marcação no servidor para anúncios do Facebook, você também continua a disparar pixels do Facebook nos navegadores dos usuários.

Isso ocorre porque o Facebook recomenda o uso de marcação tanto no lado do cliente quanto no servidor para obter resultados otimizados.

Ao migrar da marcação do lado do cliente para a marcação do lado do servidor, você move seus pixels de marcação e pixels de marketing para o lado do servidor.

Exemplos de pixels de marcação: Tag Universal Analytics, tag Google Analytics 4, tag Adobe Analytics etc.

Exemplos de pixels de marketing: Pixel de anúncios do Facebook, pixel do Google Ads, pixel de anúncios do Twitter (x.com) etc.

Por que você deveria migrar para a marcação do lado do servidor?

Você provavelmente sabe que o navegador Brave bloqueia o Google Analytics e o GTM por padrão.

Um número crescente de usuários agora estão utilizando bloqueadores de anúncios que também podem bloquear o Google Analytics.

Prevenção Inteligente de Marcação (ITP) da Apple

A Prevenção Inteligente de Marcação (ITP) da Apple é um recurso de privacidade do navegador Safari da Apple. Este recurso foi projetado para melhorar a privacidade dos usuários do Safari, bloqueando cookies/marcação de terceiros que identificam e rastreiam usuários em diferentes sites.

Para piorar a situação, o Google também anunciou um plano para encerrar o suporte a cookies de terceiros em um futuro próximo.

Os navegadores continuam a restringir o acesso a um número cada vez maior de dados dos usuários.

Regulamentações de privacidade progressivamente mais rigorosas e restrições de rastreamento de dados cada vez maiores por parte dos navegadores e bloqueadores de anúncios tornaram a marcação do lado do cliente pouco confiável.

E a situação só tende a piorar.

Essas restrições de marcação criam lacunas significativas de dados nos funis de conversão, dificultando muito a compreensão das jornadas de compra dos clientes e retorno sobre o investimento das campanhas de marketing.

Portanto, é justo concluir que:

A marcação baseada em navegador e os cookies (especialmente cookies de terceiros) não durarão muito, e a marcação do lado do servidor é o futuro.

Conversão baseada em API

Uma das maiores vantagens de usar a marcação no servidor é a possibilidade de implementar a marcação de conversões baseada em API, que consegue rastrear conversões com muito mais precisão do que a marcação tradicional baseada nos dados do navegador.

Exemplos de marcação de conversões baseada em API: API de conversão do Google Ads, API de conversão do Facebook Ads e etc.

A marcação de conversões baseada em API é menos afetada por restrições de marcação em navegadores e bloqueadores de anúncios do que a marcação tradicional baseada em navegador.

Assim, ao usar a marcação de conversões baseada em API, você pode fornecer mais dados de conversão aos seus pixels de anúncios.

Isso, por sua vez, pode ajudar a melhorar o desempenho das suas campanhas de marketing.

O Facebook recomenda o uso da API de Conversão (CAPI) juntamente com o seu pixel do Facebook

"The Conversions API helps improve performance by sending data you already share with your pixel through an API connection, which is less impacted by ad blockers and browser connectivity issues. You can see how people interact with your business in ways the pixel alone can't measure, like when purchases are initiated online but completed in a physical store." - Facebook

Você pode mitigar alguns dos efeitos negativos das atualizações do iOS 14.5+ da Apple nos anúncios do Facebook usando CAPI.

No entanto, não é possível usar CAPI sem a marcação no servidor.

O Facebook prioriza a API de Conversão em relação ao Pixel do Facebook

Isso significa que os eventos baseados em servidor têm prioridade para alimentar o seu pixel de anúncios do Facebook, e os eventos baseados em navegador são usados somente quando não houver eventos correspondentes disponíveis no servidor.

Se você deseja veicular anúncios lucrativos no futuro próximo, precisa migrar para a marcação no servidor. Não há outra alternativa.

Transição de third-party para first-party

Para entender o conceito de coleta de dados primários (first-party) e de terceiros (third-party), você primeiro precisa entender o conceito de cookies primários e de terceiros.

O que são cookies primários?

Cookies primários são cookies emitidos pelo site que você está visitando, e somente esse site pode lê-los.

O que são dados primários?

Os dados coletados por cookies primários são chamados de "first-party data".

Se o seu site coleta dados de usuários sem usar cookies (talvez por meio de protocolo de medição ou marcação do lado do servidor), esses dados também são chamados de "first-party data".

O que são cookies de terceiros?

Cookies de terceiros são cookies emitidos por sites diferentes do site que você está visitando. Por exemplo, os cookies emitidos pelo Facebook ou pelo Google Ads nos navegadores dos seus usuários são cookies de terceiros.

O que são dados de terceiros?

Os dados coletados por cookies de terceiros são chamados de "third party data". Os dados coletados por fornecedores terceirizados também são chamados de "third party data".

Uma das maiores vantagens de usar o Tagging do lado do servidor é que você pode coletar dados de terceiros no contexto primário.

Você pode usar cookies de terceiros como se fossem dados primários ao usar o Tagging do lado do servidor. Você pode implantar todas as suas configurações de Tagging no contexto primário. Por exemplo:

Em vez de enviar os dados dos seus usuários diretamente para o servidor de anúncios do Facebook por meio do pixel do Facebook no seu site, você pode enviar os mesmos dados para o seu servidor.

Seu servidor de marcação processaria os dados e os enviaria para o servidor de anúncios do Facebook.

Assim, você pode contornar as restrições de marcação em cookies de terceiros, como:

• Estender o período de expiração do cookie de 7 para 30 dias.
• Enviar dados de usuários para fornecedores terceirizados sem usar cookies de terceiros.

Principais vantagens da marcação via servidor

A seguir, as principais vantagens da marcação de dados no servidor:

1. Você pode implementar a marcação de conversões baseada em API, que rastreia conversões com muito mais precisão do que a marcação tradicional baseada em navegador.
2. Você pode coletar dados de terceiros como se fossem dados primários.
3. Ao contrário da marcação do lado do cliente, os navegadores ou bloqueadores de anúncios não podem bloquear a marcação do lado do servidor.
4. Por meio da marcação do lado do servidor, você pode preencher as lacunas de dados em seus fluxos de conversão criadas pela marcação do lado do cliente.
5. Ao usar a marcação do lado do servidor, você tem mais controle sobre os dados que envia para fornecedores terceirizados (como Google e Facebook).
6. Como você não dispara tags de marketing e análise dos navegadores dos usuários, a marcação do lado do servidor pode ajudar a melhorar a velocidade do seu site.

Client-Side vs Server-Side GTM Container

A marcação do lado do cliente significa executar um contêiner do GTM em um ambiente do lado do cliente. O contêiner do GTM que é executado em um ambiente do lado do cliente é chamado de "Client-Side GTM Container" (também conhecido como contêiner web do GTM).

Você configura a marcação do lado do servidor por meio da marcação do lado do servidor.

O contêiner do GTM que é executado em um ambiente do lado do servidor é chamado de "Server-Side GTM Container" (também conhecido como contêiner GTM SS).

Existem várias maneiras de enviar dados do seu site para o seu contêiner do Google Tag Manager (GTM):

1. Usando seu contêiner web do GTM existente.
2. Usando o framework JavaScript Gtag.js (caso não seja possível usar o contêiner do GTM).
3. Usando o protocolo de medição.

Introdução ao contêiner GTM

O contêiner do GTM é um trecho de código JavaScript projetado para armazenar uma ou mais tags, bem como seus respectivos acionadores e variáveis. É por isso que ele é conhecido como contêiner.

Exemplos de tags de marketing: Código de tags de conversão do Google Ads, código do Pixel do Facebook, pixel do LinkedIn, etc.

Exemplos de tags de análise: Código de rastreamento do GA4, código de rastreamento do Adobe Analytics, etc.

Três funções principais do contêiner do GTM:

1. Armazenar tags e seus respectivos acionadores e variáveis em um local central.
2. Implantar diversas tags de marketing e análise em um site e/ou aplicativo móvel.
3. Roteamento (ou seja, envio) de dados de uma fonte de dados para outra.

Além de armazenar tags, acionadores e variáveis, o contêiner do GTM é usado para implantar tags de marketing e análise em um site e/ou aplicativo móvel.

Em vez de inserir várias tags diretamente no código de um site, uma única tag (chamada de contêiner do GTM) é inserida diretamente no código de cada página, sendo utilizada para implantar e gerenciar outras tags no site.

Isso torna o gerenciamento de tags eficiente. Essa é a vantagem de usar o GTM.

Observação: a tag de contêiner não consegue rastrear, por si só, as interações dos usuários (visualizações de página, eventos, transações etc.) nem os dados de uso do site.

Em outras palavras, a tag de contêiner não é uma tag de análise. Mas ela pode ser usada para implantar uma tag de análise.

O contêiner do GTM é frequentemente usado para rotear (ou seja, enviar) dados de uma fonte para outra.

Por exemplo:

Se você quiser enviar dados analíticos do seu site para o servidor do Google Analytics, poderá fazer isso por meio do contêiner do GTM.

Da mesma forma, se você quiser enviar dados de marketing do seu site para o servidor de anúncios do Facebook, poderá fazer isso por meio do contêiner do GTM.

No GTM, criamos integrações com cada fonte de dados por meio de ETL (extração, transformação e carregamento).

Funções ETL e marcação do lado do servidor

ETL é um processo utilizado para enviar dados de uma fonte de dados para outra.

Uma fonte de dados pode ser:

• Website
• Data warehouse (como o BigQuery)
• CRM
• Carrinho de compras
• Smartphone
• Tablet
• Eletrodomésticos digitais (máquina de lavar roupa, máquina de café, máquina caça-níqueis)
• Sistema de ponto de venda ou
• Qualquer dispositivo/sistema que possa ser conectado à internet.

Ao usar uma solução de gerenciamento de tags como o GTM para rotear dados de uma fonte de dados para outra (como do seu site para o servidor do Google Analytics), você está, consciente ou inconscientemente, realizando ETL (Extração, Transformação e Carga).

Seu contêiner do GTM atua como um hub entre a fonte de dados de origem e a fonte de dados de destino:

A fonte de dados da qual você extrai os dados é chamada de fonte de dados de origem. A fonte de dados para a qual você envia os dados é chamada de fonte de dados de destino.

Por exemplo:

Se você enviar dados do seu site para o servidor do Google Analytics via GTM, seu site será a fonte de dados de origem e o servidor do Google Analytics será a fonte de dados de destino.

Observação: Você também pode enviar dados:

• De uma fonte de dados de origem para várias fontes de dados de destino;
• De várias fontes de dados de origem para uma fonte de dados de destino;
• De várias fontes de dados de origem para várias fontes de dados de destino.

O processo ETL é composto pelas seguintes três funções:

• A função de extração é usada para extrair dados da fonte de dados de origem.
• A função de transformação é usada para transformar os dados em um formato que a fonte de dados de destino possa entender.
• A função de carregamento é usada para enviar os dados transformados para a fonte de dados de destino.

Exemplo de funções ETL

Suponhamos que você precise de um requisito de marcação para enviar dados de e-commerce do seu site para o Google Analytics via GTM.

Para realizar essa tarefa, normalmente você primeiro extrai os dados de e-commerce das camadas de dados (que estão codificadas no seu site) via GTM.

Em seguida, você transforma os dados de e-commerce em um formato que o Google Analytics possa entender. Isso é feito por meio de modelos de tags do GTM.

Finalmente, você envia os dados de e-commerce transformados para o servidor do Google Analytics.

O processo de extração dos dados de e-commerce das camadas de dados representa a função de extração.

Ao usar um contêiner do GTM para enviar dados de uma fonte de dados para outra, você executa, consciente ou inconscientemente, uma ou mais funções de ETL.

Na marcação do lado do servidor, as funções de ETL são executadas no ambiente do servidor.

Você rastreia e envia dados de usuários de uma ou mais fontes de dados de origem para o seu contêiner do GTM SS.

A fonte de dados original pode ser:

• Website
• Data warehouse (como o BigQuery)
• CRM
• Plataforma de anúncios (como o Facebook Ad Manager)
• Carrinho de compras
• Smartphone
• Tablet
• Eletrodomésticos digitais (máquina de lavar roupa, máquina de café, máquina caça-níqueis)
• Sistema de ponto de venda
• Qualquer dispositivo/sistema que possa ser conectado à internet.

A fonte de dados de destino pode ser:

• Website
• Data warehouse (como o BigQuery)
• CRM
• Plataforma de anúncios (como o Facebook Ad Manager)
• Carrinho de compras
• Smartphone
• Tablet
• Eletrodomésticos digitais (máquina de lavar roupa, máquina de café, máquina caça-níqueis)
• Sistema de ponto de venda
• Qualquer dispositivo/sistema que possa ser conectado à internet.

No caso do SS Tagging, enviamos dados da(s) fonte(s) de dados de origem para a(s) fonte(s) de dados de destino.

Utilizar os seus próprios servidores ou alugar servidores para a marcação do lado do servidor?

Você pode usar seus próprios servidores virtuais ou alugar servidores de terceiros para instalar as configurações no servidor. Há opções de hospedagem dedicada e hospedagem compartilhada.

Recomendo que você configure e use seus próprios servidores para a marcação no servidor.

Vantagens de usar seus próprios servidores para marcação do lado do servidor (Server Side Tagging):

1. A vantagem de usar seus próprios servidores é que você é o proprietário exclusivo dos seus dados, e de mais ninguém.
2. Você pode processar os dados facilmente de acordo com sua política de privacidade.
3. Você pode realizar inúmeras personalizações nas configurações de marcação do lado do servidor, pois você é o proprietário tanto dos dados quanto dos servidores.
4. Se você administra um site com alto tráfego (mais de 100 mil visitas por mês), usar seus próprios servidores custará muito menos do que contratar um servidor de terceiros.
5. Como você tem acesso total aos seus servidores, você tem controle total sobre todo o tráfego HTTP de saída do seu endpoint do servidor e sobre o registro de logs. Esse nível de controle pode beneficiá-lo muito na otimização do custo da marcação do lado do servidor.

Desvantagens de usar seus próprios servidores para a marcação do lado do servidor:

1. Para configurar a marcação do lado do servidor, o Google recomenda que você execute pelo menos 3 instâncias do App Engine em sua plataforma Google Cloud. Portanto, você precisaria configurar e manter esses três servidores virtuais.
2. Configurar e manter a marcação do lado do servidor pode se tornar muito técnico rapidamente. Você precisaria de um recurso interno dedicado (como um desenvolvedor) ou de um provedor de serviços externo para manutenção contínua.

O custo da marcação do lado do servidor ao usar seus próprios servidores

Para configurar a marcação do lado do servidor, o Google recomenda que você execute pelo menos 3 instâncias do App Engine em sua plataforma Google Cloud. Você precisaria configurar três servidores virtuais.

O custo por instância de servidor é de cerca de US$ 40 por mês. 3 instâncias de servidor custarão cerca de US$ 120 por mês ou US$ 1440 por ano.

Este é o dinheiro que você paga ao Google. E aqui está a parte ruim.

Este é apenas o custo de computação e o mínimo que você pode esperar gastar a cada mês.

O custo real depende da saída de rede (todo o tráfego HTTP de saída do endpoint do seu servidor) e do registro de logs. E isso pressupõe que o tráfego do seu site não aumente com o tempo.

Porque quanto mais tráfego seus sites receberem, mais tags de terceiros você enviará para elas e, consequentemente, mais você pagará.

Ao usar o recurso de marcação no servidor, você deve ter cuidado para não coletar dados desnecessários.

Devo instalar e gerenciar meus próprios servidores ou terceirizar a configuração do servidor?

Ao terceirizar a configuração de marcação do seu servidor para alguém com experiência (como eu rsrs), essa pessoa pode otimizar sua configuração, reduzindo ao máximo os custos computacionais, a saída de dados na rede e o registro de logs.

Assim, você paga o mínimo possível ao Google todos os meses.

Ao tentar fazer você mesmo, mesmo que consiga, você pagará desnecessariamente mais ao Google todos os meses, num futuro próximo.

Qualquer dinheiro que você pense estar economizando a curto prazo fazendo você mesmo, estará pagando de 3 a 4 vezes mais ao Google.

No final, você não economizará dinheiro algum, mas gastará muito mais.

Vantagens de contratar um servidor de terceiros

Em vez de configurar e manter seus próprios servidores virtuais, você também pode contratar um servidor de terceiros para o serviço de marcação do lado do servidor.

A seguir, as vantagens de contratar um servidor de terceiros:

1. Você pode começar imediatamente, pois o terceiro criará e manterá os servidores e integrações em seu nome, para que você não precise se preocupar com os aspectos técnicos da configuração.
2. Se você administra um site com baixo tráfego (menos de 30 mil visitas por mês), contratar um servidor pode ser mais barato do que manter seus próprios servidores virtuais.

Desvantagens de contratar um servidor de terceiros

A seguir, apresento as desvantagens de contratar um servidor de terceiros:

1. Prepare-se para pagar centenas ou milhares de dólares por mês

Se você administra um site com alto tráfego (mais de 100 mil visitas por mês), contratar um servidor pode facilmente se tornar muito mais caro do que manter seus próprios servidores.

Prepare-se para pagar ao seu provedor de soluções centenas ou milhares de dólares por mês.

2. Como você aluga espaço em servidor, você não é o proprietário exclusivo dos seus dados

3. Você não pode processar dados facilmente de acordo com sua política de privacidade

Na verdade, você tem muito pouco controle sobre o processamento de dados, pois não é o proprietário dos servidores. Isso pode se tornar um grande obstáculo para a conformidade com o GDPR.

4. Espere restrições de personalização

Você não pode realizar personalizações ilimitadas nas configurações de marcação do lado do servidor, pois você não é o proprietário dos dados nem dos servidores.

O nível de personalização permitido depende da expertise técnica da equipe da empresa terceirizada.

5. Você tem pouco controle se algo der errado

Se algo der errado com a configuração de marcação no servidor (o que acontece com frequência), não há muito o que você possa fazer.

Isso ocorre porque você não tem acesso ao servidor. Você precisará abrir um chamado de suporte e aguardar a resolução do problema. Enquanto isso, você não terá outra opção a não ser continuar coletando dados falhos ou incompletos.

Essa não é uma configuração ideal para grandes empresas consolidadas que processam milhares de transações por dia.

Se você administra um site de e-commerce e leva seu negócio a sério, use seus próprios servidores. Seu eu do futuro lhe agradecerá por isso.

Empresas que permitem contratar um seus servidores.

As seguintes empresas permitem contratar seus servidores:

• https://www.customerlabs.com/customer-data-platform/
• https://stape.io/
• https://anytrack.io/
• https://redtrack.io/
• https://www.getelevar.com/

Custo do rastreamento no servidor ao contratar um em servidor de terceiros

O custo do rastreamento no servidor ao contratar um servidor depende dos seguintes fatores:

1. Número de eventos baseados no servidor rastreado a cada mês

O custo do seu rastreamento no servidor depende muito do número de eventos baseados no servidor (também conhecidos como provedores) rastreados a cada mês para o seu site e/ou outras fontes de dados de origem.

Um evento é uma interação do usuário. Pode ser uma visualização de página, um clique em botão, um download, um clique em link etc.

Quanto mais tráfego seu site receber, mais eventos baseados em servidor você rastreará e maior será o custo.

2. Número de fontes de dados de origem que sua configuração de marcação requer.

A fonte de dados da qual você extrai os dados é chamada de fonte de dados de origem. Quanto mais fontes de dados de origem você usar, mais você pagará.

3. Número de fontes de dados de destino que sua configuração de marcação requer (integrações de API).

A fonte de dados para a qual você envia dados é chamada de fonte de dados de destino. Quanto mais fontes de dados de destino você usar, mais você pagará.

4. Número de servidores em nuvem que você aluga.

Quanto mais servidores você alugar, mais você pagará por mês.

5. Número de serviços que você deseja usar.

Esses serviços podem ser:

• Monitoramento de erros de tags.
• Monitoramento de conversões.
• Relatórios em tempo real.
• Retenção de dados.
• Automação baseada em regras.
• Alertas.
• Nível de suporte, etc.

Quanto mais serviços você usar, mais você pagará por mês.

Vale mesmo a pena contratar um servidor para a marcação do lado do servidor?

Existem três tipos de custos associados à configuração da marcação do lado do servidor (SS) do GTM:

1. Taxas únicas de configuração (geralmente a partir de US$ 980).
2. Taxas mensais recorrentes pagas a provedores de hospedagem como Stape e Google pelo uso de seus servidores (geralmente a partir de US$ 20/mês).
3. Taxas de manutenção (as taxas horárias do provedor de serviços que você utiliza).

A taxa mensal recorrente que você paga aos provedores de hospedagem pelo uso de seus servidores depende do número de eventos processados no último mês.

Portanto, quanto mais eventos você enviar para o servidor de marcação, mais você pagará, e quanto menos você enviar, menos você pagará.

Em outras palavras, à medida que o tráfego do site aumenta, o custo de usar a marcação SS também aumentará.

Você pode usar seus próprios servidores virtuais ou alugar servidores de terceiros para instalar configurações de marcação do lado do servidor. É como decidir entre hospedagem dedicada e compartilhada.

Recomendo configurar e usar seus próprios servidores virtuais no Google Cloud Platform para marcação do lado do servidor.

Mas muitas empresas alugam servidores de terceiros para instalar configurações de marcação do lado do servidor simplesmente porque é barato.

Se você usa marcação do lado do servidor de terceiros para GA4, Google Ads, Meta etc., onde paga uma pequena taxa de assinatura mensal (geralmente abaixo de US$ 100/mês), provavelmente já percebeu como parece "acessível" em comparação com a execução de seus próprios servidores no Google Cloud Platform.

Mas, como a maioria das coisas que parecem boas demais para ser verdade, há um porém.

Na verdade, são 11 poréms:

1. Propriedade e controle limitados dos dados.
2. Riscos de privacidade e segurança.
3. Problemas de conformidade com o GDPR e o CCPA.
4. Dependência da infraestrutura de servidores do fornecedor.
5. Personalização limitada.
6. Atrasos nos dados (latência).
7. Dependência de fornecedor.
8. Transparência e controle limitados no processamento de dados.
9. Risco de descontinuação do serviço.
10. Custos ocultos ao longo do tempo.

A resolução de problemas pode se tornar um pesadelo.

1. Propriedade e controle limitados dos dados

Você perde o controle direto e total dos seus dados ao usar um provedor de serviços terceirizado.

Eles processam e, às vezes, modificam seus dados antes que cheguem ao GA4. Você não tem ideia de como os dados são processados/modificados.

Risco: Você não tem mais 100% de visibilidade ou controle da sua coleta de dados.

2. Riscos de privacidade e segurança

Este é um ponto crucial, especialmente se você estiver sediado na União Européia.

Os dados dos seus usuários passam por servidores de terceiros antes de chegarem ao GA4. Seus dados podem ser expostos se esse provedor sofrer uma violação de segurança.

Risco: O GDPR e o CCPA responsabilizam você por vazamentos, não o fornecedor.

3. Problemas de Conformidade com o GDPR e o CCPA

O GDPR e o CCPA exigem que você saiba para onde os dados do usuário estão indo, como são processados ​​e quem tem acesso a eles.

Mas, com ferramentas de terceiros, você introduz um intermediário no seu fluxo de dados, tornando muito mais difícil rastrear e comprovar a conformidade.

Risco: Sem a devida conformidade, você corre o risco de sofrer penalidades do GDPR e do CCPA.

4. Dependência da Infraestrutura de Servidores do Fornecedor

Se o sistema do fornecedor ficar fora do ar por qualquer motivo, seu sistema de marcação também ficará indisponível. E o pior é que você não pode fazer nada a respeito, a não ser torcer para que o problema seja resolvido.

Risco: Imagine perder dados de marcação durante a Black Friday ou uma grande campanha.

5. Personalização Limitada

Esta é uma das maiores limitações. As configurações de terceiros são "plug-and-play", mas oferecem pouca ou nenhuma flexibilidade. Você pode enviar uma solicitação de suporte e torcer para que ela seja atendida.

Você pode acabar tendo que contornar as limitações da ferramenta em vez de fazer com que ela trabalhe para você.

Risco: Configurações de marcação exclusivas podem não ser possíveis.

6. Atrasos nos dados (latência)

Ao usar um serviço de terceiros, você tem pouco ou nenhum controle sobre a infraestrutura de servidores deles.

Portanto, você não pode gerenciar e otimizar os atrasos nos dados com o mesmo nível de controle que teria ao usar seus próprios servidores.

Risco: A marcação em tempo real sofre atrasos, o que afeta a coleta de dados e a tomada de decisões.

7. Dependência do fornecedor

Uma vez totalmente integrado a um sistema de terceiros, a migração é difícil. Configurações de marcação, APIs e dependências de plataforma criam barreiras de saída.

Impacto: A migração significa uma implementação completa e você pode perder um histórico valioso de marcação.

8. Transparência e Controle Limitados no Processamento de Dados.

Com um fornecedor terceirizado, você não consegue ver como os dados são processados, se são transformados ou se ocorrem falhas.

Impacto: Você não sabe se seus dados estão sendo modificados ou classificados incorretamente antes de chegarem à sua propriedade do GA4.

9. Risco de Descontinuação do Serviço

Este é um grande problema. Se o provedor terceirizado fechar, aumentar consideravelmente seus preços ou descontinuar o serviço, você estará em apuros.

Impacto: Você enfrentará uma migração forçada para outro provedor e sua coleta de dados poderá ser severamente interrompida.

10. Custos Ocultos ao Longo do Tempo

Serviços terceirizados geralmente começam baratos, mas cobram por uso (por exemplo, chamadas de API ou contagens de eventos). Os custos podem aumentar consideravelmente à medida que o tráfego cresce.

Impacto: O que começa como uma opção "barata" pode se tornar 10 vezes mais caro à medida que seu volume de dados aumenta. Você pode acabar pagando muito mais do que se usasse seus próprios servidores.

11. A resolução de problemas pode se tornar um pesadelo

Quando algo quebra, é o GA4? A ferramenta de terceiros? Seu CMS? Quem sabe?

Impacto: A resolução de problemas pode se tornar um pesadelo porque vários sistemas estão envolvidos.

Lembre-se: a opção "barata" de hoje pode se tornar uma armadilha cara amanhã devido à falta de controle sobre o processamento de dados, dependência de fornecedor e conformidade com a privacidade. A decisão é sua.

Garantir o orçamento para a configuração de marcação do lado do servidor (SS)

Depois de ouvir meus argumentos, sua empresa magicamente terá o orçamento necessário para a configuração de tags do lado do servidor (SS Tagging).

Quando seu site não usa tags SS, suas campanhas de anúncios pagos tendem a ter um desempenho inferior devido à insuficiência de dados de conversão. Seu pixel de anúncios precisa de muitos dados de conversão para encontrar o público com maior probabilidade de conversão.

De acordo com fontes como a Statista, cerca de 25 a 40% dos usuários de internet usam bloqueadores de anúncios globalmente. Nos EUA, a penetração em computadores geralmente varia entre 26 e 37%, segundo dados da eMarketer e da AudienceProject.

Os bloqueadores de anúncios não bloqueiam apenas anúncios; muitas vezes, eles também bloqueiam rastreadores (como o GA4).

Estudos mostram que os bloqueadores de anúncios podem reduzir as conversões relatadas em 20 a 30%. Você pode pular a configuração de SS Tagging agora e economizar X dólares inicialmente.

Mas esse mesmo valor pode ser desperdiçado ao longo do tempo em campanhas publicitárias mal otimizadas devido à subnotificação de conversões causada pelos bloqueadores de anúncios.

No final, você não está economizando dinheiro. Ele está simplesmente sendo redirecionado para campanhas publicitárias com baixo desempenho.

Você simplesmente não consegue ver isso, por isso não parece um desperdício. Mas a perda financeira é real.

Portanto, ter ou não um orçamento é irrelevante. Você gastará dinheiro com a configuração de tags do lado do servidor ou com anúncios que não serão exibidos, com perdas que se multiplicam devido a dados imprecisos. Adiar isso apenas aumenta o custo de oportunidade.

Seu dinheiro será gasto de qualquer maneira, seja de forma proativa ou desperdiçada. Para empresas que veiculam anúncios pagos, o SS Tagging não é um diferencial, mas um requisito obrigatório.

Migração completa ou parcial para marcação no servidor?

Migração completa significa mover todos os seus eventos de marcação baseados em navegador para um ambiente no servidor.

Vantagens da migração completa:

1. Você obtém a configuração de marcação mais precisa possível ao mover todas as suas marcações para o servidor.

Desvantagens da migração completa:

1. O custo da marcação no servidor será maior após a migração completa de todas as suas tags para o ambiente do servidor, pois você estará marcando a maioria dos eventos baseados em servidor.
2. Você pode precisar de um recurso dedicado em tempo integral para gerenciar e monitorar a marcação no servidor. Isso aumentará o custo total da marcação.
3. Nem todos os fornecedores terceirizados oferecem suporte à marcação no servidor. A marcação do seu site pode ser severamente restringida após a migração completa de todas as tags para o ambiente do servidor.
4. Para a maioria dos fornecedores terceirizados, não sabemos quais dados do navegador eles utilizam para retargeting ou marcação dos usuários do seu site.

Portanto, se você migrar todas as suas marcações baseadas em navegador para o lado do servidor, precisará superar muitos obstáculos técnicos para alcançar o sucesso. A marcação do seu site pode ficar severamente restrita após a migração completa de todas as funcionalidades desejadas.

Migração parcial significa mover apenas determinados eventos de marcação baseados em navegador para um ambiente do lado do servidor.

Vantagens da migração parcial:

1. A migração parcial manterá o custo da marcação do lado do servidor sob controle, pois você rastreará relativamente menos eventos baseados em servidor.
2. Você obtém o melhor dos dois mundos (marcação do lado do cliente e marcação do lado do servidor) ao implementar a migração parcial. Nem todos os fornecedores terceirizados oferecem suporte à marcação do lado do servidor. Nesse caso, você pode usar a marcação baseada em navegador. Assim, a marcação do seu site não será restringida.
3. A maioria das empresas implementa a migração parcial. Elas usam principalmente a marcação do lado do servidor para implementar a marcação de conversão baseada em API e a marcação baseada em navegador para o restante da marcação do site, como pageviews, clicks e etc.

Desvantagens da migração parcial:

1. Dados de conversão duplicados.

Ao implementar uma migração parcial, é fundamental não rastrear o mesmo evento de conversão duas vezes. Uma vez pelo navegador e outra pelo servidor.

Algumas plataformas de dados, como o Facebook, fornecem instruções muito claras sobre como usar a marcação baseada em navegador em paralelo com a marcação do lado do servidor para evitar a duplicação de eventos de conversão.

Outras, como o Google Analytics, não fornecem essas instruções.

Marcação no servidor e GDPR

Até onde sei, não há fundamento legal para contestar o uso de marcação no servidor. Não é ilegal nem viola o GDPR. No entanto, o uso de marcação no servidor não lhe dá a liberdade de seguir as diretrizes do GDPR com menos rigor.

Você ainda deve cumprir o GDPR e coletar dados de acordo com sua política de privacidade.

A marcação no servidor ajuda a recuperar os dados compatíveis com o GDPR que os bloqueadores de anúncios e navegadores estão bloqueando. Não é contra o GDPR recuperar dados de bloqueadores de anúncios e navegadores.

Dados compatíveis com o GDPR não incluem informações de identificação pessoal (como nome, endereço de e-mail, número de telefone etc.).

Dados compatíveis com o GDPR não devem ser usados para identificar seus usuários ou suas atividades em nível pessoal. Devem ser anônimos e agregados.

FAQ: Ainda preciso exibir um pop-up de consentimento de cookies se usar a marcação no servidor?

Ao usar a marcação no servidor, você não precisa configurar nenhum cookie de terceiros nos discos rígidos dos usuários. Você também não precisa armazenar informações no dispositivo do usuário nem obter acesso a informações no dispositivo do usuário.

Para a configuração de cookies primários, já existe um bom argumento para o "interesse comercial legítimo" no uso de cookies.

Por esses motivos, você provavelmente não precisará exibir um pop-up de consentimento de cookies.

Mas você ainda deve consultar seu controlador/processador de dados para ter certeza absoluta, pois sua situação pode ser diferente, especialmente se você estiver localizado na UE.

Você ainda pode precisar exibir um pop-up de consentimento se estiver marcando algo para o qual precise de consentimento prévio explícito de acordo com o GDPR e/ou sua política de privacidade.

Portanto, embora o pop-up de consentimento de "cookies" tenha sido removido, o pop-up de consentimento provavelmente permanecerá, a menos que você decida não divulgá-lo.

Observação: a maioria das soluções de pop-up de consentimento de cookies não se integra automaticamente aos contêineres do GTM do lado do servidor.

Como determinar se um site usa a marcação do lado do servidor (SS) do GTM?

Para confirmar a marcação SS no site em questão, siga os passos abaixo:

Passo 1: Clique com o botão direito do mouse em uma página da web no navegador Google Chrome e selecione Inspect.

Passo 2: Clique na aba Network, pressione CTRL+R e procure por /collect.

Passo 3: Clique um por um nos resultados da pesquisa que começam com /collect?V=2 até encontrar a URL da solicitação (na seção Headers) que não começa com algo como:

https://region1.google-analytics.com/g/collect?

Mas comece com um subdomínio como:

https://sgtm.yourtargetwebsite.com/g/collect?v=2

Isso é um forte indício de que o site está usando tags SS.

Passo 4: Clique na aba Application no painel Ferramentas do Desenvolvedor, expanda a seção Cookies, clique no domínio do site que você está investigando e localize o cookie FPID:

Passo 5: Depois de encontrar o cookie FPID, verifique a coluna HttpOnly. Ela deve exibir uma marca de seleção (✓) se estiver definida como true.

Se você encontrar um cookie FPID com o sinalizador HttpOnly definido (marca de seleção na coluna HttpOnly), é um forte indício de que o site está usando tags SS.

Passo 6: Instale e ative uma extensão de bloqueador de anúncios no seu navegador e visite o site em questão. Se o site ainda conseguir enviar eventos de marcação (como visualizações de página, adições ao carrinho, etc.) mesmo com o bloqueador de anúncios ativo, é possível que esteja usando marcação SS.

Visão geral da configuração de marcação do lado do servidor do GA4 via GTM

A seguir, uma visão geral das etapas envolvidas na configuração da marcação do lado do servidor para o Google Analytics 4 via GTM:

1. Instale o Google Tag Manager em seu site.
2. Instale o GA4 em seu site por meio do Google Tag Manager.
3. Crie uma conta do Google Cloud Platform com faturamento ativado.
4. Crie um contêiner do GTM no lado do servidor.
5. Configure seu servidor de marcação.
6. Configure um domínio personalizado no Google Cloud.
7. Configure seu contêiner de servidor para usar o domínio personalizado.
8. Conecte a tag de configuração do GA4 ao contêiner de servidor.
9. Atualize do servidor de teste para o servidor de produção.
10. Otimize os custos.

Fase 1: Instale o Google Tag Manager em seu site

Usaremos o Google Tag Manager (GTM) para configurar a marcação no servidor. Para que a marcação no servidor funcione, usaremos tanto o contêiner web quanto o contêiner servidor.

Se o GTM já estiver instalado no seu site, ignore esta fase e passe para a Fase 2.

Fase 2: Instale o GA4 em seu site por meio do GTM

A tag de configuração do GA4 que você usa atualmente para o seu GA4 Tagging envia dados para o endpoint do Google (https://www.google-analytics.com/g/collect), também conhecido como servidor do Google.

Mais tarde, editaremos essa tag para que ela envie dados para o endpoint do seu servidor, também conhecido como servidor de tags. É por isso que precisamos de uma tag de configuração do GA4 para nossa configuração de tags no servidor.

Se você já tiver o GA4 instalado em seu site, pule esta fase e vá para a Fase 3.

Fase 3: Crie uma conta do Google Cloud Platform com o faturamento ativado

Se você já possui uma conta do Google Cloud Platform com o faturamento ativado, ignore esta fase e passe para a Fase 4.

Fase 4: Criar um contêiner do GTM no servidor.

Siga os passos abaixo para criar um novo contêiner do GTM no servidor:

Passo 1: Acesse sua conta do Google Tag Manager e clique no botão Admin.

Passo 2: Clique no botão + para criar um novo contêiner do GTM:

Passo 2: Clique no botão + para criar um novo contêiner do GTM:

Passo 4: Clique em Server em Target Platform e, em seguida, clique no botão Create:

Você deverá ver a seguinte janela pop-up:

Passo 5: Clique no botão X para fechar:

Você deverá ver agora uma tela semelhante à mostrada abaixo:

Seu contêiner GTM do lado do servidor foi criado.

Fase 5: Configure seu servidor de marcação.

Siga os passos abaixo para configurar seu servidor de marcação:

Passo 1: Clique no ID do contêiner do seu servidor GTM:

Você deverá ver agora uma janela pop-up semelhante à abaixo:

Passo 2: Clique no botão Provisionar servidor de marcação automaticamente:

Passo 3: Selecione sua conta de faturamento do Google Cloud Platform no menu suspenso:

Esta é a mesma conta de faturamento que você criou anteriormente na Fase 1.

Passo 4: Clique no botão Select billing account and create server.

Você verá a seguinte mensagem:

Observação: Não feche esta janela de mensagem.

Assim que seu servidor de marcação for criado com sucesso, você verá uma caixa de mensagem semelhante a esta:

Passo 6: Clique no botão "Close":

Fase 6: Configurar domínio personalizado no Google Cloud.

Siga os passos abaixo:

Passo 1: Clique no ID do contêiner do seu contêiner do lado do servidor do GTM:

Você deverá ver agora uma janela pop-up semelhante à abaixo:

Passo 2: Abra seu projeto do Google Cloud Platform clicando no botão abaixo:

Você deverá ver agora uma tela semelhante à mostrada abaixo:

Passo 3: Digite custom domain na caixa de pesquisa e clique no primeiro resultado da pesquisa:

Passo 4: Clique no botão Add a custom domain:

Passo 5: Clique no menu suspenso abaixo do texto Select the domain you want to use:

Passo 6: Clique na opção Verify no menu suspenso:

Nesse passo você terá que fazer algumas configurações via DNS de acordo com seu servidor.

Passo 7: Digite 'sgtm' seguido do seu nome de domínio principal.

Como meu nome de domínio principal é reulison.com.br, vou digitar sgtm.reulison.com.br e clicar no botão "Verify".

Você será redirecionado automaticamente para sua conta do Google Search Console em outra aba do navegador:

Passo 8: Selecione seu registrador de domínio no menu suspenso.

Eu selecionaria Any DNS Provider, pois meu gerenciador de DNS é o Vercel e ele não está listado na lista de serviços disponíveis.

Passo 9: Adicione o registro TXT que você vê à configuração de DNS para sgtm.<seu-nome-de-domínio>.com e clique no botão VERIFY:

Observação: Se a verificação do seu domínio falhar, você deve procurar a ajuda de um desenvolvedor web (pode ser eu), pois adicionar registros DNS corretamente pode ser bastante técnico.

Passo 10: Volte para sua conta do Google Cloud e clique no botão Refresh domains:

Você deverá ver agora uma tela semelhante à mostrada abaixo:

Passo 11: Clique no botão Continue:

Passo 12: Clique no botão x ao lado de www.sgtm.<seu-nome-de-domínio>.com.

Passo 13: Clique no botão Save mappings:

Passo 14: Clique no botão Continue:

Passo 15: Adicione os registros DNS que você vê com seu registrador de domínio para sgtm.<seu nome de domínio>.com e clique no botão Done:

Após cerca de 15 a 20 minutos, você deverá ver uma tela semelhante à imagem abaixo:

Veja como configurei os diversos registros DNS para meu site no Vercel:

O URL do meu endpoint do servidor agora é https://sgtm.reulison.com.br/.

O URL do seu endpoint do servidor será https://sgtm.<seu nome de domínio>.com/

Passo 16: Adicione a palavra healthy ao URL do seu endpoint do servidor.

Como o URL do meu endpoint do servidor é https://sgtm.reulison.com.br/, o URL modificado será

https://sgtm.reulison.com.br/healthy

Passo 17: Acesse o URL modificado do seu endpoint do servidor no seu navegador.

Se você vir a mensagem ok, significa que o seu endpoint do servidor está respondendo corretamente à sua solicitação e está servindo o servidor GTM a partir do seu nome de domínio personalizado.

Se você não vir a mensagem ok, aguarde 24 horas e tente novamente, pois as alterações de DNS podem levar até 24 horas para entrar em vigor.

Após 24 horas de espera, se você ainda não vir a mensagem ok, significa que seus registros de DNS não foram configurados corretamente. Entre em contato com seu desenvolvedor.

Você deverá ser redirecionado automaticamente para a janela de depuração do gerenciador de tags:

Passo 2: Observe atentamente o URL na barra de endereços do navegador. Ele conterá o nome de domínio server-side-tagging-2xbnshwpxa-uc.a.run.app.

Passo 3: Navegue até o contêiner do seu servidor GTM e clique no link Admin:

Passo 4: Clique no link Container Settings em CONTAINER:

Agora você deverá ver a URL do contêiner do servidor padrão, a mesma que você viu anteriormente na janela de depuração:

Passo 5: Substitua o URL do contêiner pelo URL do seu endpoint do servidor (no meu caso, https://sgtm.reulison.com.br) e clique no botão "Save".

Passo 6: Clique na aba Workspace:

Passo 7: Clique novamente no botão Preview para atualizar a janela de depuração:

Você deverá ser redirecionado automaticamente para a janela de depuração do gerenciador de tags:

Observação: Se, em vez da janela de depuração do GTM, você vir uma mensagem de erro, aguarde 24 horas e tente novamente, pois as alterações de DNS (feitas anteriormente durante a configuração do domínio personalizado) podem levar até 24 horas para entrar em vigor.

Fase 8: Conecte a tag de configuração do GA4 ao contêiner do servidor

A tag de configuração do GA4 que você usa atualmente para o seu GA4 Tagging envia dados para o endpoint do Google (https://www.google-analytics.com/g/collect), também conhecido como servidor do Google.

Agora, vamos atualizar essa tag para enviar dados para o endpoint do seu servidor.

Siga os passos abaixo:

Passo 1: Navegue até o seu contêiner web do GTM.

Passo 2: Edite a tag de configuração do GA4:

Passo 3: No seu GTM Web, em sua Tag do Google Tag clique na aba Configuration settings e em Configuration Parameter selecione server_container_url e insira sua URL do seu servidor, no meu caso: https://sgtm.reulison.com.br

Passo 4: Navegue até o contêiner do seu GTM Server e clique no botão Preview.

Passo 5: Navegue até o seu GTM web e clique no botão Preview:

Passo 6: Insira a URL do seu site e clique no botão Conect:

Passo 7: Volte para a janela do seu GTM Server. Agora você deverá ver alguns acessos registrados:

A requisição HTTP GA4 que enviamos (do nosso contêiner web) para o endpoint do nosso servidor é reivindicada pelo cliente GA4:

É muito importante que o cliente GA4 aceite a solicitação GA4. Caso contrário, há algo errado com sua configuração de marcação.

Passo 10: Clique na aba Event Data para ver quais dados de evento são enviados para o seu servidor:

Passo 11: Agora va para sua conta no Google Cloud, busque por Cloud Run. Ele vai configurado dois serviços automaticamente server-side-tagging e server-side-tagging-preview.

Fase 10: Otimização de Custos.

A marcação no servidor não é do tipo "configure e esqueça".

Embora a marcação no servidor seja mais confiável e menos propensa a erros do que a marcação baseada em navegador, ela ainda requer monitoramento diário/semanal e ajustes periódicos.

É muito provável que você precise fazer ajustes na sua configuração de marcação após a primeira configuração. Você precisará verificar regularmente se há erros originados do seu site e de outras fontes de dados.

Caso contrário, isso poderá aumentar seus custos.

Ao usar a marcação no servidor, você deve ter cuidado para não coletar dados desnecessários. Quanto mais eventos baseados em servidor você rastrear, mais você pagará.

Ao terceirizar a configuração de marcação do lado do servidor para alguém com experiência, essa pessoa pode otimizar sua configuração para reduzir o custo, diminuindo ao máximo os cálculos, a saída de rede e o registro de logs. Assim, você paga o mínimo possível ao Google todos os meses.

Ao tentar fazer isso sozinho, mesmo que consiga, você provavelmente pagará ao Google mais que o necessário.

Como configurar a camada de dados para o contêiner do GTM no lado do servidor.

O contêiner do GTM no lado do servidor não é carregado no navegador e reside no ambiente do Google Cloud. Você pode estar se perguntando como configurar uma camada de dados para um contêiner do GTM que nem sequer está disponível no navegador.

Outra questão é se o contêiner do GTM no lado do servidor requer uma camada de dados. A resposta para essa pergunta não é simples, mas tentarei explicá-la com alguns cenários.

Cenário 1: Ao definir uma tag do Google Analytics (GA4 ou Universal Analytics) no contêiner do GTM no lado do cliente, você a configura de forma que todas as variáveis da camada de dados sejam mapeadas para um parâmetro específico, como uma variável personalizada, uma métrica personalizada, variáveis de dados de e-commerce etc.

Quando o site é carregado, o contêiner no lado do cliente recupera seu valor da camada de dados e o envia para o contêiner no lado do servidor por meio de solicitações HTTP.

O contêiner no lado do servidor interpreta as solicitações e as encaminha para o Google Analytics. Neste cenário, se você definir a variável personalizada, digamos "User State", que pode ter valores como logged ou not logged.

Essa variável será inicializada a partir da camada de dados durante o carregamento da página e enviada via solicitação HTTP para o contêiner do GTM no servidor.

Agora, o contêiner do servidor interpretará a solicitação HTTP recebida e passará as informações para o Google Analytics no mesmo formato, sem modificações.

Você pode ver na imagem abaixo que estou disparando uma tag de visualização de página e passando a variável personalizada como "User State".

As mesmas informações são mantidas no contêiner GTM do lado do servidor e, quando a tag é acionada, a variável também é definida como logged, que nada mais é do que o valor da nossa variável da camada de dados "User State".

Isso responde à nossa pergunta: se configurarmos corretamente as tags do lado do cliente com um valor da camada de dados e o passarmos em um parâmetro específico, como uma dimensão personalizada, uma métrica personalizada, variáveis de dados de e-commerce etc., ele será mantido exatamente como está no contêiner do lado do servidor, e você não precisará de uma camada de dados separada para o contêiner do GTM do lado do servidor.

Cenário 2: Agora, vamos considerar uma situação em que você deseja enviar dados para uma ferramenta de terceiros, como o Facebook, e deseja ter um valor da sua variável da camada de dados, que está disponível no navegador (e também no contêiner do GTM do lado do cliente).

Você gostaria de usar o mesmo valor de variável que está disponível no contêiner do lado do servidor.

Você não pode usar ou interpretar as dimensões personalizadas, métricas ou variáveis de e-commerce da tag do Universal Analytics.

Nesse caso, a tag de configuração do GA4 entra em ação, e você pode usá-la como um meio para enviar valores do contêiner do GTM do lado do cliente para o contêiner do GTM do lado do servidor.

Usando parâmetros de tag do GA4, você pode enviar valores do contêiner do GTM no lado do cliente para o contêiner do GTM no lado do servidor.

Em seguida, você pode usar esses valores como variáveis de dados de evento no contêiner do lado do servidor.

Agora, vamos ver como você pode fazer isso.

Como passar uma variável da camada de dados para um contêiner do Google Tag Manager (GTM) no servidor?

Para passar uma variável da camada de dados de um contêiner do GTM no cliente para um contêiner do GTM no servidor, vamos criar eventos fictícios do Google Analytics 4 (GA4).

Observação: Presumo que você já tenha configurado suas variáveis da camada de dados no GTM.

Passo 1: Navegue até o contêiner do GTM Web, vá até sua Tag do Google Tag.

Passo 3: Vá até Shared event settings e adicione um novo Event Parameter.

Passo 4: Clique em Add parameter e insira seu novo parametro , no meu caso estou usando um parametro enviando um parametro blog_category junto ao evento pageview, e depois clique em Save.

 window.dataLayer.push({
    event: 'pageview',
    page_path: url,
    page_title: typeof document !== 'undefined' ? document.title : '',
    blog_category: blogCategory,
  })

Passo 5: Ao mesmo tempo, coloque o contêiner GTM do lado do servidor no modo Preview e você deverá ver a solicitação via cliente do GA4, conforme mostrado abaixo.

Parabéns!

Você passou com sucesso a variável da camada de dados de um contêiner GTM do lado do cliente para um contêiner GTM do lado do servidor.

Mas espere, esses valores da variável da camada de dados ainda estão disponíveis apenas em solicitações de dados de eventos e agora precisamos criar uma nova variável de dados de evento no contêiner do lado do servidor para que ela possa armazenar esses valores.

Como usar variáveis da camada de dados do lado do cliente em um contêiner GTM do lado do servidor.

Siga os passos abaixo para criar uma nova variável do tipo Event data no contêiner GTM do lado do servidor, que herdará seus valores dos parâmetros de eventos da tag do GA4 e, em última instância, da camada de dados.

Passo 1: Navegue até o seu contêiner GTM do lado do servidor, clique em Variable e, em seguida, clique em New em User-Defined Variables.

Passo 2: Agora selecione 'Event data' como o tipo de variável.

Passo 3: Agora, digite o caminho exato da chave para a variável específica que definimos no contêiner do GTM do lado do cliente.

Em outras palavras, o Event Parameter do contêiner do GTM do lado do cliente deve ser o Key Path do contêiner do lado do servidor para a variável correspondente.

Por exemplo, definimos o nome do campo como Page Category no contêiner do lado do cliente, e esse é o Key Path da variável do lado do servidor.

GTM client-side Event Parameter:

GTM server-side Key Path:

Passo 4: Agora, salve a variável e repita o mesmo processo dos passos 1 ao 3 para as outras variáveis também.

Passo 5: Agora, coloque seu contêiner do GTM do lado do servidor novamente no modo de visualização e visite uma página.

Para as solicitações correspondentes do cliente GA4, clique em Variables no console e você deverá ver as variáveis que criamos no contêiner do lado do servidor com os valores da variável original da camada de dados, como abaixo.

Parabéns!

Você configurou com sucesso uma camada de dados para um contêiner do lado do servidor do GTM. Agora você pode usar essas variáveis ​​em qualquer tag de terceiros.

Solução de problemas de marcação do lado do servidor do GA4 GTM

A seguir, apresento os 7 principais motivos pelos quais a marcação do lado do servidor do seu GA4 GTM pode estar apresentando problemas.

#1 Uma ou mais tags de evento são disparadas antes da tag do Google.

Na marcação do lado do servidor, é mais provável que as tags de evento sejam disparadas antes da tag do Google do que na marcação do lado do cliente.

Isso ocorre devido às diferentes maneiras como os dados de evento são processados e transmitidos entre o cliente e servidor. Portanto, é mais provável que você veja tráfego não atribuído na marcação do lado do servidor.

Certifique-se de que sua Tag do Google Tag seja disparada antes de qualquer tag de evento.

#2 O evento page_view é disparado antes do evento session_start.

Altere a tag do Google Tag no contêiner do GTM do lado do cliente para disparar em todos os eventos de inicialização em vez de em todas as páginas.

Dessa forma, o evento session_start será disparado antes do evento page_view.

#3 As configurações de Cookies e Identificação do Cliente no Cliente GA4 no Servidor GTM estavam definidas como Server Managed.

Altere as configurações de Cookies e Identificação do Cliente no Cliente GA4 no Servidor GTM para JavaScript-managed.

Isso deve resolver os problemas de tráfego não atribuído relacionados à marcação no servidor.

A desvantagem do gerenciamento por JavaScript, em comparação com o gerenciamento pelo servidor, é que alguns navegadores podem expirar os cookies prematuramente.

Agora, você precisa escolher entre a desvantagem de alguns navegadores expirarem os cookies prematuramente e a correção do tráfego não atribuído.

Eu optaria pela segunda opção, já que o tráfego não atribuído é praticamente inútil para análise de dados.

#4 Nem todas as tags no GTM do lado do servidor têm o server_container_url configurado

Quando uma tag não passa pelo contêiner do lado do servidor, o GA4 pode não conseguir atribuir corretamente os dados de origem/mídia do tráfego, resultando em tráfego não atribuído no GA4.

#5 Desalinhamento entre a marcação do lado do cliente e do lado do servidor.

Este é um dos problemas mais negligenciados ao configurar a marcação do lado do servidor.

O desalinhamento entre a marcação (tagging) do lado do cliente e do servidor pode levar a problemas de tráfego não atribuído no GA4, pois os dados capturados e processados pelas configurações do lado do cliente e do servidor podem ser diferentes ou estar incompletos.

Por exemplo, a marcação do lado do cliente pode capturar automaticamente dados de parâmetros UTM na maioria dos URLs.

No entanto, a marcação do lado do servidor não captura automaticamente dados de parâmetros UTM.

O contêiner do lado do servidor pode receber o evento, mas sem os detalhes de source/medium, o que pode levar a tráfego não atribuído.

#6 Desalinhamento entre o tratamento de consentimento no lado do cliente e no lado do servidor

Ao usar o Modo de Consentimento, as implementações do lado do cliente e do lado do servidor precisam estar alinhadas.

Se o consentimento for tratado de forma diferente no servidor em comparação com o cliente, isso pode levar a problemas de tráfego não atribuído.

#7 Não testar a marcação do lado do servidor bloqueando o GTM no lado do cliente

Ao bloquear ou desativar o contêiner do GTM no lado do cliente, você pode isolar e verificar a funcionalidade da marcação do lado do servidor. Você pode identificar problemas difíceis de diagnosticar.

Você pode simular cenários em que bloqueadores de anúncios, navegadores, VPNs ou ferramentas de privacidade podem bloquear a marcação do lado do cliente.

Uma das maneiras mais eficazes de impedir que o GTM seja bloqueado por bloqueadores de anúncios é servir o script do contêiner do GTM a partir seu proprio domínio em vez do domínio padrão googletagmanager.com.