Server-Side Google Tag Manager Deep Impact

Antes de mergulharmos no Google Tag Manager (GTM) do lado do servidor, vou prefixar a carne deste post com uma ressalva: respeitar sempre a privacidade do usuário.

Qualquer técnica de coleta de dados discutida aqui deve ser aplicado corretamente e não como uma alternativa para contornar a regulamentação de consentimento de coleta de dados.

vista de 10.000 pés

Aqui está uma situação familiar - Google Tag Manager como a conhecemos há anos.

Seu contêiner é carregado em todas as páginas, ou telas em seu site/app, e com base nos eventos de acionamento, os dados são enviados para o primeiro e terceiro pontos finais.

Funciona, está bem, mas não é perfeito. Bloqueadores de rastreamento, falhas no JavaScript, muitos, muitos pedidos para pontos finais, e JavaScript ineficiente são todos riscos, e problemas potenciais de desempenho que podem levar a problemas de qualidade de dados.

O GTM do lado do servidor move a solicitação de tag vendor do cliente para um servidor - um servidor na Plataforma Google Cloud que vive em um subdomínio de seu site. O container carregado no navegador/app ainda tem tags e ainda envia uma solicitação mas tem muito menos código, envia menos solicitações, não é necessariamente afetado pelo software anti-tracking, não envia o endereço IP do usuário para fornecedores de tags de terceiros, e os cookies de primeira parte são configurados corretamente em um Forma compatível com o ITP.

Out of the Box - O que é legal?

Há muito para se empolgar com o GTM do lado do servidor, pois, do lado do cliente, tudo isso é muito familiar—mas muito melhor! O comerciante digital "tradicional" ainda pode configurar sua(s) tag(s) no Facebook com os mesmos gatilhos, e acender os holofotes conforme necessário. O mesmo, o mesmo... mas diferente.

Como mencionado anteriormente, em vez de enviar dados para o endpoint do fornecedor da tag, ela é enviada para um subdomínio. Por exemplo, se você estiver em www.mysite.como GTM do lado do servidor enviará os dados para tracking.mysite.comum subdomínio que você pode ter configurado.

E isso é ótimo porque...?

• Respeita a privacidade do usuário: O endereço IP do usuário não é enviado a um terceiro.
• Preserva a qualidade dos dados: A prevenção de rastreamento não acontece em pedidos ao seu próprio domínio.
• Ele alivia o inchaço do código do lado do cliente: As tags requerem menos trabalho no navegador, transferindo a carga de trabalho para o servidor. Isto significa que o que permanece em GTM no navegador faz menos, assim o site roda mais rápido.
• Ele consolida as solicitações do lado do cliente: Você pode enviar várias solicitações do servidor com base em uma solicitação do cliente.

Na MightyHive, nós defendemos fortemente o foco no que é melhor para o usuário, não a capacidade de frustrar ou contornar o software anti-rastreamento. Lembrete: agir com retidão, não de forma egoísta. Como está agora, os dados são coletados, não capturados. No futuro, os dados serão trocados... Pense nisso por um minuto.

Impacto mais profundo

Você já notou que os pedidos de rastreamento são enviados para seu domínio e não para um domínio de terceiros? A carga de trabalho de coleta de dados é transferida para sua infra-estrutura.

Isso lhe dá vontade de voltar para o registro no servidor web? Quão diferente é isto do registro no servidor web?

Muito.

Os dados analíticos são formatados (em sessão), limpos (PII removidos), integrados (unidos aos dados dos Anúncios do Google, Anúncios de Busca/Exibição & Vídeo 360) e apresentados prontos para desempenhar sua função: análise e otimização de todos os aspectos do negócio on-line, o que, sejamos francos, tem tudo a ver com um melhor marketing.

Os registros do servidor Web não coletam todos os dados comportamentais. Normalmente, os dados em nível de log não são integrados aos dados do canal de marketing, o que significa que não há um loop de feedback para a ativação dos dados.

Mas! há semelhanças entre o GTM do lado do servidor e o log do servidor Web. O servidor web recebe uma solicitação, tipicamente para uma página, constrói o conteúdo da página e responde, possivelmente definindo cookies de primeira mão junto com a resposta. O endpoint GTM do lado do servidor também recebe solicitações e responde, potencialmente com cookies (mas com menos conteúdo).

Agora... o servidor web sabe que página está voltando.

É sabe que dados apresentar na camada de dados para registrar uma transação (por exemplo).

A camada de dados é capturada por uma etiqueta disparada no navegador e então enviada voltar para o ponto final de rastreamento.

O ponto final então leva os mesmos dados e o envia para o Google Analytics (GA) para completar a viagem de ida e volta e obter seus dados analíticos registrados.

Phew!

Espere um minuto. Se o servidor web sabe que está renderizando uma página de confirmação "obrigado", e sabe que dados renderizar na camada de dados, por que se preocupar em enviar isto para o navegador para que ele simplesmente o envie de volta ao ponto final de rastreamento e depois para a GA?

Por que não remover alguns passos para a eficiência? O servidor da web sabe que está apresentando uma página de confirmação. Portanto, ele constrói exatamente a mesma solicitação que o navegador estava fazendo, e envia os dados da transação GA diretamente para o ponto final de rastreamento. Recorte a viagem de ida e volta do cliente.

É bastante normal disparar etiquetas de conversão, Floodlights, FB pixels, Adnxs, TTD, e assim por diante para registrar as transações. Não as envie para o cliente para tratar. Como o servidor web responde com a página de confirmação, envie esses pedidos diretamente para o ponto final de rastreamento. O endpoint responde com os detalhes dos cookies a definir, e o servidor web envia aqueles com o conteúdo da página de confirmação na resposta ao cliente.

Pense em quantas etiquetas de marketing e pixels de rastreamento disparam em eventos no nível da página. Quantas tags realmente precisam disparar sobre o cliente? Quantas tags nem precisam ser expostas ao navegador? E se, apenas talvez, você somente tinha tags acionadas por eventos de nível de página? Talvez você só precise de rastreamento de nível de página se você tiver removido todas as suas inchaço de dados? Então você não precisa CNAME o subdomínio de rastreamento, você pode restringir o acesso ao seu endpoint de rastreamento para permitir apenas que seu servidor web o acesse via https (pense em restrição de faixa IP). Isso é um monte de menos complexidade e uma quantidade razoável de peças móveis removidas da solução.

Mais simples é melhor. Nenhum código é melhor do que nenhum códigocomo diz o ditado.

Em conclusão

A solução GTM do lado do servidor oferece uma boa e correta solução para a medição analítica digital. É boa porque a qualidade dos dados pode ser melhorada, a privacidade do usuário está mais protegida e, significativamente, é um passo para fazer menos trabalho no navegador, o que significa que os sites e aplicativos ficam mais rápidos.

Pensar nas possíveis soluções que a tecnologia oferece, com a motivação correta em mente, demonstra quão versátil é a solução, quanta energia está disponível e que caminhos ainda devem ser explorados para alavancar os dados de primeira mão.