Analysez vos paiements dans vos propres outils analytics
rgive pousse automatiquement vos données de paiement vers Google Tag Manager (GTM) ou Matomo Tag Manager (MTM). Ce guide vous explique comment les brancher, les configurer et les exploiter dans vos outils analytics — sans écrire une seule ligne de code.
Pas développeur ? Ce guide est fait pour vous. rgive ne permet pas d'injecter du code personnalisé — et c'est une bonne chose pour la sécurité de vos payeurs. GTM et MTM ont précisément été conçus pour que des équipes non-techniques puissent gérer le tracking de façon autonome, sans solliciter un développeur à chaque campagne.
Connecter votre outil de tracking
rgive s'intègre nativement avec Google Tag Manager (GTM) et Matomo Tag Manager (MTM). Il vous suffit de renseigner quelques champs dans votre back-office — aucune ligne de code à toucher.
Obligation légale — mettez en place une CMP
Avant de renseigner votre identifiant GTM ou MTM, assurez-vous d'avoir mis en place une solution de gestion du consentement (CMP) sur votre site. C'est un prérequis légal, pas une option.
Renseignez vos identifiants dans rgive
Format GTM-XXXXXXX, disponible en haut à droite de votre espace de travail sur tagmanager.google.com.
Configuration proxy (avancé) : si votre organisation héberge un serveur GTM côté serveur (server-side tagging), renseignez l'URL de ce serveur dans le champ prévu à cet effet. Cette configuration améliore la conformité RGPD et contourne les bloqueurs de publicité. Laissez ce champ vide si vous n'êtes pas concerné.
URL complète du script MTM. Disponible dans Matomo → Administration → Tag Manager → Installer.
Ajoutez automatiquement des informations propres à votre organisation dans tous vos événements analytics — sans les reconfigurer dans chaque balise GTM ou MTM. Elles sont injectées une seule fois, au chargement du formulaire.
Chaque ligne est une paire Clé (le nom que vous choisissez) + Valeur (son contenu). Ces données accompagnent tous vos événements automatiquement.
integration — sans rien configurer ici. Les valeurs additionnelles sont utiles principalement pour les organisations qui gèrent plusieurs entités distinctes (causes abritées, sous-égide…) et veulent les distinguer dans leurs rapports.GTM ou MTM, lequel choisir ?
rgive supporte les deux solutions. Voici les différences essentielles pour faire le bon choix selon vos contraintes et les valeurs de votre organisation.
- Écosystème Google natif (GA4, Ads, Search Console…)
- Interface très répandue, tutoriels abondants
- Mode Aperçu (Preview) pour débugger en temps réel
- Marketplace de templates communautaires
- Option server-side tagging disponible
- 100 % open source, code auditable publiquement
- Données hébergées sur vos propres serveurs
- RGPD natif — aucun partage avec des tiers
- Intégré à l'écosystème Matomo Analytics
- Idéal secteur public et associations exigeantes
Rappel : quel que soit l'outil choisi, une CMP doit être active sur votre site avant de publier votre container en production. Voir la section Mise en place pour les détails.
Pourquoi rgive n'accepte pas de code personnalisé ?
rgive a fait le choix délibéré de ne permettre aucune injection de JavaScript, HTML ou CSS. Ce n'est pas une limitation — c'est une décision d'architecture qui protège vos payeurs et la pérennité de votre intégration.
Les 3 événements du parcours payeur (paiement)
rgive pousse automatiquement ces événements dans le dataLayer à chaque étape clé du parcours. Vous n'avez pas à les déclencher manuellement — il vous suffit de créer les déclencheurs correspondants dans GTM ou MTM.
Les noms purchase, items, value, currency, transaction_id et generate_lead suivent la convention e-commerce de Google Analytics 4, reconnue nativement par la plupart des outils analytics. Cette documentation ne couvre pas la configuration de ces outils.
Déclenché à chaque chargement d'étape du formulaire de paiement : choix du montant, coordonnées, informations de paiement. La variable step indique l'étape en cours (amount, contact, payment, payment-details). C'est l'événement de référence pour suivre la progression du payeur dans le tunnel. L'étape payment-details correspond à l'écran de finalisation propre au moyen de paiement choisi (par exemple les instructions pour un chèque ou un virement). Elle n'apparaît pas pour tous les moyens de paiement.
checkout, puis associez-le à votre balise.Déclenché quand un paiement est confirmé avec un paiement immédiat : carte bancaire, PayPal, Apple Pay, Google Pay, prélèvement SEPA. C'est l'événement de conversion principal. Un rechargement de la page de confirmation ne génère pas de second purchase : chaque transaction n'est comptée qu'une fois.
Déclenché quand un payeur fait une promesse de paiement à paiement différé : chèque envoyé par courrier ou virement bancaire à effectuer. Le prélèvement SEPA génère un événement purchase, pas un pledge. Le payload de pledge ne contient ni step ni conversion_url.
purchase couvre tout paiement immédiat (CB, PayPal, SEPA…). pledge couvre uniquement les promesses à paiement différé (chèque, virement). Pour plus de détails, voir la FAQ.purchase. Vos chiffres de paiements et de revenus dans vos outils analytics sont fiables sans traitement particulier.Toutes les variables disponibles
rgive enrichit chaque événement avec des variables décrivant précisément le paiement, la campagne et le payeur. Dans GTM ou MTM, créez une « Variable de couche de données » pour chaque propriété que vous souhaitez exploiter dans vos rapports.
items sont des propriétés imbriquées dans le tableau e-commerce — elles ne nécessitent pas de variables de couche de données séparées dans GTM.| Variable | Clé dataLayer | Type | Description | Exemple / Valeurs | Événements |
|---|---|---|---|---|---|
| campaign_id | ecommerce.campaign_id | String | Code de la campagne tel que renseigné dans le back-office. Vide ("") si aucun code n'est renseigné. | CAMP_123 | checkout, purchase, pledge |
| campaign_uuid | ecommerce.campaign_uuid | String | Identifiant technique de la campagne (6 premiers caractères de son UUID). Toujours renseigné, même sans code de campagne. | 0ebf97 | checkout, purchase, pledge |
| campaign_name | ecommerce.campaign_name | String | Nom de la campagne | Don été 2025 | checkout, purchase, pledge |
| campaign_type | ecommerce.campaign_type | String | Type de campagne | donation·membership·subscription·payment | checkout, purchase, pledge |
| campaign_media_code | ecommerce.campaign_media_code | String | Code média de la campagne. Facultatif, saisi dans le back-office. Vide ("") si non renseigné. | EMAIL_MAI | checkout, purchase, pledge |
| campaign_origin_code | ecommerce.campaign_origin_code | String | Code origine de la campagne. Facultatif, saisi dans le back-office. Vide ("") si non renseigné. | NEWSLETTER | checkout, purchase, pledge |
| campaign_assignment_code | ecommerce.campaign_assignment_code | String | Code d'affiliation de la campagne. Facultatif, saisi dans le back-office. Vide ("") si non renseigné. | FH | checkout, purchase, pledge |
| integration | ecommerce.integration | String | Mode d'intégration du formulaire | page·overlay·embed | checkout, purchase, pledge |
| form_type | ecommerce.form_type | String | Format du formulaire de paiement | 3-step·express | checkout, purchase, pledge |
| step | ecommerce.step | String | Étape actuelle du formulaire au moment de l'événement | amount·contact·payment·payment-details·push-regular1 | checkout, purchase |
| firststep | ecommerce.firststep | String | Étape par laquelle le payeur est arrivé directement sur le formulaire | amount·contact·payment | checkout, purchase, pledge |
| donation_type | ecommerce.donation_type | String | Fréquence du paiement | one-off·monthly | checkout, purchase, pledge |
| amount_type | ecommerce.amount_type | String | Montant choisi dans la grille ou personnalisé | default·custom | checkout, purchase, pledge |
| initial_amount | ecommerce.initial_amount | Float | Montant initialement choisi avant le déclenchement éventuel du widget push don régulier. Absent du payload si le widget ne s'est pas déclenché ou si le payeur maintient le don ponctuel. | 23 | checkout, purchase, pledge |
| payment_method | ecommerce.payment_method | String | Moyen de paiement utilisé | Carte Bancaire·PayPal·Apple Pay·Google Pay·IBAN·Virement·cheque | purchase, pledge |
| donor_email | ecommerce.donor_email | String | Email du payeur. Renseigné dès le premier checkout quand l'email est déjà connu (paramètre URL, ou session en cours après une signature de pétition par exemple), sinon complété à la confirmation. Donnée personnelle : vérifiez que vos outils de destination sont autorisés à la recevoir. | contact@exemple.fr | checkout, purchase, pledge |
| affiliation | ecommerce.affiliation | String | Nom de l'organisation collectrice. Utile quand une association crée des formulaires pour des entités abritées ou sous-égide — permet de distinguer l'entité concernée dans les rapports. | NOM MARQUE | checkout, purchase, pledge |
| referrer_url | ecommerce.referrer_url | String | URL de la page d'origine du visiteur avant son arrivée sur votre site : moteur de recherche, réseau social, autre site. Fiabilisée sur l'ensemble du parcours. Vide en accès direct. | https://www.google.com/ | checkout, purchase, pledge |
| landing_url | ecommerce.landing_url | String | URL complète de la page par laquelle le visiteur est entré sur votre site pour la visite en cours, paramètres UTM inclus. Permet une attribution marketing fiable même quand le formulaire n'est pas la première page vue. | https://don.votreasso.fr/?utm_source=newsletter&utm_medium=email&utm_campaign=relance-don | checkout, purchase, pledge |
| conversion_url | ecommerce.conversion_url | String | URL de la page sur laquelle le paiement a été confirmé. Absente sur les promesses de paiement (chèque, virement). | https://don.votreasso.fr/campagne/merci | purchase |
| type | ecommerce.type | String | Type de don (dédicace, mémoire) | dédicace·en mémoire | purchase, pledge |
| value | ecommerce.value | Float | Montant du paiement | 23.0 | checkout, purchase, pledge |
| currency | ecommerce.currency | String | Devise au format ISO | EUR·USD·GBP | checkout, purchase, pledge |
| transaction_id | ecommerce.transaction_id | String | Identifiant unique du paiement | a1b2c3d4-e5f6-... | purchase, pledge |
| items | ecommerce.items | Array | Tableau des articles au format e-commerce standard. Contient les sous-variables item_id, item_name, affiliation, item_category, item_category2, price et quantity. | voir sous-variables items ci-dessous | checkout, purchase, pledge |
| Sous-variables de l'objet items[ ] — propriétés du tableau e-commerce | |||||
| items.item_id | ecommerce.items.0.item_id | String | Identifiant du formulaire ou de la cause (multi-cause à venir) | FORM_456 | checkout, purchase, pledge |
| items.item_name | ecommerce.items.0.item_name | String | Nom du formulaire ou valeur technique de l'affectation | NOM MARQUE | checkout, purchase, pledge |
| items.affiliation | ecommerce.items.0.affiliation | String | Nom de l'organisation collectrice au niveau du produit e-commerce | NOM MARQUE | checkout, purchase, pledge |
| items.item_category | ecommerce.items.0.item_category | String | Fréquence du paiement au niveau du produit e-commerce | one-off·monthly | checkout, purchase, pledge |
| items.item_category2 | ecommerce.items.0.item_category2 | String | Moyen de paiement au niveau du produit e-commerce | Carte Bancaire·cheque·PayPal | purchase, pledge |
| items.price | ecommerce.items.0.price | Float | Valeur du paiement au niveau du produit e-commerce. | 23 | checkout, purchase, pledge |
| items.quantity | ecommerce.items.0.quantity | Float | Quantité du produit e-commerce. Toujours égale à 1 sur rgive. | 1 | checkout, purchase, pledge |
campaign_type, step, donation_type, payment_method et form_type ont des valeurs prédéfinies — respectez la casse exacte indiquée pour garantir la cohérence de vos rapports dans le temps.referrer_url répond à « d'où vient le visiteur ? », landing_url à « par où est-il entré, avec quels UTM ? », conversion_url à « sur quelle page a-t-il payé ? ». Ces trois valeurs reflètent la visite en cours — pas la toute première visite du navigateur.Payloads complets du dataLayer
Voici des exemples de payloads que rgive pousse dans le dataLayer pour chaque événement. Les valeurs réelles dépendent de la configuration de votre formulaire.
{ "event": "checkout", "ecommerce": { "affiliation": "NOM MARQUE", "campaign_id": "", "campaign_uuid": "0ebf97", "campaign_code": "", "campaign_media_code": "", "campaign_origin_code": "", "campaign_assignment_code": "", "campaign_name": "Amplifiez votre impact avec un don", "campaign_type": "donation", "integration": "page", "form_type": "3-step", "step": "amount", "donation_type": "one-off", "amount_type": "default", "currency": "EUR", "value": 20, "donor_email": "contact@exemple.fr", "referrer_url": "", "landing_url": "https://don.votreasso.fr/?utm_source=newsletter&utm_medium=email&utm_campaign=relance-don", "items": [ { "item_id": "", "item_name": "Amplifiez votre impact avec un don", "affiliation": "NOM MARQUE", "item_category": "one-off", "price": 20, "quantity": 1 } ] } }
Suivre les abandons à chaque étape du formulaire
rgive utilise des fragments d'URL pour identifier chaque étape du tunnel de paiement. GTM peut détecter ces changements automatiquement et les exploiter dans vos balises — sans aucun développement supplémentaire de la part de rgive.
checkout étant poussé à chaque étape avec la variable step, vous pouvez construire votre entonnoir dans votre outil analytics directement dessus — checkout (step = amount) → checkout (step = contact) → checkout (step = payment) → purchase ou pledge. Aucune configuration supplémentaire n'est requise au-delà de la variable de couche de données step. La méthode par fragments d'URL ci-dessous reste une alternative valide, notamment pour recouper les deux mesures.Configuration GTM en 2 étapes
Avant toute configuration, activez le mode Aperçu (Preview) dans GTM. Naviguez sur votre formulaire de paiement en passant de l'étape 1 à 2, puis à 3. Dans le panneau Tag Assistant, vérifiez que des événements History Change apparaissent à chaque changement d'étape. Si ces événements apparaissent, la solution est viable.
a) Activer les variables intégrées
Variables → Variables intégrées → Configurer → cochez New History Fragment et History Source.
b) Créer les déclencheurs
Déclencheurs → Nouveau → Type : Modification de l'historique.
— Déclencheur 1 : "New History Fragment" contient contact → nommer rgive - Passage étape 2 Contact
— Déclencheur 2 : "New History Fragment" est égal à payment → nommer rgive - Passage étape 3 Paiement
N'utilisez pas "contient" : le fragment #payment-details déclencherait une seconde fois cette balise.
c) Associer vos balises
Créez une balise pour votre outil analytics (événement form_step_contact sur le déclencheur "rgive - Passage étape 2 Contact", événement form_step_payment sur le déclencheur "rgive - Passage étape 3 Paiement").
d) Tester puis publier
Repassez en mode Aperçu, vérifiez que les deux balises se déclenchent. Une fois validé, publiez le conteneur.
Vous disposez alors, dans votre outil analytics, de la séquence page_view → form_step_contact → form_step_payment → checkout (step = payment) → purchase ou pledge pour construire votre entonnoir.
checkout est poussé à chaque chargement d'étape du formulaire, avec la variable step qui identifie l'étape en cours (amount, contact, payment, payment-details) — pas au clic sur « Je paye ». Pour mesurer un paiement effectivement abouti, appuyez-vous sur purchase ou pledge, pas sur checkout.Pétitions, manifestes, plaidoyer : les campagnes de mobilisation
Le module mobilisation de rgive permet de collecter des signatures plutôt que des paiements. Le tracking suit la même logique que les formulaires de paiement — événements poussés automatiquement dans le dataLayer, aucun code à écrire — mais avec ses propres événements et ses propres variables. Comme il n'y a pas de transaction, les données ne sont pas dans l'objet ecommerce mais dans un objet dédié mobilization.
Déclenché lorsque le visiteur commence réellement à interagir avec le formulaire de signature (première saisie). Sert à mesurer l'intention et calculer le taux d'abandon. Ne compte pas une signature.
Déclenché lorsque le formulaire a été soumis avec succès et que la signature a été enregistrée. Selon la configuration de la campagne, signature_status vaut confirmed (sans validation e-mail) ou pending_confirmation (avec validation e-mail). La variable step vaut contact sur cet événement.
Déclenché uniquement dans le parcours avec validation d'e-mail, lorsque le signataire clique sur le lien reçu et que sa signature devient définitive. Absent des campagnes sans validation e-mail. La variable step vaut confirmation. Ce payload ne contient pas les codes de campagne (campaign_media_code, campaign_origin_code, campaign_assignment_code).
Événement de conversion standard, poussé en complément. Il est déclenché au moment où la signature devient définitive : avec mobilization_submit si la campagne n'a pas de validation e-mail, avec mobilization_confirm sinon. Contient value (toujours 0) et currency. Ne contient ni step, ni integration, ni form_type.
generate_lead : il est déclenché une seule fois par signature, au moment où elle est définitive, quel que soit le parcours. mobilization_start mesure l'intention, pas la signature.Dans GTM ou MTM, créez une variable de couche de données avec le chemin exact de la colonne « Clé dataLayer ». Les variables ecommerce.* ne sont pas alimentées sur les campagnes de mobilisation.
| Variable | Clé dataLayer | Type | Description | Exemple / Valeurs | Événements |
|---|---|---|---|---|---|
| campaign_id | mobilization.campaign_id | String | Code de la campagne. Vide ("") si aucun code n'est renseigné dans le back-office. | Tous | |
| campaign_uuid | mobilization.campaign_uuid | String | Identifiant technique de la campagne (6 premiers caractères de son UUID), toujours renseigné | 7c354c | mobilization_start, mobilization_submit |
| campaign_name | mobilization.campaign_name | String | Nom de la campagne | Protégeons les océans | Tous |
| campaign_type | mobilization.campaign_type | String | Type de campagne | mobilization (toujours) | Tous |
| campaign_media_code | mobilization.campaign_media_code | String | Code média de la campagne. Facultatif, saisi dans le back-office. Vide ("") si non renseigné. | EMAIL_MAI | mobilization_start, mobilization_submit |
| campaign_origin_code | mobilization.campaign_origin_code | String | Code origine de la campagne. Facultatif, saisi dans le back-office. Vide ("") si non renseigné. | NEWSLETTER | mobilization_start, mobilization_submit |
| campaign_assignment_code | mobilization.campaign_assignment_code | String | Code d'affiliation de la campagne. Facultatif, saisi dans le back-office. Vide ("") si non renseigné. | FH | mobilization_start, mobilization_submit |
| integration | mobilization.integration | String | Mode d'intégration | page (uniquement, pour le moment) | mobilization_start, mobilization_submit, mobilization_confirm |
| form_type | mobilization.form_type | String | Format du formulaire | 1-step (uniquement, pour le moment) | mobilization_start, mobilization_submit, mobilization_confirm |
| step | mobilization.step | String | Étape en cours | contact (start, submit) · confirmation (confirm) | mobilization_start, mobilization_submit, mobilization_confirm |
| affiliation | mobilization.affiliation | String | Nom de l'organisation collectrice | NOM ORGANISATION | Tous |
| referrer_url | mobilization.referrer_url | String | Page d'origine du visiteur | https://www.facebook.com/ | Tous |
| landing_url | mobilization.landing_url | String | Page d'entrée de la visite en cours, UTM inclus | https://agir.votreasso.fr/oceans?utm_source=facebook&utm_medium=paid-social | Tous |
| Variable | Clé dataLayer | Type | Description | Exemple / Valeurs | Événements |
|---|---|---|---|---|---|
| mobilization_type | mobilization.mobilization_type | String | Nature fonctionnelle de la campagne | petition · manifesto · advocacy | Tous |
| signature_id | mobilization.signature_id | String | Identifiant unique de la signature. Clé de dédoublonnage recommandée. | 72fcf307-0c6f-45f0-bfce-a01a2eb19cbf | submit, confirm, generate_lead |
| signature_status | mobilization.signature_status | String | Statut de la signature au moment de l'événement | pending_confirmation · confirmed | submit, confirm, generate_lead |
| validation_method | mobilization.validation_method | String | Méthode de validation configurée sur la campagne | none · email | Tous |
| value | mobilization.value | String | Toujours 0 | 0 | generate_lead |
| currency | mobilization.currency | String | Devise ISO de la campagne | EUR | generate_lead |
Voici des exemples de payloads poussés par rgive sur une campagne de mobilisation. Les valeurs réelles dépendent de la configuration de votre campagne.
{ "event": "mobilization_submit", "mobilization": { "affiliation": "NOM ORGANISATION", "campaign_id": "", "campaign_uuid": "7c354c", "campaign_code": "", "campaign_media_code": "", "campaign_origin_code": "", "campaign_assignment_code": "", "campaign_name": "Pour des aires marines vraiment protégées", "campaign_type": "mobilization", "mobilization_type": "petition", "integration": "page", "form_type": "1-step", "step": "contact", "signature_id": "72fcf307-0c6f-45f0-bfce-a01a2eb19cbf", "signature_status": "pending_confirmation", "validation_method": "email", "referrer_url": "https://www.facebook.com/", "landing_url": "https://agir.votreasso.fr/oceans?utm_source=facebook&utm_medium=paid-social&utm_campaign=oceans-2026" } }
- Créez quatre déclencheurs « Événement personnalisé » avec les noms exacts
mobilization_start,mobilization_submit,mobilization_confirm,generate_lead. - Créez une variable de couche de données par propriété souhaitée, avec le préfixe
mobilization. - Entonnoir recommandé :
page_view→mobilization_start→mobilization_submit→mobilization_confirm(si validation e-mail). Variables utiles pour segmenter :campaign_name,mobilization_type,validation_method.
Pour chaque événement, créez une balise pour votre outil analytics associée au déclencheur correspondant. Voici des exemples de configuration — adaptez les paramètres à vos besoins.
Événement personnalisé : mobilization_startÉvénement personnalisé : mobilization_submitÉvénement personnalisé : mobilization_confirmÉvénement personnalisé : generate_leadUTM / MTM — comprendre et bien utiliser
Les paramètres UTM sont des informations que vous ajoutez à vos liens pour savoir précisément d'où viennent vos payeurs. Sans eux, vos rapports analytics sont partiellement aveugles. Avec eux, vous savez quelle campagne, quel canal et quel contenu a généré chaque paiement.
| Source | Medium | Sessions |
|---|---|---|
| gmail.com | (none) | 312 |
| yahoo.fr | (none) | 187 |
| orange.fr | (none) | 143 |
| (direct) | (none) | 114 |
Vos newsletters apparaissent comme du trafic webmail — impossible de savoir que c'est votre campagne.
| Campagne | Medium | Sessions |
|---|---|---|
| newsletter-mai-25 | 298 | |
| newsletter-avr-25 | 231 | |
| relance-don | 107 | |
| campagne-meta | paid-social | 120 |
Vous savez exactement quelle campagne a amené ces payeurs et généré ces paiements.
Les 6 paramètres disponibles
Aucun n'est techniquement obligatoire — mais 3 sont essentiels. La logique est identique sur Matomo (MTM).
D'où vient le payeur ? Identifie l'émetteur du lien — la plateforme ou le canal d'origine.
Quel type de canal marketing ? Permet de regrouper les sources par famille dans vos rapports.
Le nom de votre campagne. C'est la dimension la plus utile au quotidien pour comparer vos actions de collecte.
Quelle variante créative ? Utile pour les tests A/B — comparer deux visuels, deux boutons ou deux accroches dans la même campagne.
Le mot-clé ciblé. Pertinent uniquement pour les campagnes Google Ads Search — inutile sur email ou social.
Un identifiant unique de campagne. Utile si vous gérez vos campagnes dans un outil externe et voulez faire le lien avec vos données analytics.
Nos recommandations par canal
Les conventions ci-dessous sont celles que nous recommandons à nos clients nonprofit pour garantir des rapports cohérents et comparables dans le temps.
utm_term est inutile sur email — il n'y a pas de mot-clé de recherche. Précisez le nom de la newsletter dans utm_source pour pouvoir comparer vos éditions entre elles.
cpc (coût par clic) est la convention la plus répandue pour les moteurs de recherche payants. Activez l'auto-tagging dans Google Ads pour remplir utm_term automatiquement.
paid-social distingue la publicité sociale du search payant (cpc). Même logique pour TikTok, LinkedIn et Instagram — adaptez uniquement utm_source.
Les règles de nommage — à respecter absolument
Les outils analytics sont sensibles à la casse et traite chaque variante comme une valeur distincte. Email et email et e-mail — ce sont trois sources différentes dans vos rapports.
Les outils analytics sont sensibles à la casse. Une majuscule suffit à créer une nouvelle entrée distincte dans vos rapports — vos données se fragmentent sans que vous vous en aperceviez.
Choisissez une convention une fois pour toutes et ne la changez jamais. Le tiret est la convention la plus répandue. Évitez absolument les espaces.
Décidez une fois comment vous appelez chaque canal et documentez-le. Toute l'équipe doit utiliser les mêmes valeurs dans tous les outils — emailing, CMS, réseaux sociaux.
Comment rgive gère vos UTMs
rgive capture et conserve vos paramètres UTM de façon native — même si le payeur refuse les cookies.
Les valeurs UTM sont enregistrées côté serveur dans la base de données, indépendamment du consentement cookies du payeur. Rien n'est perdu.
Chaque paiement stocke utm_source, utm_medium, utm_campaign, utm_content, utm_term et utm_id associés à la transaction.
Filtrez vos paiements par utm_source, utm_medium ou utm_campaign directement dans rgive pour isoler les résultats d'une campagne.
Les valeurs UTM sont exportables en CSV et disponibles comme dimensions dans Metabase pour vos tableaux de bord personnalisés.
Générateur d'URL UTM
Construisez votre URL trackée en remplissant les champs ci-dessous. L'URL se génère automatiquement en temps réel, prête à coller dans votre email ou votre campagne.
Les valeurs sont automatiquement converties en minuscules. Les espaces sont remplacés par des tirets.
Générer votre configuration prête à importer
Configurer GTM ou MTM manuellement prend du temps — il faut créer une variable pour chaque propriété rgive et un déclencheur pour chaque événement. Ce fichier JSON fait tout ça automatiquement : importez-le en un clic dans votre container et votre configuration de base est prête en moins d'une minute.
Le fichier exporté est adapté au format natif de la plateforme choisie.
Questions fréquentes
Les réponses aux questions que nos clients posent le plus souvent lors de l'intégration GTM ou MTM avec rgive.
Oui — c'est une obligation légale, pas une recommandation.
Si vous n'avez pas encore de CMP, mettez en place ce prérequis avant de publier votre container GTM ou MTM en production.
Pour trois raisons principales :
GTM et MTM ont précisément été conçus pour répondre à ce besoin de façon gouvernée, auditée et réversible.
step qui identifie l'étape en cours (amount, contact, payment, payment-details). Un payeur qui parcourt les trois étapes génère donc trois événements checkout, distingués par leur valeur de step. Pour mesurer les paiements aboutis, utilisez purchase (paiement immédiat) ou pledge (promesse à paiement différé), pas checkout.payment, sinon #payment-details déclencherait une seconde fois la balise. Vous pouvez ensuite construire votre entonnoir dans votre outil analytics. Consultez la section Abandons pour le guide de configuration complet.Les causes les plus fréquentes :
referrer_url est la page externe d'où vient le visiteur (Google, Facebook, un autre site). landing_url est la première page de votre site qu'il a vue pendant cette visite, avec ses paramètres UTM. Le premier dit d'où il vient, le second par où il est entré chez vous. Les deux reflètent la visite en cours.purchase n'est envoyé qu'une seule fois par transaction, même si le payeur recharge la page de confirmation. Le champ transaction_id reste disponible comme clé de dédoublonnage.generate_lead, déclenché une seule fois par signature au moment où elle devient définitive. N'utilisez pas mobilization_start, qui mesure l'intention et non la signature.campaign_id reprend le code de campagne saisi dans le back-office rgive. S'il n'est pas renseigné, la variable est transmise vide. Utilisez campaign_uuid, toujours renseigné, ou saisissez un code de campagne dans les paramètres de la campagne.mobilization, pas dans ecommerce. Créez des variables de couche de données avec le préfixe mobilization. (voir la section Campagnes de mobilisation).