Track
Premiers pasGuideIntermédiaire

Événements d'abonnement et SaaS : essais, abonnements, renouvellements et résiliations sans gonfler le chiffre d'affaires

Comment modéliser une activité par abonnement dans le vocabulaire d'événements standard — sign_up, start_trial, subscribe, purchase pour les renouvellements, refund pour les résiliations — où chaque événement doit naître, quelle valeur envoyer aux plateformes publicitaires et comment tenir les renouvellements à l'écart des métriques d'acquisition.

Par
Rédaction Track
Publié le
Dernière relecture
Temps de lecture
3 min de lecture

À retenir

  • Modélisez le cycle de vie avec sign_up, start_trial, subscribe, purchase avec un indicateur de renouvellement ou d'expansion, refund et login ; le système de facturation fait autorité pour tout ce qui touche à l'argent.
  • Les renouvellements ne doivent jamais être envoyés comme subscribe : ne mappez que l'événement d'acquisition vers les actions de conversion publicitaires, afin que les plateformes n'apprennent pas à cibler vos clients existants.
  • Les valeurs restent honnêtes — le montant de la première facture pour subscribe, tout au plus des constantes documentées par offre, le delta pour l'expansion, des montants négatifs pour les remboursements.
  • Le consentement enregistré à l'inscription voyage avec le webhook de facturation ; être client n'est pas un consentement, et les identifiants de facture ou d'abonnement utilisés comme transaction_id absorbent les répétitions de webhooks.

Le cycle de vie en événements

Moment du cycle de vieÉvénementOriginePropriétés
Compte créésign_upnavigateur (hybride)method
Essai démarréstart_trialserveur (webhook de facturation)plan, trial_days
Premier abonnement payantsubscribeserveur (webhook de facturation)plan, interval, value, currency, transaction_id
Facture de renouvellement payéepurchase avec props.renewal: trueserveurvalue, currency, transaction_id
Upgrade / expansionpurchase avec props.expansion: trueserveurvalue en delta
Résiliation ou remboursementrefundserveurtransaction_id d'origine, value négative
Connexionloginnavigateur

Le système de facturation fait autorité pour tout ce qui touche à l'argent. Le navigateur peut bien afficher une page « abonnement confirmé », mais l'événement qui atteint les plateformes publicitaires provient du webhook, avec les identifiants du système de facturation.

Pourquoi les renouvellements ne doivent pas être des subscribe

Les plateformes publicitaires optimisent vers la conversion que vous leur envoyez. Si chaque renouvellement mensuel leur parvient comme un nouvel abonnement avec une valeur, la plateforme apprend que vos clients existants convertissent bien et enchérit pour les atteindre à nouveau. Gardez l'événement d'acquisition (subscribe, une fois par client) séparé de la rétention (purchase avec l'indicateur de renouvellement) et ne mappez que l'événement d'acquisition vers les actions de conversion publicitaires. Les renouvellements continuent d'alimenter l'analytics et votre propre reporting.

Les valeurs destinées aux plateformes publicitaires

  • subscribe : le montant de la première facture est défendable et simple. Envoyer une estimation de valeur vie client n'est autorisé que sous la forme d'une constante documentée par offre dans le mapping de la destination, visible dans le journal d'audit ; jamais une estimation par utilisateur.
  • start_trial : pas de valeur, ou une valeur attendue documentée par offre.
  • Expansion : le delta, pas le nouveau total.
  • refund : la valeur négative du montant remboursé ; GA4 traite les remboursements via l'identifiant de transaction, Google Ads via les ajustements de conversion, la plupart des autres plateformes les ignorent — le connecteur applique ce que le fournisseur prend en charge.

L'identité d'un appareil à l'autre

Un client SaaS s'inscrit sur ordinateur, paie sur mobile et se connecte partout. Appelez identify avec votre identifiant utilisateur et, sous consentement marketing, l'e-mail haché ; les événements serveur portent le même identifiant utilisateur et le même hachage. C'est ce qui permet aux plateformes de rapprocher un subscribe côté serveur du clic publicitaire survenu des jours plus tôt sur un autre appareil, dans les limites de leurs fenêtres d'attribution.

Essais et consentement

Le webhook de facturation transporte l'état du consentement que votre système a enregistré à l'inscription, avec l'identifiant utilisateur. Le routeur applique cet état : un utilisateur qui a refusé le marketing à l'inscription ne produit que des événements analytics, et un webhook sans aucune information de consentement n'atteint aucune destination publicitaire. Ne déduisez pas le consentement du fait que quelqu'un est devenu client ; être client n'est pas un consentement à la mesure publicitaire.

Déduplication face aux répétitions de facturation

Les systèmes de facturation rejouent leurs webhooks. Utilisez l'identifiant de facture ou d'abonnement comme transaction_id ; l'étape d'ingestion marque un second subscribe ou purchase portant le même identifiant de transaction comme conversion en doublon, et les plateformes qui dédupliquent sur le numéro de commande fusionnent ce qui serait passé au travers.

Un reporting qui reste honnête

  • Acquisition : nombre et valeur des subscribe par campagne, depuis les plateformes publicitaires et depuis vos propres événements.
  • Conversion des essais : start_trialsubscribe par offre, uniquement depuis vos propres événements.
  • Chiffre d'affaires net : purchase (tous indicateurs confondus) moins refund, depuis la facturation, rapproché chaque mois des événements.

Si ces trois chiffres divergent un jour des rapports du système de facturation lui-même, la répartition par source sur la page des événements montre quel chemin laisse échapper quoi.

Sources principales

Documentation et normes sur lesquelles cet article s’appuie.

  1. Stripe — Webhook events for subscriptionsdocs.stripe.com

Cet article vous a-t-il été utile ?

Responsable éditorial

Rédaction Track

Produit et ingénierie

Les personnes qui construisent Track : des ingénieurs et des analystes qui travaillent chaque jour sur le tracking côté serveur, les outils de consentement et les intégrations de connecteurs.