Diagnostiquer les référents de paiement dans GA4 pour un site d’événement

Confirmer le retour que GA4 peut observer

Télécharger la feuille de diagnostic des référents de paiement (Markdown en anglais)

Ouvrez la page publique comme un visiteur et suivez le véritable bouton de billetterie. Notez chaque domaine dans l’ordre : page de l’événement, formulaire, paiement, confirmation et éventuel retour au site de l’organisateur. Vérifiez si GA4 est présent sur la page de retour et si le prestataire permet de configurer des balises ou une URL de retour. Certains parcours ne reviennent jamais. Dans ce cas, un référent de paiement aperçu ailleurs dans GA4 demande une autre explication ; exclure un domaine ne crée pas les événements de commande manquants.[1]

Décrire le symptôme avec la portée du rapport

Sur une période GA4 terminée, relevez la propriété, le flux Web, les dates, le rapport et la ligne exacte Source/Support de la session qui semble erronée. L’acquisition par session est le point de départ pour un nouveau référent ; Première source de l’utilisateur et l’attribution au niveau des événements répondent à d’autres questions. Consignez la page d’arrivée et le domaine de paiement, sans identité d’acheteur. Sauvegardez le réglage actuel avant toute modification. Demandez aux responsables de la billetterie et du site si ce domaine est une étape de paiement, un second site à vous ou un partenaire qui apporte réellement des visiteurs.[3][1]

Classer le domaine avant de choisir la solution

Jugez le trajet plutôt que le nom seul. Un processeur de paiement externe qui renvoie vers le site balisé est l’exemple de référent indésirable cité par Google. Un lieu, sponsor, média ou annuaire qui envoie des visiteurs vers l’événement est une véritable source d’acquisition et doit rester visible. Si page et paiement sont deux domaines légitimement balisés avec le même identifiant de flux Web GA4, la mesure multidomaine peut préserver un parcours compatible. Elle suppose un balisage et une navigation compatibles sur les deux domaines ; elle ne donne aucun contrôle sur le paiement d’un prestataire externe. GA4 écarte déjà automatiquement beaucoup d’autoréférents du même domaine et de ses sous-domaines. Vérifiez donc le symptôme dans des sessions récentes.[1][2]

Imaginez une personne ouvrant un lien de campagne vers un festival, achetant sur une plateforme de billetterie, puis arrivant sur la page de remerciement de l’organisateur. Si GA4 sur cette page de retour indique le domaine de paiement comme nouvelle source de session, ce retour relève de ce diagnostic. Si la confirmation reste uniquement chez le prestataire, le GA4 de l’organisateur ne voit jamais cette page et sa liste des référents n’est pas la solution. Dans les deux cas, le registre de commandes du prestataire reste la preuve qu’un billet a été émis.[1][2]

Appliquer une seule correction étroite et justifiée

Pour un retour de paiement confirmé, un éditeur GA4 autorisé peut ouvrir Administration → Flux de données → flux Web → Configurer les paramètres de la balise → Tout afficher → Référents indésirables. Choisissez une condition de domaine aussi étroite que le permet la preuve, conservez l’ancien réglage et notez le nouveau. N’excluez pas tout le domaine du prestataire simplement parce que le bouton y mène : prouvez qu’il apparaît comme référent au retour vers votre site balisé. Si les deux domaines autorisent une mesure commune, suivez la procédure multidomaine distincte de Google et contrôlez le paramètre de liaison à l’arrivée. Ces réglages ne sont pas interchangeables.[1][2]

Tester le trajet et lire les nouvelles données traitées

Utilisez un parcours de test approuvé, par exemple un environnement de test du prestataire ou un retour sans achat, en respectant les choix de consentement habituels. Partez d’une entrée connue sur la page, notez l’URL de billetterie, le domaine de paiement, l’URL de retour et la présence d’une page vue sur votre site. Testez une autre méthode de paiement et une annulation si elles existent. DebugView peut confirmer les événements de votre appareil de test, mais Google précise que son analyse d’attribution est limitée ; examinez ensuite les nouvelles données traitées de Source/Support de la session dans Acquisition de trafic. Comparez une portée et une période identiques au point de départ. Les anciens rapports ne sont pas réécrits et une source attribuée auparavant peut encore apparaître pour des visiteurs revenant. Une ligne de référent plus nette ne prouve pas que les commandes sont suivies : rapprochez-les séparément du prestataire et gardez ouverts les défauts de retour ou d’intégration.[5][4][1]