A pesquisa da loja no Google Analytics

Em resumo

• O painel da pesquisa responde a «como está a pesquisa». O Google Analytics responde a «quanto vale», porque é lá que estão as campanhas, as audiências e as conversões.
• Ligado o interruptor, cada acontecimento da pesquisa é entregue à própria página duas vezes: como evento do browser e como push para o dataLayer.
• Nada sai da página por esse caminho. Não se escrevem cookies nem se carregam scripts, e quem decide o que segue para o GA4 é o Tag Manager da loja.
• O evento mais útil é o menos glamoroso: uma pesquisa com zero resultados, registada com o termo que a pessoa escreveu.

O painel da pesquisa mostra os termos, os cliques e as pesquisas que acabam em nada. É a imagem certa para afinar a pesquisa, e é a imagem errada para responder a uma pergunta que aparece sempre: e no Google Analytics?

A pergunta é legítima e não é sobre teimosia. Uma ferramenta de pesquisa com relatório próprio é uma ferramenta que ninguém compara com nada, e as campanhas, as audiências, os funis e as conversões da loja vivem no GA4. O que não entra lá fica fora das contas que se fazem ao negócio, e uma ferramenta com relatório próprio é uma ferramenta que ninguém compara com nada.

O que muda quando se liga

Com o interruptor Enviar eventos para o analytics da loja ligado na ficha da loja, cada acontecimento da pesquisa passa a ser entregue à própria página, duas vezes e de duas formas. Vale para qualquer plataforma suportada, incluindo o módulo de pesquisa para PrestaShop:

• como evento do browser, com nomes do género buskara:search, para quem quiser ouvi-los com três linhas de JavaScript;
• como push para o dataLayer, com nomes do género buskara_search, que é o formato que o Google Tag Manager espera.

Vale a pena sublinhar o que não acontece. Este caminho não escreve cookies, não carrega scripts e não envia nada para fora da página. Põe a informação em cima da mesa da loja e sai da frente. Desligado o interruptor, o dataLayer fica exatamente como estava.

Os eventos

Duas notas sobre a tabela.

O search_id é o mesmo identificador que o painel usa. É o que permite pegar num número do GA4 e ir confrontá-lo com o mesmo número do outro lado, em vez de discutir qual das duas ferramentas está errada.

O buskara_add_to_cart conta a adição ao carrinho de uma sessão que pesquisou, venha ela do botão da pesquisa, do assistente ou do botão da própria loja depois de uma pesquisa. É deliberadamente generoso, e é preciso lê-lo assim: é influência da pesquisa, não atribuição apertada. A atribuição apertada faz-se do outro lado, como se explica em quem pesquisa compra mais.

Porque é que o buskara_search não dispara a cada tecla

Porque uma pesquisa escrita não é uma pesquisa por letra, e um relatório que confunda as duas coisas é pior do que não ter relatório.

Escrever «auscultadores» produz uma dúzia de estados intermédios, e só o último é o que a pessoa quis pesquisar. Se todos contassem, os «mais procurados» da loja seriam meias-palavras que ninguém escreveu de propósito, e a taxa de pesquisas sem resultados seria um número inventado pela velocidade a que cada visitante escreve.

Por isso o evento espera que a escrita assente. É uma decisão com consequência: o GA não tem forma de retratar um evento já enviado, e um número que se enche sozinho não se limpa depois.

Ligar, em três passos

1. Descarregar o container pronto no painel e importá-lo no Tag Manager. Traz as variáveis, os acionadores e as tags do GA4 já montados. A tabela completa dos eventos e dos parâmetros vive no guia dos eventos no GTM e GA4.
2. Abrir a variável do Measurement ID e substituir o valor de exemplo pelo da loja, que se encontra no GA4 em Administrador → Fluxos de dados.
3. Em Preview, fazer uma pesquisa na loja e confirmar que os eventos chegam. Depois, Submit.

Sem Tag Manager, os eventos do browser servem o mesmo propósito com muito pouco código:

document.addEventListener('buskara:search', function (e) {
  gtag('event', 'buskara_search', e.detail);
});

O consentimento é decisão da loja

As tags importadas vêm sem estado de consentimento definido, de propósito.

Não é uma omissão a corrigir: é o reconhecimento de que a política de consentimento é da loja e não de um fornecedor de pesquisa. O gating faz-se nas regras do próprio container, com o mesmo mecanismo de qualquer outra tag. Um fornecedor que decidisse isso por si estaria a assumir uma responsabilidade que continua, legalmente, do lado de quem tem a loja.

O caminho do dataLayer em si não escreve cookies nem identifica ninguém. O que precisa de consentimento é o que a loja decidir fazer com ele a seguir.

E o Microsoft Clarity

Há um segundo interruptor, independente do primeiro, para lojas que já usam o Microsoft Clarity. Com ele ligado, os mesmos eventos são entregues ao Clarity que estiver na página, e cada sessão fica marcada com duas etiquetas: o termo pesquisado e o nome do produto.

São as etiquetas que interessam, mais do que os eventos, porque é por elas que se filtram gravações de sessão e mapas de calor por aquilo que as pessoas pesquisaram. Ver meia dúzia de gravações de quem procurou um termo e saiu sem clicar em nada explica mais do que a coluna desse termo num relatório.

Duas limitações honestas: o Clarity não recebe parâmetros nos eventos, o que é da ferramenta e não desta integração, e daí as etiquetas; e a pesquisa nunca carrega o script do Clarity, portanto sem ele já na página o interruptor não faz nada.

Prós e contras de espelhar para o analytics da loja

O relatório que vale a pena montar primeiro

Se só houver tempo para um, é este: buskara_search filtrado por results = 0, com o search_term como dimensão.

É a lista do que os visitantes procuraram e a loja não serviu, escrita pelas palavras deles. No painel da pesquisa ela já existe, com classificação por tipo de problema e estimativa do que se recupera. O que muda ao tê-la também no GA4 é a companhia: passa a poder cruzar-se com a origem do tráfego, e a pergunta «que campanha está a trazer gente que procura o que não temos» deixa de ser retórica.

O tema tem artigo próprio, com as quatro causas e o que fazer a cada uma, em as pesquisas sem resultado são a lista de compras que ninguém lê.

Perguntas frequentes

Como levo a pesquisa interna para o Google Analytics 4?

Ligando o envio de eventos na ficha da loja e importando o container do Tag Manager que o painel disponibiliza. Os eventos chegam ao dataLayer da loja e é o Tag Manager que os encaminha para o GA4, com as regras de consentimento que a loja já tiver.

Estes eventos escrevem cookies ou seguem visitantes?

Este caminho não. Os eventos são entregues à própria página e mais nada sai dela. Cookies e identificação são o que as tags do GA4 fazem depois, sob as regras do container da loja, como com qualquer outra tag.

Porque é que o número de pesquisas do GA4 não bate certo com o do painel?

Quase sempre por causa do consentimento e dos bloqueadores. O painel conta as pesquisas que chegaram ao serviço; o GA4 conta as que as tags conseguiram enviar. O search_id está nos dois lados, e é por ele que se investiga uma diferença em vez de se adivinhar.

Vale a pena isto se a loja já tem o painel da pesquisa?

Vale se as decisões de marketing forem tomadas no GA4, o que é o caso da maioria. O painel é melhor para afinar a pesquisa; o GA4 é melhor para a comparar com tudo o resto que a loja faz. Não competem.

O que é o search_id?

Um identificador atribuído a cada pesquisa, presente nos eventos e nos relatórios do painel. Serve para ligar um clique, uma adição ao carrinho ou uma conversa à pesquisa concreta que os originou, em vez de os agrupar só pelo termo escrito.

Posso usar isto com o Microsoft Clarity em vez do Google Analytics?

Pode, e são interruptores independentes: um, o outro, ou os dois. O Clarity dá uma coisa que o GA4 não dá, que é ver a gravação da sessão de quem pesquisou um termo, e não dá parâmetros nos eventos, que é o que o GA4 faz melhor.