Forcer une redirection vers une page de remerciement uniquement pour mesurer les conversions est souvent une approche “ancienne école”, pratique pour les configurations basiques, mais pas nécessairement la plus propre ni la plus fiable.
L’argument principal est simple : si le widget ou l’iframe remonte déjà un événement purchase fiable avec valeur, devise, transaction ID et items, la page de remerciement n’est pas indispensable.
La création d’une page de remerciement n’est pas une obligation technique pour mesurer les conversions. C’est une méthode simple, souvent utilisée pour des formulaires ou des configurations basiques, mais elle n’est pas forcément la plus fiable pour un paiement en ligne.
Dans le cas de 4escape, le tracking peut être configuré proprement via Google Tag Manager, soit en récupérant les variables post-paiement en mode iframe, soit via les événements dataLayer en mode widget. Cette approche permet de remonter un événement purchase avec les données utiles : montant, devise, identifiant de transaction et produits/réservations.
Une page de remerciement peut générer des doublons si elle est rechargée ou revisitée. À l’inverse, une configuration basée sur un événement purchase avec transaction_id est plus précise et plus conforme aux bonnes pratiques GA4 / Google Ads.
-----------------------------------------------------------------------------
1. Une conversion sérieuse ne doit pas dépendre uniquement d’une URL
Une page de remerciement mesure une page vue, pas forcément une transaction réelle. C’est acceptable pour un formulaire simple, mais beaucoup moins pour un paiement.
Google Ads indique lui-même que le tracking par URL est surtout adapté lorsqu’on veut suivre un chargement de page et qu’on n’a pas besoin de valeurs transactionnelles comme transaction_id ou paramètres personnalisés. À l’inverse, pour suivre une valeur, un identifiant de transaction ou d’autres paramètres, Google recommande une configuration par code / tag / GTM.
Lien: https://support.google.com/google-ads/answer/16560108?hl=en
-> Une page de remerciement peut suffire pour compter une demande de contact, mais pour une réservation payée, il vaut mieux suivre l’événement réel de paiement, avec son montant et son identifiant de transaction.
2. Le tracking événementiel est plus “pro” que le simple tracking de page
GA4 fonctionne sur une logique d’événements. Pour l’e-commerce, Google recommande de mesurer les étapes du parcours : ajout panier, début checkout, ajout d’informations de paiement, achat, remboursement, etc.
Lien: https://developers.google.com/analytics/devguides/collection/ga4/ecommerce?hl=fr
Le mode widget 4escape va précisément dans ce sens : il prévoit les événements add_to_cart, begin_checkout, add_payment_info, purchase, etc., avec des variables de couche de données comme ecommerce.value, ecommerce.currency, ecommerce.transaction_id et ecommerce.items.
-> Une page de remerciement ne donne qu’un signal final. Une configuration événementielle donne le tunnel complet : panier, checkout, paiement, achat. C’est plus exploitable pour GA4, Google Ads, Meta Ads et l’analyse marketing.
3. La page de remerciement augmente le risque de doublons
Une URL de remerciement peut être rechargée, ouverte depuis l’historique, copiée, partagée ou revisitée. Si le déclencheur est seulement basé sur l’URL, la conversion peut être comptée plusieurs fois.
Une configuration propre doit utiliser un transaction_id unique. Le mode iframe, 4escape expose justement un transactionId après paiement, et le déclencheur proposé vérifie que paymentSuccess = 1 et que transactionId n’est pas nul.
-> Ce n’est pas la page de remerciement qui rend le tracking fiable, c’est l’identifiant unique de transaction. Sans transaction_id, une page de remerciement peut même être moins fiable qu’un événement purchase bien configuré.
4. Une redirection ajoute une dépendance inutile dans le parcours utilisateur
Forcer une redirection après paiement ajoute une étape technique supplémentaire : chargement d’une nouvelle URL, dépendance au site client, éventuels problèmes de cache, consentement, scripts bloqués, lenteur, erreur 404, plugin WordPress, conflit JS, etc.
En mode widget, cette redirection n’a pas de justification forte puisque le tracking est prévu pour se faire directement sur le site via les événements envoyés au dataLayer.
-> On ne doit pas modifier le parcours de paiement uniquement pour satisfaire une méthode de tracking basique. Le tracking doit s’adapter au parcours utilisateur, pas l’inverse.
5. Une redirection peut perturber l’attribution
Une redirection post-paiement peut introduire des problèmes d’attribution : changement de domaine, retour depuis une plateforme de paiement, perte ou modification des paramètres de campagne, session coupée, self-referral, consentement différent entre les environnements, etc.
Cela ne veut pas dire qu’une redirection est toujours mauvaise, mais elle doit être justifiée. Si le purchase est déjà envoyé proprement avec value, currency, transaction_id et items, la redirection devient souvent une rustine inutile.
6. Le suivi par page de remerciement ne suffit pas pour optimiser Google Ads correctement
Google Ads peut mesurer une conversion par URL, mais cette méthode est limitée si l’on veut transmettre des valeurs dynamiques, un ID de transaction ou des paramètres avancés. Google précise que la méthode manuelle par code est adaptée lorsqu’on veut personnaliser le tag avec valeur, transaction ID ou paramètres personnalisés.
Lien: https://support.google.com/google-ads/answer/16560108?hl=en
-> Pour piloter correctement Google Ads, il ne suffit pas de dire “il y a eu une conversion”. Il faut idéalement transmettre combien elle vaut, quelle transaction elle concerne, et éviter les doublons.
Pour plus d'informations, ou si besoin d'assistance/accompagnement concernant le paramétrage de votre tracking, vous pouvez vous adresser directement à Olivier Dhennin - [email protected] qui pourra vous aider à ce sujet.