Por que não devemos pegar elementos do DOM para passar informações dentro do Google Tag Manager

O que você irá aprender?

    Postei la no meu instagram esses dias sobre um cliente fazendo uma gambiarra puxando as informações diretamente de um comppo de texto escondido página, da uma ligada:

    A variável em questão monta um objeto para ser utilizado junto ao Enhanced Commerce funcionalidade do Google Analytics Universal que disponibiliza uma série de relatórios voltados para lojas on-lines. O objeto em questão inclusive monta apenas o o escopo que envia para o Google Analytics informações sobre compra, nem é importante né? Kkkk (Depois a galera não sabe pq não bate as vendas no Google Analytics com a plataforma)

    Pois bem, vamos analisar um pouco do porque não devemos puxar elementos diretamente do DOM, principalmente quando estamos falando de um checkout de terceiro, mas antes…

    O que é DOM?

    DOM ou Modelo de Objeto de Documento é uma interface de programação para documentos HTML, XML e SVG. Ele fornece uma representação estruturada do documento como uma árvore. Não sou eu quem estou dizendo é a MDN vou ilustrar uma simulação de página que representa os campos puxados no print de cima pra gente bater um papo beleza?

    <!DOCTYPE html>
    <html lang="en">
    <head>
        <meta charset="UTF-8">
        <meta http-equiv="X-UA-Compatible" content="IE=edge">
        <meta name="viewport" content="width=device-width, initial-scale=1.0">
        <title>Seu pedido foi finalizado com sucesso</title>
    </head>
    <body>
        <h1>Seu pedido foi finalizado com sucesso</h1>
        <div class="hidden">
            <input type="hidden" id="idTrans" value="1382211688">
            <input type="hidden" id="amount" value="582.12">
            <input type="hidden" id="cupom" value="">
            <input type="hidden" id="plan" value="Yearly - Premium Plus">
            <input type="hidden" id="billing" value="Boleto Bancário">
        </div>
    </body>
    </html>

    Forcei a barra né, mostrei um monte de código, falei de arvore, kkk que loucura! Tá mais da uma olhada aqui em baixo:

    Toda estrutura dessa árvore DOM inicia assim como na vida real da raiz, nesse caso toda raiz de um DOM está presente no objeto “window” e de lá começamos a estruturar nossas ramificações.

    Quando navegamos dentro desse objeto conseguimos visualizar outros objetos com suas propriedades esse objetos chamamos de “child”, por exemplo, dentro da propriedade “document” temos uma propriedade bem importante que define a referência do usuário “referrer”. Ou seja, quando acessamos window.document.referrer teremos o retorno de onde o usuário veio antes de chegar no nosso site. Mas vamos nos concentrar no objeto “document” por enquanto.

    Navegando dentro desses filhos conseguimos chegar até os campos de textos que estão escondidos dentro da página propositalmente para puxar as informações sobre transações eles fazem isso nesse trecho do código aqui:

    <div class="hidden">
            <input type="hidden" id="idTrans" value="1382211688">
            <input type="hidden" id="amount" value="582.12">
            <input type="hidden" id="cupom" value="">
            <input type="hidden" id="plan" value="Yearly - Premium Plus">
            <input type="hidden" id="billing" value="Boleto Bancário">
    </div>

    Dentro da variável ele puxar essas informações através do atributo id através dessa instrução “document.getElementyById(“idTrans”).value”, assim ele navega dentro dos nós para puxar o valor que está no campo value do elemento input#idTrans retornando “1382211688” como o valor da variável.

    Esse inclusive é um dos motivos inclusive de uma certa indignação minha, se teve tempo de implementar isso dentro do código fonte, puxando todas as informações relacionadas a compra, tinha tempo para implementar as informações via camada de dados.

    Falta de escalabilidade dentro do Google Tag Manager

    Qual é o ponto sobre passar informações copiando diretamente pelo DOM? Ficamos totalmente a mercê do código renderizados na página, além de criar um ambiente totalmente instável, cria também um ambiente suscetível a mudanças da plataforma que mudaria as informações coletadas. Agora tu imagina acordar naquela segunda feira e deparar com a noticia de que os seus dados pararam de coletar? Pois é, a camada de dados serve para trazer uma estabilidade maior as suas informações personalizadas.

    Imagina que essa plataforma em questão decide mudar para uma nova versão do layout, ou até mesmo uma nova versão do checkout como um todo. O que é mais fácil de manter dentro do código, algo que visivelmente passa informações de compra para uma plataforma de implementação de tags, uma vez que fica explicito que a camada de dados é utilizada pelo Google Tag Manager, ou algo que simplesmente está na página, solta sem nenhuma referência sobre o que se trata?

    Overview sobre a camada de dados do Google Tag Manager

    Datalayer (camada de dados) é uma camada invisível de comunicação do nosso código fonte com o Google Tag Manager, toda vez que precisamos personalizar algum tipo de informação dentro das nossas ferramentas de análise precisamos resgatar essas informações diretamente do nosso código. Por exemplo, quando queremos dizer quais produtos foram comprados, estamos automaticamente gerando a necessidade de puxar essas informações de algum lugar. O Google Analytics sozinho não consegue saber que o seu usuário finalizou uma compra e acima de tudo, que os produtos que foram comprados foram a camisa preta e a caneca rosa.

    Você pode ler o post completo aqui

    Funciona assim:

    Nesse caso em questão, a camada de dados serve para gente como uma camada de comunicação entre o código fonte (Página de finalização de pedido) e o Google Tag Manager de forma que a gente consegue personalizar as informações de acordo com quais produtos o usuário comprou.

    Assim conseguimos passar com muito mais exatidão as informações que precisamos passar para não só o Google Analytics mais para todas as outras tags que podem se beneficiar desse conteúdo.

    Ou seja, quando você implementa esse tipo de variável personalizada:

    function() {
     var ecommerceData = {
      'event': 'purchase',
      'ecommerce': {   
        'purchase': {
          'actionField': {
            'id': document.getElementById('idTrans').value,       
            'revenue':  document.getElementById('amount').value,
            'coupon': document.getElementById('cupom').value
          },
          'products': [{                            // List of productFieldObjects.
            'name': document.getElementById('plan').value,     // Name or ID is required.  
            'price':  document.getElementById('amount').value,        
            'category':  document.getElementById('billing').value,        
            'quantity': 1        
           }]
        }
      }
    
     
     };
      return ecommerceData;
    }

    Além de você estar suscetível a mudanças na página que podem afetar suas coleta, você fica totalmente a mercê a tipagem desses dados predefinidos pelo Google por exemplo, na documentação o Google Analytics define que q quantidade de produto é do tipo inteiro e não uma string, logo passar uma informação com a tipagem errada é extremamente ruim para a precisão dos dados, sacou?

    Artigos Relacionados

    WhatsApp