285 Membres en ligne
Apprenez à mettre en place des objectifs, le suivi ecommerce, vérifier l'exactitude des sources de trafic ou encore discuter des entonnoirs multicanaux, des objectifs, et le commerce électronique avancé
Guidez moi
star_border
Répondre

Remontée des données : Moins de déclanchement d'objectif que de réception de leads

Novice ✭ ✭ ✭

Bonjour à tous,

 

Je travail sur un site web dont son but est de générer des leads via des formulaires. J'ai de nombreux formulaires différents chacun traqué séparément via son objectif. Nous effectuons le tracking via GTM.

 

Mais il se trouve que je n'arrive pas à avoir une précision correcte entre la remontée des objectifs dans GA et les fichiers enregistrés sur mon serveur pour chaque demande.

 

  • Dans un premier test, en configurant les objectifs sur une page vue (une bête page de confirmation), j'avais systématiquement plus de réalisations d'objectif que de demandes réelles (variant de +1 à +6 sur environ une 50aine de demande par jours).

 

  • Dans un second test, on a poussé dans un DataLayer un Event spécifique dès que le formulaire fût validé puis enregistré sur le serveur. Ce qui m'a permis de déclencher une page virtuelle qui servira de page vue pour la réalisation des objectifs. Mais là, oh suprise, alors que cette méthode est censée être plus précise, j'obtenais systématiquement moins de réalisations d'objectif que je recevais de demandes réelles (variant de -6 à -10 sur environ une 50aine de demande par jours).

 

Je fait mon enquête, et ni l'échantillonnage, ni les filtre des vues, ni les segments, ni de regroupement de contenu n'impacte l'acquisition des données dans GA. J'ai isolé le problème vraiment au niveau de la récolte, donc au niveau du tag dans GTM.

 

Mais c'est là que mon souci grandi. J'ai analysé les demande que nous avons reçues mais qui n'ont pas été traquées dans GA, dans le but d'avoir un point commun entre-elles. Malheureusement, je n'ai rien pu trouvé. Le bug à l'aire d'être aléatoire et ne dépend ni d'un OS, ni d'un type d'appareil, ni d'un navigateur, rien...

 

Du coup, c'est pour ça que j'aurai besoin de votre aide :

  • Pour le premier test, est-ce qu'installer une redirection forcée sur la page de confirmation afin d'éviter le déclenchement de l'objectif si la personne arrivent directement sur la page pourrait ajuster de manière plus précise les données remontées?
  • A propos du second test, est-ce que quelqu'un pourrait savoir d'où viendrai le problème?
  • Si quelqu'un a déjà eu un problème semblable, comment a-t-il réussi à le contourner?
  • Et quel serait votre avis concernant l'utilisation d'une méthode "Server Side" en passant par le "Measurement Protocol" afin d'assurer un suivi ultra précis?

Dans l'attente de vos réponses, je vous remercie d'avance pour votre aide.

 

Bonne journée!

Réponses des expertsverified_user
1 SOLUTION APPROUVÉE

Solutions approuvées
Message signalé comme meilleure réponse.
Solution
Accepté par l'auteur du sujet Alexis B
août

Remontée des données : Moins de déclanchement d'objectif que de réception de leads

Novice ✭ ✭ ✭

Bonjour,

 

Un dernier message juste pour clôturer la discussion.

 

Après un bon mois de tests, de pose de traceurs dans tout les sens, de débogage, etc. Rien y fait, on arrive pas à trouver la source du problème. Par contre, on a pu l'isoler assez précisément et ça se trouve entre le moment du push du dataLayer et du catching par GTM, mais impossible de savoir pourquoi GTM n'arrive pas à récupérer les éléments du dataLayer, alors que le callback contenu dans ce dernier fonctionne parfaitement.

 

Enfin, on a mis de côté la résolution de ce problème pour passer par une requête en server side via le Measurement Protcole. Et là tout remonte nickel.

 

Encore merci pour votre aide.

 

A+

Voir la solution dans l'envoi d'origine

Remontée des données : Moins de déclanchement d'objectif que de réception de leads

Étudiant ✭ ✭

Bonjour Alexis. As-tu essayé pour le second test de mettre en place le goal directement à partir des évènements envoyées (sans passer par la page virtuelle) ? 

Remontée des données : Moins de déclanchement d'objectif que de réception de leads

Novice ✭ ✭ ✭

Bonjour Simon,

 

Merci pour ta réponse.

 

Non je n'ai pas testé la réception des évènements à la place d'une page virtuelle (à ne pas confondre avec l'event perso que j'utilise pour faire mon déclencheur dans GTM). Ceci principalement à cause du fait que j'aimerai conserver l'entonnoir de conversion vers l'objectif, qui n'est pas possible d'avoir via un objectif basé sur un event.

 

Du coup petite question: est-ce qu'un évènement remonterait plus "facilement" dans GA qu'une page vue?

Remontée des données : Moins de déclanchement d'objectif que de réception de leads

[ modifié ]
Étoiles Montantes

Bonjour Alexis,

 

Le problème reste le même avec un event GA ou avec une page vue.

 

Premier test
Il faudrait que tu fasses un audit de ton tracking pour savoir si tu ne déclenches pas de manière abusive le tracking (donc l'affichage de la page de confirmation) alors que la génération de leads n'est pas effective.
A moins que tu aies un problème technique d'enregistrement de tes leads, qui ne remontent donc pas dans ton back office.

J'espère que tu es dans le premier cas Smiley heureux

 

Seconde test
Cela ressemble plus au cas habituel avec un écart qui peut peut-être être réduit.


Il faudrait plus d'information sur l'implémentation :
A quel moment exactement est envoyé l'event perso GTM et est-il fait pour éviter :
- Un déclenchement juste avant un redirection vers une autre page ne garantissant pas que la requête ne soit annulée pas par le déchargement de la page (exemple : A la soumission du formulaire et juste avant redirection vers la page de confirmation)
- Trop de latence vis-à-vis de la sortie de l'utilisateur sur la page de confirmation (exemple : DOM ready sur la page de confirmation)

 

A ta disposition.

Mehdi Oudjida
Consultant web analytics
http://www.wissi.fr

Remontée des données : Moins de déclanchement d'objectif que de réception de leads

Novice ✭ ✭ ✭

Bonjour Mehdi,

 

Je te remercie pour ta réponse.

 

J'ai lu avec attention ce que tu m'as transmis et on a discuté avec les développeurs au sujet de tes pistes d'enquête.

 

Premier test

À ce sujet, on reviendra dessus si les corrections apportées au second test ne fonctionnent toujours pas. Mais on a identifié un truc tout bête, que nous n'avions pas pensé, c'est qu'il n'y a pas de "protection" de la page de confirmation pour empêcher l'atterrissage sur cette page et donc le déclenchement d'un objectif inattendu.

 

Second test

Là, ta phrase "Un déclenchement juste avant un redirection vers une autre page ne garantissant pas que la requête ne soit annulée pas par le déchargement de la page" m'a fait tilte.

En effet, on push le datalayer juste après la réception d'une requête JS de confirmation. Qui, elle, se fait juste avant la redirection vers la page de confirmation.

Du coup, on va tester avec les développeurs (je manque encore de connaissance sur l'aspect technique de la chose) ce qu'ils appellent une fonction de callback avec le push du datalayer. Ce qui nous permettra de stopper la redirection sur la page de confirmation tant que les tags ne se sont pas déclenché correctement.

 

Je te tiens au courant si cette méthode fonctionne.

 

Bonne soirée.

Message signalé comme meilleure réponse.
Solution
Accepté par l'auteur du sujet Alexis B
août

Remontée des données : Moins de déclanchement d'objectif que de réception de leads

Novice ✭ ✭ ✭

Bonjour,

 

Un dernier message juste pour clôturer la discussion.

 

Après un bon mois de tests, de pose de traceurs dans tout les sens, de débogage, etc. Rien y fait, on arrive pas à trouver la source du problème. Par contre, on a pu l'isoler assez précisément et ça se trouve entre le moment du push du dataLayer et du catching par GTM, mais impossible de savoir pourquoi GTM n'arrive pas à récupérer les éléments du dataLayer, alors que le callback contenu dans ce dernier fonctionne parfaitement.

 

Enfin, on a mis de côté la résolution de ce problème pour passer par une requête en server side via le Measurement Protcole. Et là tout remonte nickel.

 

Encore merci pour votre aide.

 

A+