Analyser ce que les gens écrivent dans le champ de recherche de votre site est à peu près l’une des choses les plus intelligentes que vous puissiez faire pour le suivi de votre site Web. Si certains termes apparaissent encore et encore dans les rapports de recherche internes, cela signifie que votre site ne fournit pas les réponses que les internautes recherchent, ce qui signifie que vous avez une excellente opportunité de répondre à la demande !
Cependant, toutes les applications de recherche de site ne sont pas traçables prêtes à l’emploi. Dans cet article, je passe en revue trois scénarios et je propose trois solutions pour résoudre les problèmes de recherche de site interne dans Google Tag Manager.
1) Aucun paramètre de requête dans l’URL
Les paramètres de recherche de site de Google Analytics nécessitent un paramètre de requête dans l’URL, par exemple https://www.simoahava.com/search?q=analytics. Souvent, cependant, l’outil de recherche de site n’applique pas de paramètre de requête à l’URL. Au lieu de cela, le mot-clé peut être un dossier d’URL typique, comme https://www.simoahava.com/search/analytics.
C’est assez banal. Vous avez peut-être vu ce phénomène sur les sites Web Drupal. C’est facile à corriger avec une macro d’URL et le page champ dans votre balise de page vue.
2) Aucun terme de recherche dans l’URL
C’est un peu plus difficile, car vous ne pouvez plus utiliser l’URL. Cela signifie que l’URL reste la même (ou a un chemin de recherche générique) et que vous devez examiner les éléments de la page pour obtenir des informations sur ce que l’utilisateur a recherché. Certains grattage DOM et le page terrain devrait faire l’affaire.
3) Rien sur la page à utiliser
C’est le scénario le plus difficile à gérer, car il n’y a rien sur la page auquel vous pouvez vous accrocher. Peut-être que le terme de recherche n’est pas itéré (stupide) ou qu’il n’est pas contenu dans un élément DOM (stupide, stupide). Cette fois, nous allons essayer d’obtenir la valeur du champ de recherche dans l’événement de soumission du formulaire et de la transmettre comme une page vue virtuelle.
1) Aucun paramètre de requête dans l’URL
Je vois ça assez souvent. Vous disposez d’un outil de recherche, mais il n’utilise pas de paramètre de requête pour le terme de recherche. Au lieu de cela, il affiche le mot-clé dans un dossier virtuel dans l’URI. Rien de mal à cela, même si chaque CMS devrait vous permettre de choisir comment les termes de recherche sont affichés dans l’URL.
Voici ce que vous allez faire :
-
Dans votre balise de page vue ordinaire, vous cliquez sur ouvrir le Champs à définir paramètre, et vous ajoutez un nouveau champ avec page comme nom de champ. La valeur du champ serait la référence à une macro JavaScript personnalisée
{{search path}}. -
Cette macro recherchera le terme de recherche dans l’URL
-
S’il trouve un terme de recherche, il renverra le chemin du document modifié avec le terme de recherche comme paramètre de requête
-
Si aucun terme de recherche n’est trouvé, la macro renvoie false, ce qui signifie que le chemin du document ne sera pas modifié et que la page vue se déclenchera normalement
C’est la beauté de GTM, encore une fois. Étant donné que la macro renvoie false pour les pages vues non liées à la recherche, vous n’aurez besoin que d’une balise de page vue unique, normale et ordinaire pour couvrir également toutes les recherches. Pas besoin de balises supplémentaires, woohoo !
Donc, disons que le terme de recherche du site est affiché comme il est affiché sur www.drupal.org : /search/site/mot-clé. Le {{search path}} La macro doit d’abord vérifier si l’URI commence par /search/site/, et si c’est le cas, elle doit renvoyer tout ce qui vient après, correctement modifié dans un chemin approprié.
Voici le code pour le {{search path}} macro :
function() { var regex = /^\/search\/site\/(.*)/; if(regex.test({{url path}})) { return "/search/site?q=" + regex.exec({{url path}})[1]; } return; } L’expression régulière regarde le {{url path}} macro (qui stocke l’URI actuel de la page), et si le chemin commence par /search/site/, il renvoie une version modifiée de l’URI avec le terme de recherche ajouté comme valeur du paramètre de requête q. Modifiez ce paramètre pour refléter tout ce que vous souhaitez avoir dans les paramètres de recherche de site de votre vue Google Analytics.
Enfin, modifiez simplement votre balise de page vue, ajoutez un nouveau champ à Champs à définirPositionner page comme nom de champ et ajoutez votre macro comme valeur. C’est tout ce qu’on peut en dire!
N’oubliez pas de faire un peu de prévisualisation et de débogage, et vérifiez également avec un débogueur comme WASP pour voir si le chemin est envoyé correctement pour les termes de recherche (et correctement pour toutes les autres pages également !).
2) Aucun terme de recherche dans l’URL
OK, celui-ci est un peu plus délicat. Dans ce cas, il n’y a pas de terme de recherche dans l’URL à utiliser. Cette solution nécessite que le terme de recherche soit explicitement présenté dans un élément HTML auquel nous pouvons nous accrocher. La meilleure façon est de l’avoir dans un span ou alors div avec un attribut ID unique. Comme c’est le meilleur moyen, c’est celui que j’utiliserai dans cet exemple, avec un <span> élément comme emballage. N’hésitez pas à faire preuve de créativité avec le DOM si votre terme de recherche est caché plus profondément dans la page.
Pour que cela fonctionne, voici ce qui se passe :
-
Dans votre balise de page vue ordinaire, vous cliquez sur ouvrir le Champs à définir paramètre, et vous ajoutez un nouveau champ avec page comme nom de champ. La valeur du champ serait la référence à une macro JavaScript personnalisée
{{search path}} -
Cette macro recherchera le terme de recherche dans l’élément HTML avec l’ID que vous spécifiez, en utilisant une nouvelle macro d’élément DOM
{{search term}} -
S’il trouve un terme de recherche, le
{{search path}}macro renverra le chemin du document modifié avec le terme de recherche comme paramètre de requête -
Si aucun terme de recherche n’est trouvé, la macro renvoie false, ce qui signifie que le chemin du document ne sera pas modifié et que la page vue se déclenchera normalement
Tout d’abord, créons la macro d’élément DOM {{search term}}.
Remplace le ID d’élément champ avec tout ce que votre page utilise.
Ensuite, nous devrons modifier la macro JavaScript personnalisée {{search path}}:
function() { if({{search term}} && {{search term}} !== 'null') { return "/search/site?q=" + {{search term}}; } return; } Donc, nous vérifions d’abord si un élément avec l’ID que vous spécifiez existe. Si c’est le cas, la macro renvoie "/search/site?q=<keyword>" comme chemin du document, comme dans l’exemple précédent. Si aucun élément de ce type n’est trouvé, la macro renvoie false et le chemin du document d’origine (c’est-à-dire l’URI de la page sur laquelle se trouve le visiteur) est envoyé.
La dernière étape est la même qu’auparavant : modifiez votre balise de page vue, ajoutez un nouveau champ à la Champs à définirdéfinissez le nom du champ sur pageet ajoutez ceci {{search path}} macro comme valeur de champ.
Oh, et n’oubliez pas de prévisualiser, de déboguer et de tester, tester, tester.
3) Rien sur la page à utiliser
C’est sombre, mais ça arrive. Il y a absolument rien dans le modèle d’objet de document que vous pouvez utiliser pour saisir le terme de recherche. L’URL est vide, il n’y a pas de terme de recherche imprimé sur la page, pas de fées qui murmurent à votre oreille, RIEN. Je sais, ça craint. Virez votre développeur. Je rigole. Non, sérieusement, virez-les. Ouais, je plaisante.
J’ai choisi de résoudre ce problème en utilisant le suivi des formulaires. Cela nécessite essentiellement que votre champ de recherche ait un identifiant unique que vous pouvez saisir dans l’événement de soumission. J’espère que vous avez un ID approprié pour le champ (ou au moins une CLASSE ou un NOM !). J’utilise ID ici, encore une fois, mais n’hésitez pas à modifier le script pour obtenir la valeur de la page.
Le fait est que vous devrez envoyer une page vue virtuelle avec la soumission du formulaire, et elle contiendra le terme de recherche dans le chemin du document, comme dans les exemples précédents. Cependant, si vous envoyez une nouvelle page vue avec la recherche, vous compterez deux fois vos vues de recherche, puisque vous enverrez également une page vue lorsque la page de recherche se chargera ! Vous ne voulez pas ça. C’est pourquoi ce cas est un peu plus complexe, car vous allez utiliser un cookie du navigateur pour transporter le terme de recherche dans la page de recherche, afin que vous puissiez ensuite l’utiliser comme chemin d’accès au document.
Voici ce qui se passe :
-
Avoir une balise Form Submit Listener déclenchée sur toutes les pages
-
Créez une nouvelle balise HTML personnalisée qui se déclenche
{{event}}est égal à gtm.formSubmitc’est-à-dire lorsqu’un formulaire est soumis -
Dans cette balise, vérifiez qu’une recherche a été effectuée et récupérez le terme de recherche à l’aide d’une macro d’élément DOM
{{search field value}} -
Dans la balise, enregistrez ce terme de recherche dans un nouveau cookie de navigateur nommé “mot clé”
-
Créer une nouvelle macro de cookie propriétaire
{{cookie search term}}qui récupère cette valeur de cookie -
Dans le
{{search path}}Macro JavaScript personnalisée, vérifiez si le cookie existe ; si c’est le cas, utilisez-le comme chemin de page virtuel -
Utiliser
{{search path}}comme la valeur d’un nouveau champ dans le Champs à définir paramètres de la balise. Définissez le nom du champ sur page et la macro comme valeur de champ. -
Créer une nouvelle macro JavaScript personnalisée
{{searchCallback}}qui supprime le cookie dans la fonction de rappel de la balise de consultation de page
PHEW!
Tout d’abord, l’écouteur de soumission de formulaire. C’est simple, il suffit de créer une nouvelle balise de type Form Submit Listener et de la faire se déclencher sur toutes les pages.
Après cela, créez la macro d’élément DOM {{search field value}}. Assurez-vous de changer le ID d’élément paramètre sur l’ID du champ de formulaire que votre page Web utilise dans la recherche de site.
Ensuite, créez une nouvelle balise HTML personnalisée qui se déclenche sur {{event}} est égal à gtm.formSubmit. Avoir le code suivant à l’intérieur :
<script> if({{search field value}} && {{search field value}} !== 'null') { document.cookie = "keyword="+{{search field value}}+";path=/"; } </script>Ici, nous recherchons un élément HTML avec l’ID “champ de recherche” et avec un attribut VALUE. S’il est trouvé, le contenu de cet attribut est défini dans un nouveau cookie nommé “mot-clé”. Il s’agit, en fait, de ce qui a été tapé dans le champ de recherche au moment de la soumission du formulaire.
(REMARQUE! S’il y a plusieurs formulaires sur une page, vous souhaiterez peut-être améliorer cette balise en vérifiant qu’il s’agit bien du formulaire de recherche qui a été soumis. Il est possible qu’un autre formulaire soit soumis avec du texte dans le champ de recherche, et ce script interpréterait alors faussement cet événement comme une soumission du formulaire de recherche du site.)
Ensuite, créez une nouvelle macro de cookie propriétaire, qui récupère la valeur du cookie « mot clé ». Appelez ça {{cookie search term}}.
Ensuite, modifiez la macro JavaScript personnalisée {{search path}} ressembler à ceci :
function() { if({{cookie search term}}) { return "/search/site?q=" + {{cookie search term}}; } return; } Donc, nous vérifions d’abord si le cookie existe. Si tel est le cas, sa valeur est renvoyée sous la forme d’un chemin d’accès au document correctement formaté pour la balise de consultation de page.
Enfin, créez une nouvelle macro JavaScript personnalisée {{searchCallback}}qui ressemble à ceci :
function() { if({{cookie search term}}) { return function() { document.cookie = "keyword=;path=/;expires=Thu, 01-Jan-70 00:00:01 GMT"; } } return; } Cela recherche le cookie “mot-clé”, et s’il en trouve un, le cookie est supprimé. Ceci est extrêmement important, car vous ne voulez pas continuer à envoyer la page virtuelle à chaque chargement de page ! Les cookies sont supprimés en définissant leur date d’expiration dans le passé.
Rassemblez tout cela dans votre balise de page vue, en utilisant le Champs à définir avec les deux hitCallback et page peuplé en conséquence.
Pourquoi supprimer le cookie dans le hitCallback et non dans la macro qui renvoie le chemin du document ? Eh bien, deux raisons :
-
Une macro ne doit pas être utilisée pour définir quoi que ce soit. La macro de rappel est évidemment une exception, car elle RETOURNE une fonction qui définit quelque chose.
-
Il y a une condition de concurrence étrange en jeu, et si vous vous référez à la macro 1st Party Cookie dans le même script qui supprime également le cookie, la macro renvoie un indéfini. Je vais devoir étudier un peu plus ce phénomène.
C’était beaucoup plus difficile que les autres méthodes, et avouons-le : si vous avez besoin de recourir à la soumission de formulaire, vous devriez probablement fouetter votre développeur en premier. Faites-leur créer un moteur de recherche de site qui fonctionne réellement avec des analyses, car c’est vraiment l’une des meilleures choses que vous puissiez mesurer.
conclusion
J’attendais depuis longtemps un article de tutoriel traditionnel, alors j’espère que vous avez apprécié celui-ci. Je travaille toujours sur le JavaScript pour GTM : Partie 2 (consultez la partie 1 ici), mais maintenant je rêve aussi des mini-vacances qui commencent demain.
Cependant, si cet article soulève des questions, si vous avez d’autres idées pour suivre la recherche sur le site ou si vous avez un problème pour lequel vous avez besoin d’aide, n’hésitez pas à laisser une ligne ci-dessous dans les commentaires ! Rien de tel qu’un défi JavaScript pour rendre l’été plus amusant.
Passez un bel été chaud et relaxant, mes amis! Vivez pleinement votre vie et rêvez de JavaScript et de toutes les choses merveilleuses.
