Les données de revenu que vous manipulez chaque jour — montant, devise, identifiant de transaction — restent hébergées dans une infrastructure conforme au RGPD, certifiée SOC 2 Type I et ISO 27001:2022, avec des centres de données en UE et aux États-Unis. C’est le point de départ dont la plupart des équipes ont besoin avant même de parler d’attribution.
La plupart des équipes veulent savoir quelles campagnes génèrent réellement de l’argent. Ce qui les arrête, c’est l’attribution : les données de vente vivent dans des systèmes différents, chacun avec son propre format, et relier cela au message qui a déclenché l’achat devient un projet à part entière. Résultat, les équipes reviennent aux ouvertures et aux clics : ces chiffres sont déjà dans le tableau de bord.
La solution consiste à faire entrer le revenu dans votre plateforme de messagerie sous une forme qu’elle peut réellement exploiter. Voici comment procéder dans Pushwoosh.
Pourquoi les données de revenu n’atteignent jamais votre plateforme de messagerie 💰
La raison tient au format : le revenu n’arrive jamais sous 1 seule forme.
Par exemple, votre SDK déclenche un événement d’achat in-app quand quelqu’un achète des gemmes. Votre backend envoie un OrderPlaced personnalisé. Stripe et Shopify envoient leurs propres événements webhook pour les abonnements et les commandes boutique. Chacun avec des noms de champs différents, une structure différente, une définition différente de ce que « montant » signifie.
Pour consolider le revenu sur l’ensemble de ces sources, il faudrait écrire une logique dédiée pour chacune et la maintenir synchronisée. La plupart des équipes ne le font pas, car ce n’est rarement une priorité — jusqu’au bilan de fin de trimestre. Et à ce moment-là, les données n’existent tout simplement pas. Le suivi du revenu est donc reporté, et l’équipe continue de reporter les ouvertures, puisque ces métriques standards sont déjà connectées.
Le problème se résout pourtant vite : il suffit de faire entrer le revenu dans 1 format cohérent.
1 événement pour tout votre revenu
Pushwoosh résout le problème de format avec 1 événement natif : PW_Conversion. Quelle que soit la source d’origine, le revenu arrive dans 1 enregistrement normalisé avec un jeu de champs fixe :
- value — le montant de la transaction
- currency — par ex. EUR ou USD
- transaction_id et product_id — identifiants optionnels
C’est tout. Un renouvellement d’abonnement, un achat in-app, une commande Shopify — tout devient le même type d’événement. Dès que le revenu arrive sous forme de PW_Conversion, tout ce qui suit lit les mêmes données : segmentation RFM, Customer Journeys, tableaux de bord et ManyMoney AI.
2 façons de démarrer le suivi
Vous configurez les événements de conversion par application, avec 2 approches possibles. Choisissez celle qui correspond à la façon dont vos données d’achat circulent déjà.
- Mapper un événement existant — sans code. Si les données d’achat arrivent déjà dans Pushwoosh via un autre événement, il suffit de pointer Pushwoosh vers celui-ci. Choisissez l’événement source et mappez ses champs : quel attribut porte le prix, lequel porte la devise. Pushwoosh génère alors un enregistrement PW_Conversion à chaque déclenchement de cet événement, sans modifier une seule ligne de votre application. Vous pouvez mapper plusieurs sources à la fois — un événement personnalisé purchase_completed, en parallèle d’un webhook Stripe, Shopify ou PrestaShop.
- Envoyer PW_Conversion depuis votre code. Si vous préférez envoyer le revenu explicitement, ajoutez un appel postEvent partout où un achat se conclut dans votre application ou votre backend. Cette approche nécessite l’aide de votre équipe de développement, mais reste une intégration ponctuelle et limitée.
Quels événements peuvent devenir du revenu (et lesquels ne le peuvent pas)
L’approche par mapping fonctionne avec tout événement qui porte un montant :
- Événements personnalisés — vos propres purchase_completed, subscription_renewed, order_placed.
- Événements par défaut — lorsqu’ils représentent une action payante.
- Événements webhook entrants — Stripe, Shopify, PrestaShop et les autres sources de paiement connectées.
Ce que vous ne pouvez pas mapper, c’est un événement sans montant à lire. App_open, screen_view ou push_opened ne font que suivre ce que l’utilisateur a fait. Sans montant, il n’y a rien à convertir.
Ce que vous pouvez mesurer une fois le revenu intégré
C’est là le vrai bénéfice. Avec un revenu normalisé, 3 éléments qui exigeaient auparavant un développement sur mesure deviennent natifs :
- Segmenter par dépense. La segmentation RFM lit directement PW_Conversion, si bien que vos plus gros acheteurs atterrissent automatiquement dans le segment Champions, prêts à recevoir une offre de fidélité.
- Prouver quels parcours génèrent réellement des achats. Définissez PW_Conversion comme objectif de conversion dans n’importe quel Customer Journey. Une fois le parcours exécuté, les statistiques de l’objectif indiquent combien d’utilisateurs ont réellement acheté, pas seulement combien ont ouvert le message. La question « ce flux a-t-il été rentable ? » trouve enfin une réponse directement sur le canevas.
- Reporter le revenu dans les tableaux de bord, aux côtés des autres métriques de performance applicative essentielles, sans développer de logique sur mesure pour chaque événement d’achat.
Retrouvez votre type d’application
La même configuration s’adapte à la façon dont votre application génère réellement du revenu. Trouvez la ligne qui correspond à votre cas :
| Type d'application | Événements à mapper ou envoyer | Ce que vous voyez enfin |
|---|---|---|
| E-commerce | Mapper order_placed + un webhook Shopify, PrestaShop ou Stripe | Quels parcours de récupération de panier génèrent des commandes réelles ; RFM par dépense pour identifier les acheteurs récurrents avant les Soldes ou le Black Friday |
| Gaming | Envoyer iap_completed, battle_pass_bought depuis le code | Si une offre post-niveau convertit réellement, pas seulement si elle est ouverte ; segments par dépense pour les joueurs à forte valeur |
| Abonnement (médias, streaming) | Mapper subscription_renewed, plan_upgraded (Stripe, App Store) | Si les parcours de reconquête génèrent de vrais réabonnements ; RFM par récence de renouvellement |
| FinTech | Mapper premium_subscribed, first_trade ou un webhook de paiement | Quelles incitations à l'onboarding mènent à des comptes réellement approvisionnés ; segments par volume de transaction |
| Livraison de repas | Mapper order_placed depuis votre backend | Quelles notifications de réengagement génèrent de nouvelles commandes ; RFM selon la récence de la dernière commande |
| Voyage / réservation | Mapper booking_confirmed + services annexes comme seat_upgraded | Quels flux de baisse de prix convertissent en réservations ; segments par valeur du voyage |
order_placed + un webhook Shopify, PrestaShop ou Stripeiap_completed, battle_pass_bought depuis le codesubscription_renewed, plan_upgraded (Stripe, App Store)premium_subscribed, first_trade ou un webhook de paiementorder_placed depuis votre backendbooking_confirmed + services annexes comme seat_upgradedFaire apparaître le revenu là où les marketeurs travaillent déjà
Les événements de conversion ne sont qu’1 élément d’une direction plus large pour Pushwoosh : rendre le revenu visible là où les marketeurs travaillent déjà, plutôt que dans un rapport qu’ils doivent aller chercher.
Vous décidez déjà quoi envoyer, à qui, et à quelle fréquence. Aujourd’hui, ces décisions reposent sur les ouvertures et les clics, car c’est tout ce que nous pouvons vous restituer. Envoyez PW_Conversion, et ces mêmes décisions reposeront sur l’argent : quelles campagnes conserver, lesquelles arrêter, quels segments méritent plus d’envois — et lesquels vous coûtent des désabonnements sans rien rapporter.
Un bénéfice cumulatif apparaît dès que le revenu commence à circuler :
Mettre le suivi du revenu au travail dans Pushwoosh
Commencez par l’approche la moins coûteuse en effort : mapper un événement que vous envoyez déjà, ou transmettre l’exemple postEvent à votre équipe de développement. Définissez PW_Conversion comme objectif de conversion sur votre prochain parcours, et regardez le revenu apparaître aux côtés des ouvertures et des clics.
Articles connexes
Tout voir
