La recherche de la boutique dans Google Analytics

En bref

• Le panneau de la recherche répond à « comment va la recherche ». Google Analytics répond à « combien elle vaut », parce que c'est là que sont les campagnes, les audiences et les conversions.
• L'interrupteur activé, chaque événement de la recherche est livré à la page elle-même deux fois : comme événement du navigateur et comme push vers le dataLayer.
• Rien ne sort de la page par ce chemin. On n'écrit pas de cookies et on ne charge pas de scripts, et celui qui décide de ce qui part vers GA4, c'est le Tag Manager de la boutique.
• L'événement le plus utile est le moins glamour : une recherche à zéro résultat, enregistrée avec le terme que la personne a écrit.

Le panneau de la recherche montre les termes, les clics et les recherches qui finissent en rien. C'est la bonne image pour régler la recherche, et c'est la mauvaise image pour répondre à une question qui revient toujours : et dans Google Analytics ?

La question est légitime et ce n'est pas de l'entêtement. Un outil de recherche avec son propre rapport est un outil que personne ne compare à rien, et les campagnes, les audiences, les tunnels et les conversions de la boutique vivent dans GA4. Ce qui n'y entre pas reste en dehors des comptes que l'on fait pour l'activité, et un outil avec son propre rapport est un outil que personne ne compare à rien.

Ce qui change quand on l'active

Avec l'interrupteur Envoyer les événements vers l'analytics de la boutique activé sur la fiche de la boutique, chaque événement de la recherche est désormais livré à la page elle-même, deux fois et de deux façons. Cela vaut pour n'importe quelle plateforme prise en charge, y compris le module de recherche pour PrestaShop :

• comme événement du navigateur, avec des noms du genre buskara:search, pour qui veut les écouter avec trois lignes de JavaScript ;
• comme push vers le dataLayer, avec des noms du genre buskara_search, qui est le format que le Google Tag Manager attend.

Il vaut la peine de souligner ce qui n'arrive pas. Ce chemin n'écrit pas de cookies, ne charge pas de scripts et n'envoie rien hors de la page. Il pose l'information sur la table de la boutique et s'écarte. L'interrupteur désactivé, le dataLayer reste exactement comme il était.

Les événements

Deux notes sur le tableau.

Le search_id est le même identifiant que celui qu'utilise le panneau. C'est ce qui permet de prendre un chiffre de GA4 et d'aller le confronter au même chiffre de l'autre côté, au lieu de discuter pour savoir lequel des deux outils se trompe.

Le buskara_add_to_cart compte l'ajout au panier d'une session qui a cherché, qu'il vienne du bouton de la recherche, de l'assistant ou du bouton de la boutique elle-même après une recherche. Il est délibérément généreux, et il faut le lire ainsi : c'est de l'influence de la recherche, pas de l'attribution serrée. L'attribution serrée se fait de l'autre côté, comme on l'explique dans qui cherche achète plus.

Pourquoi le buskara_search ne se déclenche pas à chaque touche

Parce qu'une recherche écrite n'est pas une recherche par lettre, et qu'un rapport qui confond les deux choses est pire que pas de rapport du tout.

Écrire « écouteurs » produit une douzaine d'états intermédiaires, et seul le dernier est ce que la personne a voulu chercher. Si tous comptaient, les « plus recherchés » de la boutique seraient des demi-mots que personne n'a écrits exprès, et le taux de recherches sans résultat serait un chiffre inventé par la vitesse à laquelle chaque visiteur écrit.

C'est pourquoi l'événement attend que la frappe se pose. C'est une décision qui a des conséquences : GA n'a aucun moyen de retirer un événement déjà envoyé, et un chiffre qui se remplit tout seul ne se nettoie pas après coup.

Activer, en trois étapes

1. Télécharger le container prêt à l'emploi dans le panneau et l'importer dans le Tag Manager. Il apporte les variables, les déclencheurs et les tags GA4 déjà montés. Le tableau complet des événements et des paramètres vit dans le guide des événements dans GTM et GA4.
2. Ouvrir la variable du Measurement ID et remplacer la valeur d'exemple par celle de la boutique, qui se trouve dans GA4 sous Administrateur → Flux de données.
3. Dans Preview, faire une recherche sur la boutique et confirmer que les événements arrivent. Ensuite, Submit.

Sans Tag Manager, les événements du navigateur remplissent le même rôle avec très peu de code :

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

Le consentement est une décision de la boutique

Les tags importées arrivent sans état de consentement défini, et c'est voulu.

Ce n'est pas un oubli à corriger : c'est la reconnaissance que la politique de consentement appartient à la boutique et non à un fournisseur de recherche. Le gating se fait dans les règles du container lui-même, avec le même mécanisme que pour n'importe quelle autre tag. Un fournisseur qui déciderait cela à sa place assumerait une responsabilité qui reste, légalement, du côté de celui qui possède la boutique.

Le chemin du dataLayer en lui-même n'écrit pas de cookies et n'identifie personne. Ce qui a besoin de consentement, c'est ce que la boutique décidera d'en faire ensuite.

Et Microsoft Clarity

Il y a un second interrupteur, indépendant du premier, pour les boutiques qui utilisent déjà Microsoft Clarity. Une fois activé, les mêmes événements sont livrés au Clarity présent sur la page, et chaque session est marquée de deux étiquettes : le terme recherché et le nom du produit.

Ce sont les étiquettes qui comptent, plus que les événements, parce que c'est par elles que l'on filtre les enregistrements de session et les cartes de chaleur selon ce que les gens ont cherché. Voir une demi-douzaine d'enregistrements de personnes qui ont cherché un terme et sont parties sans cliquer sur rien explique plus que la colonne de ce terme dans un rapport.

Deux limites honnêtes : Clarity ne reçoit pas de paramètres dans les événements, ce qui vient de l'outil et non de cette intégration, d'où les étiquettes ; et la recherche ne charge jamais le script de Clarity, donc sans lui déjà sur la page l'interrupteur ne fait rien.

Pour et contre le fait de refléter vers l'analytics de la boutique

Le rapport qui vaut la peine d'être monté en premier

S'il n'y a de temps que pour un seul, c'est celui-ci : buskara_search filtré par results = 0, avec le search_term comme dimension.

C'est la liste de ce que les visiteurs ont cherché et que la boutique n'a pas servi, écrite avec leurs mots à eux. Dans le panneau de la recherche elle existe déjà, avec un classement par type de problème et une estimation de ce que l'on récupère. Ce qui change en l'ayant aussi dans GA4, c'est la compagnie : elle peut désormais être croisée avec la source du trafic, et la question « quelle campagne amène des gens qui cherchent ce que nous n'avons pas » cesse d'être rhétorique.

Le sujet a son propre article, avec les quatre causes et quoi faire pour chacune, dans les recherches sans résultat sont la liste de courses que personne ne lit.

Questions fréquentes

Comment amener la recherche interne dans Google Analytics 4 ?

En activant l'envoi des événements sur la fiche de la boutique et en important le container du Tag Manager que le panneau met à disposition. Les événements arrivent dans le dataLayer de la boutique et c'est le Tag Manager qui les achemine vers GA4, avec les règles de consentement que la boutique a déjà.

Ces événements écrivent-ils des cookies ou suivent-ils les visiteurs ?

Pas par ce chemin. Les événements sont livrés à la page elle-même et rien d'autre n'en sort. Les cookies et l'identification sont ce que les tags GA4 font ensuite, sous les règles du container de la boutique, comme avec n'importe quelle autre tag.

Pourquoi le nombre de recherches de GA4 ne correspond-il pas à celui du panneau ?

Presque toujours à cause du consentement et des bloqueurs. Le panneau compte les recherches qui sont arrivées au service ; GA4 compte celles que les tags ont réussi à envoyer. Le search_id est des deux côtés, et c'est par lui que l'on enquête sur un écart au lieu de le deviner.

Cela vaut-il la peine si la boutique a déjà le panneau de la recherche ?

Cela vaut la peine si les décisions marketing se prennent dans GA4, ce qui est le cas de la majorité. Le panneau est meilleur pour régler la recherche ; GA4 est meilleur pour la comparer à tout le reste de ce que fait la boutique. Ils ne sont pas en concurrence.

Qu'est-ce que le search_id ?

Un identifiant attribué à chaque recherche, présent dans les événements et dans les rapports du panneau. Il sert à relier un clic, un ajout au panier ou une conversation à la recherche concrète qui les a produits, au lieu de les regrouper seulement par le terme écrit.

Puis-je utiliser cela avec Microsoft Clarity au lieu de Google Analytics ?

Oui, et ce sont des interrupteurs indépendants : l'un, l'autre, ou les deux. Clarity donne une chose que GA4 ne donne pas, qui est de voir l'enregistrement de la session de celui qui a cherché un terme, et il ne donne pas de paramètres dans les événements, ce que GA4 fait mieux.