Como evitar problemas de performance e recursividade em tags do Google Tag Manager

O que você irá aprender?

Se você trabalha com Google Tag Manager (GTM), já deve ter se deparado com problemas como tags mal configuradas, dependências desnecessárias ou até loops recursivos que comprometem o desempenho do site. É comum cair nessas armadilhas quando configuramos tags sem considerar os impactos na performance e na manutenção. Essa conversa, inclusive, começou lá no meu LinkedIn e ficamos um bom tempo debatendo os pontos de incoerência que encontramos. Vamos dar uma olhada:

E aí, você viu a imagem, mas consegue, antes de terminar de ler o artigo, identificar todos os pontos? Te desafio: pause agora e, apenas analisando a imagem, identifique todos os pontos errados encontrados nessa tag. Boa sorte! :)

Utilização de classes dinâmicas

Se você perceber, as classes utilizadas para definir os valores product_id, product_name, best_price_value e best_price são baseadas em classes dinâmicas. Vamos dar uma olhada:

var product_id = $('*.sc-lydpso-1 sc-1ps56m7-0').text().replace('ID: ', '');
var product_name = $('*.sc-lydpsno-1 .sc-1z0kxod-*').text();
var best_price_value = $('*.sc-lydpsmo-1 sc-1j8rlpu-1 ins').text().replace('R$', '');
var best_price = parseFloat(best_price_value.replace(",", "."));

Qual é o problema disso? Utilizar classes dinâmicas fornecidas por frameworks (Styled Components, React etc.) faz com que o valor em questão seja de baixíssima confiabilidade. Isso acontece devido a essas classes mudarem a cada vez que o site é alterado/buildado. Ou seja, esse é o típico caso em que você deveria usar um evento da camada de dados no lugar. Isso vai aumentar a consistência e, principalmente, a confiabilidade dessa informação. Bem citado pelo Fábio Bessa

Além disso, a maneira com que essa tag está capturando o valor best_price também vai gerar inconsistência quando o valor for acima de R$ 1.000,00, uma vez que ele quebraria completamente o valor, enviando uma informação incorreta para o evento. Isso foi muito bem apontado no LinkedIn pelo Raylan N. Silva.

Disparando eventos personalizados do Google Tag Manager para o próprio Google Tag Manager

Esse tipo de erro chega a dar arrepios. Entendo algumas exceções em que não temos acesso ao código-fonte, mas considere criar variáveis de JavaScript personalizadas para lidar com o tratamento de dados, ao invés de usar eventos sendo disparados de dentro do Google Tag Manager para o

dataLayer

. Isso vai melhorar a manutenibilidade do seu container e poupar muitas horas de debugging, evitando procurar um código que deveria estar no código-fonte, mas está dentro do container do Google Tag Manager. Principalmente considerando o nome da tag, que nem vou citar, mas adianto: não era nada explicativo.

Uso desnecessário de jQuery

É comum ver scripts personalizados dentro do GTM usando jQuery para capturar cliques ou manipular o DOM. Isso adiciona uma dependência externa que nem sempre está disponível em todas as páginas e que pode ser substituída por gatilhos nativos. Ou seja, se o Google Tag Manager já permite criar acionadores de maneira nativa, para que adicionar a dependência de um script externo para fazer exatamente o que o GTM foi feito para fazer? Esse erro me lembra os tempos do D.R.Y (Don't Repeat Yourself), um guia de boas práticas de otimização de código que usei bastante durante minha carreira.

Inimigos do primeiro clique

Como bem dito pelo nosso amigo Caique Dourado, caso essa implementação funcionasse, a tag em questão só dispararia o evento para a camada de dados na segunda vez que fosse clicada. Isso acontece porque, em vez de disparar diretamente a informação para a camada de dados, ela primeiro adiciona um listener para o comportamento. Ou seja, o usuário clica, ele cria o listener; quando clica a segunda vez, aí sim o evento é disparado. É rir para não chorar mesmo.

O pior de todos: a tag dispara o próprio gatilho

Chegou a notar isso? Bizarro, né? E, para ser sincero, é o problema mais estranho. Se unirmos isso ao fato de estar adicionando um listener na página, é o pior de todos os problemas. Imagine: a cada vez que o usuário clica no botão de adicionar o produto ao carrinho, será adicionado um novo listener ao clique do botão que, quando o usuário clicar, disparará o evento novamente, e novamente, e novamente, gerando quase que uma “explosão” no navegador do seu usuário devido à quantidade de listeners criados. Esse, inclusive, foi o único ponto que a galera do LinkedIn demorou um pouco para identificar. Um salve para o Rafael Pavelski, que foi o primeiro a acertar.

Esse comportamento é mais comum do que parece e, além de causar travamentos, pode:

Enviar dados duplicados ou inválidos para o Google Analytics.
Piorar o desempenho da página, especialmente em sites com muitas interações.

Uma implementação eficiente no GTM não depende apenas de configurar tags corretamente, mas também de evitar práticas que possam causar problemas de desempenho ou dificultar a manutenção. Ao substituir scripts personalizados por gatilhos nativos, usar seletores estáveis e evitar loops recursivos, você melhora a performance do site e simplifica o processo de gerenciamento.