Événements à envoyer aux intégrations tierces
Apple et Google envoient les événements d’abonnement directement aux serveurs via les Notifications du serveur App Store et les Notifications en temps réel pour les développeurs (RTDN). En conséquence, les applications mobiles ne peuvent pas envoyer de manière fiable des événements aux systèmes d’analyse en temps réel. Par exemple, si un utilisateur souscrit un abonnement sans jamais rouvrir l’application, le développeur ne recevra aucune mise à jour du statut d’abonnement sans serveur.
Adapty comble cette lacune en collectant les données d’abonnement et en les convertissant en événements lisibles. Ces événements d’intégration sont envoyés au format JSON. Bien que tous les événements partagent la même structure, leurs champs varient selon le type d’événement, le store et la configuration spécifique. Les champs exacts inclus dans chaque événement sont détaillés sur les pages d’intégration correspondantes.
Pour savoir comment déterminer si un événement a bien été traité ou si un problème est survenu, consultez la page Statuts des événements.
Types d’événements
La plupart des événements sont créés et envoyés à toutes les intégrations configurées si elles sont activées. Cependant, l’événement Access level updated ne se déclenche que si l’intégration webhook est configurée et que cet événement est activé. Cet événement apparaîtra dans le Event Feed et sera également envoyé au webhook, mais ne sera pas partagé avec les autres intégrations.
Si aucune intégration webhook n’est configurée ou si ce type d’événement n’est pas activé, l’événement Access level updated ne sera pas créé et n’apparaîtra pas dans le Event Feed.
| Nom de l’événement | Description |
|---|---|
| subscription_started | Déclenché lorsqu’un utilisateur active un abonnement payant sans période d’essai, c’est-à-dire qu’il est facturé immédiatement. |
| subscription_renewed | Se produit lors du renouvellement d’un abonnement et de la facturation de l’utilisateur. Cet événement débute à partir de la deuxième facturation, que l’abonnement soit avec ou sans essai. |
| subscription_renewal_cancelled | Un utilisateur a désactivé le renouvellement automatique de son abonnement. Il conserve l’accès aux fonctionnalités premium jusqu’à la fin de la période d’abonnement payante. |
| subscription_renewal_reactivated | Déclenché lorsqu’un utilisateur réactive le renouvellement automatique de son abonnement. |
| subscription_expired | Déclenché lorsqu’un abonnement prend fin après une annulation. Par exemple, si un utilisateur annule son abonnement le 12 décembre mais qu’il reste actif jusqu’au 31 décembre, l’événement est enregistré le 31 décembre à l’expiration de l’abonnement. |
| subscription_paused | Se produit lorsqu’un utilisateur active la mise en pause de l’abonnement (Android uniquement). |
| subscription_deferred | Déclenché lorsqu’un achat d’abonnement est différé, permettant aux utilisateurs de reporter le paiement tout en conservant l’accès aux fonctionnalités premium. Cette fonctionnalité est disponible via l’API Google Play Developer et peut être utilisée pour des essais gratuits ou pour les utilisateurs rencontrant des difficultés financières. |
| non_subscription_purchase | Tout achat sans abonnement, tel qu’un accès à vie ou des produits consommables comme des pièces dans un jeu. |
| trial_started | Déclenché lorsqu’un utilisateur active un abonnement d’essai. |
| trial_converted | Se produit lorsqu’un essai se termine et que l’utilisateur est facturé (premier achat). Par exemple, si un utilisateur a un essai jusqu’au 14 janvier mais est facturé le 7 janvier, cet événement est enregistré le 7 janvier. |
| trial_renewal_cancelled | Un utilisateur a désactivé le renouvellement automatique de son abonnement pendant la période d’essai. Il conserve l’accès aux fonctionnalités premium jusqu’à la fin de l’essai, mais ne sera pas facturé et ne démarrera pas d’abonnement. |
| trial_renewal_reactivated | Se produit lorsqu’un utilisateur réactive le renouvellement automatique de son abonnement pendant la période d’essai. |
| trial_expired | Déclenché lorsqu’un essai se termine sans conversion en abonnement. |
| entered_grace_period | Se produit lorsqu’une tentative de paiement échoue et que l’utilisateur entre dans un délai de grâce (si activé). L’utilisateur conserve l’accès premium pendant cette période. |
| billing_issue_detected | Déclenché lorsqu’un problème de facturation survient lors d’une tentative de débit (par exemple, solde de carte insuffisant). |
| subscription_refunded | Déclenché lorsqu’un abonnement est remboursé (par exemple, par le support Apple). |
| non_subscription_purchase_refunded | Déclenché lorsqu’un achat sans abonnement est remboursé. |
| access_level_updated | Se produit lorsque le niveau d’accès d’un utilisateur est mis à jour. |
Les événements ci-dessus couvrent entièrement l’état des utilisateurs en matière d’achats. Voici quelques exemples.
Exemple 1
L’utilisateur a activé un abonnement mensuel le 1er avril avec une période d’essai de 7 jours. Le 4e jour, il s’est désabonné.
Dans ce cas, les événements suivants seront envoyés :
trial_startedle 1er avriltrial_renewal_cancelledle 4 avriltrial_expiredle 7 avril
Exemple 2
L’utilisateur a activé un abonnement mensuel le 1er avril avec une période d’essai de 7 jours. Le 10e jour, il s’est désabonné.
Dans ce cas, les événements suivants seront envoyés :
trial_startedle 1er avriltrial_convertedle 7 avrilsubscription_renewal_cancelledle 10 avrilsubscription_expiredle 1er mai
Pour une description détaillée des événements déclenchés dans chaque scénario, consultez les Flux d’événements.