Flux d'événements

Dans Adapty, vous recevrez divers événements d’abonnement tout au long du parcours d’un client dans votre application. Ces flux d’abonnement décrivent les scénarios les plus courants pour vous aider à comprendre les événements qu’Adapty génère lorsque les utilisateurs s’abonnent, annulent ou réactivent des abonnements.

Gardez à l’esprit qu’Apple traite les paiements d’abonnement plusieurs heures avant la date de début ou de renouvellement effective. Dans les flux ci-dessous, nous représentons le début/renouvellement de l’abonnement et le débit comme ayant lieu simultanément pour simplifier les diagrammes.

De plus, les événements liés à la même action se produisent simultanément et peuvent apparaître dans votre Event Feed dans n’importe quel ordre, qui peut différer de la séquence présentée dans nos diagrammes.

Cycle de vie d’un abonnement

Flux d’achat initial

Ce flux se produit lorsqu’un client souscrit un abonnement pour la première fois sans essai. Dans ce cas, les événements suivants sont créés :

• Subscription started
• Access level updated pour accorder l’accès à l’utilisateur

Lorsque la date de renouvellement de l’abonnement arrive, l’abonnement est renouvelé. Les événements suivants sont alors créés :

• Subscription renewal pour démarrer une nouvelle période d’abonnement
• Access level updated pour mettre à jour la date d’expiration de l’abonnement, prolongeant l’accès d’une période supplémentaire

Les situations où le paiement échoue ou lorsque l’utilisateur annule le renouvellement sont décrites respectivement dans Flux de résultat d’un problème de facturation et Flux d’annulation d’abonnement.

Flux d’annulation d’abonnement

Lorsqu’un utilisateur annule son abonnement, les événements suivants sont créés :

• Subscription renewal canceled pour indiquer que l’abonnement reste actif jusqu’à la fin de la période en cours, après quoi l’utilisateur perdra l’accès
• L’événement Access level updated est créé pour désactiver le renouvellement automatique de l’accès

Une fois l’abonnement terminé, l’événement Subscription expired (churned) est déclenché pour marquer la fin de l’abonnement.

Si un remboursement est approuvé, l’événement suivant remplace Subscription expired (churned) :

• Subscription refunded pour mettre fin à l’abonnement et fournir les détails du remboursement

Pour Stripe, un abonnement peut être annulé immédiatement, sans attendre la fin de la période restante. Dans ce cas, tous les événements sont créés simultanément :

• Subscription renewal cancelled
• Subscription expired (churned)
• Access Level updated pour supprimer l’accès de l’utilisateur

Si un remboursement est approuvé, un événement Subscription refunded est également déclenché au moment de son approbation.

Flux de réactivation d’abonnement

Si un utilisateur annule un abonnement, celui-ci expire, puis l’utilisateur rachète le même abonnement plus tard, un événement Subscription renewed sera créé. Même s’il y a une interruption d’accès, Adapty traite cela comme une seule chaîne de transactions, liée par le vendor_original_transaction_id. Ainsi, le rachat est considéré comme un renouvellement.

Les événements Access level updated seront créés deux fois :

• à la fin de l’abonnement pour révoquer l’accès de l’utilisateur
• lors du rachat de l’abonnement pour accorder l’accès

Flux de mise en pause d’abonnement (Android uniquement)

Ce flux s’applique lorsqu’un utilisateur met en pause puis reprend un abonnement sur Android.

La mise en pause d’un abonnement a des effets différés. Si un utilisateur met en pause un abonnement avant sa date de renouvellement, l’abonnement reste actif et l’utilisateur conserve l’accès payant pour le reste de la période de facturation.

1. Lorsque l’utilisateur met en pause un abonnement, l’événement Subscription paused (Android only) est déclenché.

2. À la fin de la période d’abonnement, Adapty déclenche l’événement Access level updated pour révoquer l’accès de l’utilisateur.

3. Lorsque l’utilisateur reprend l’abonnement, les événements suivants sont déclenchés :

   • Subscription renewed
   • Access level updated pour rétablir l’accès de l’utilisateur

Ces abonnements appartiendront à la même chaîne de transactions, liée par le même vendor_original_transaction_id.

Flux d’essai

Si vous utilisez des essais dans votre application, vous recevrez des événements supplémentaires liés aux essais.

Flux d’essai avec conversion réussie

Le flux le plus courant se produit lorsqu’un utilisateur démarre un essai, fournit une carte bancaire et convertit avec succès vers un abonnement standard à la fin de la période d’essai. Dans ce cas, les événements suivants sont créés au moment du démarrage de l’essai :

• Trial started pour marquer le début de l’essai
• Access level updated pour accorder l’accès

L’événement Trial converted est créé lorsque l’abonnement standard démarre.

Flux d’essai sans conversion réussie

Si un utilisateur annule l’essai avant qu’il ne se convertisse en abonnement, les événements suivants sont créés au moment de l’annulation :

• Trial renewal cancelled pour désactiver la conversion automatique de l’essai en abonnement
• Access level updated pour désactiver le renouvellement de l’accès

L’utilisateur conservera l’accès jusqu’à la fin de l’essai, moment auquel l’événement Trial expired est créé pour marquer la fin de l’essai.

Flux de réactivation d’abonnement après expiration d’essai

Si un essai expire (en raison d’un problème de facturation ou d’une annulation) et que l’utilisateur souscrit ensuite un abonnement, les événements suivants sont créés :

• Access level updated pour accorder l’accès à l’utilisateur
• Trial converted

Même avec un écart entre l’essai et l’abonnement, Adapty les relie via le vendor_original_transaction_id. Cette conversion est traitée comme faisant partie d’une chaîne de transactions continue, démarrant par un essai à prix zéro. C’est pourquoi l’événement Trial converted est créé plutôt que Subscription started.

Changements de produit

Cette section couvre les ajustements apportés aux abonnements actifs, comme les mises à niveau, les rétrogradations ou les achats d’un produit d’un autre groupe.

Flux de changement de produit immédiat

Après qu’un utilisateur change de produit, le changement peut être appliqué immédiatement dans le système avant la fin de l’abonnement (principalement en cas de mise à niveau ou de remplacement d’un produit). Dans ce cas, au moment du changement de produit :

• Le niveau d’accès est modifié, et deux événements Access level updated sont créés :
  1. pour supprimer l’accès au premier produit.
  2. pour accorder l’accès au second produit.
• L’ancien abonnement prend fin et un remboursement est effectué (l’événement Subscription refunded est créé avec cancellation_reason = upgraded). Notez qu’aucun événement Subscription expired (churned) n’est créé ; l’événement Subscription refunded le remplace.
• Le nouvel abonnement démarre (l’événement Subscription started est créé pour le nouveau produit).

Si un utilisateur rétrograde son abonnement, le premier abonnement durera jusqu’à la fin de la période payée, puis sera remplacé par un nouvel abonnement de niveau inférieur. Dans ce cas, seul l’événement Access level updated pour désactiver le renouvellement automatique de l’accès sera créé immédiatement. Tous les autres événements seront créés au moment du remplacement effectif de l’abonnement :

• Un autre événement Access level updated est créé pour accorder l’accès au second produit.
• L’événement Subscription expired (churned) est créé pour mettre fin à l’abonnement au premier produit.
• L’événement Subscription started est créé pour démarrer un nouvel abonnement pour le nouveau produit.

Flux de changement de produit différé

Il existe également un cas où un utilisateur change de produit au moment du renouvellement de l’abonnement. Ce cas est très similaire au précédent : un événement Access level updated sera créé immédiatement pour désactiver le renouvellement automatique de l’accès à l’ancien produit. Tous les autres événements seront créés au moment où l’utilisateur change d’abonnement et que le changement est appliqué dans le système :

• Un autre événement Access level updated est créé pour accorder l’accès au second produit.
• L’événement Subscription expired (churned) est créé pour mettre fin à l’abonnement au premier produit.
• L’événement Subscription started est créé pour démarrer un nouvel abonnement pour le nouveau produit.

Flux de résultat d’un problème de facturation

Si les tentatives de conversion d’un essai ou de renouvellement d’un abonnement échouent en raison d’un problème de facturation, la suite dépend de si un délai de grâce est activé ou non.

Avec un délai de grâce, si le paiement réussit, l’essai est converti ou l’abonnement est renouvelé. S’il échoue, le store continuera à tenter de débiter l’utilisateur pour l’abonnement ; en cas d’échec persistant, le store mettra fin à l’essai ou à l’abonnement.

Ainsi, au moment du problème de facturation, les événements suivants sont créés dans Adapty :

• Billing issue detected
• Entered grace period (si le délai de grâce est activé)
• Access level updated pour fournir l’accès jusqu’à la fin du délai de grâce

Si le paiement réussit ultérieurement, Adapty enregistre un événement Trial converted ou Subscription renewed, et l’utilisateur ne perd pas l’accès.

Si le paiement échoue définitivement et que le store annule l’abonnement, Adapty génère ces événements :

• Trial expired ou Subscription expired (churned) avec cancellation_reason: billing_error
• Access level updated pour révoquer l’accès de l’utilisateur

Sans délai de grâce, la période de nouvelle tentative de facturation (pendant laquelle le store continue de tenter de débiter l’utilisateur) démarre immédiatement.

Si le paiement n’aboutit jamais avant la fin de la période de nouvelle tentative, le flux est identique : les mêmes événements sont créés lorsque le store met fin automatiquement à l’abonnement :

• Événement Trial expired ou Subscription expired (churned) avec un cancellation_reason de billing_error

• Access level updated pour révoquer l’accès de l’utilisateur

Flux de partage d’achats entre comptes utilisateurs

Lorsqu’un Customer User ID iOS, Android, React Native, Flutter, et Unity tente de restaurer ou d’étendre un abonnement déjà associé à un autre Customer User ID iOS, Android, React Native, Flutter, et Unity , le paramètre Sharing paid access between user accounts d’Adapty contrôle la gestion de l’accès. Le flux variera selon l’option sélectionnée.

Pour avoir un aperçu rapide des événements déclenchés lorsqu’un second profil revendique un abonnement existant, utilisez cette matrice. Les sections suivantes présentent le payload JSON complet pour chaque flux.

Les renouvellements, remboursements et expirations sur un abonnement transféré continuent de déclencher les événements subscription_renewed, subscription_refunded et subscription_expired sur le profil qui détient actuellement le niveau d’accès. L’événement de transfert lui-même n’émet pas d’événement subscription_started, car aucune nouvelle transaction n’est enregistrée — seule l’attribution change.

Pour les détails par mode, consultez Référence pratique.

Flux de transfert d’accès vers un nouvel utilisateur

L’option recommandée est de transférer le niveau d’accès au nouvel utilisateur. Cela préserve l’historique des transactions de l’utilisateur d’origine pour des analyses cohérentes. Seuls 2 événements Access level updated seront créés :

1. pour supprimer l’accès du premier utilisateur
2. pour accorder l’accès au second utilisateur

Voici un détail des champs relatifs à l’attribution et au transfert du niveau d’accès dans les événements générés dans ce scénario :

• Utilisateur A : Access level updated (envoyé lorsque l’utilisateur A souscrit un abonnement dans l’application)

  {
    "profile_id": "00000000-0000-0000-0000-000000000000",
    "customer_user_id": UserA,
    "event_properties": {
      "profile_has_access_level": true,
    },
    "profiles_sharing_access_level": null
  }

• Utilisateur A : Access level updated (envoyé lorsque l’application est réinstallée et que l’utilisateur B se connecte, révoquant l’accès de l’utilisateur A)

  {
    "profile_id": "00000000-0000-0000-0000-000000000000",
    "customer_user_id": UserA,
    "event_properties": {
      "profile_has_access_level": false,
    },
    "profiles_sharing_access_level": null
  }

• Utilisateur B : Access level updated (envoyé lorsque l’utilisateur B se connecte et que l’accès lui est accordé)

  {
    "profile_id": "00000000-0000-0000-0000-000000000001",
    "customer_user_id": UserB,
    "event_properties": {
      "profile_has_access_level": true,
    },
    "profiles_sharing_access_level": null
  }

Flux de partage d’accès entre utilisateurs

Cette option permet à plusieurs utilisateurs de partager le même niveau d’accès si leur appareil est connecté au même identifiant Apple/Google. C’est utile lorsqu’un utilisateur réinstalle l’application et se connecte avec une adresse e-mail différente — il conservera quand même l’accès à son achat précédent. Avec cette option, plusieurs utilisateurs identifiés peuvent partager le même niveau d’accès. Pendant le partage du niveau d’accès, toutes les transactions sont enregistrées sous le Customer User ID iOS, Android, React Native, Flutter, et Unity d’origine pour maintenir un historique complet des transactions et des analyses.

Par conséquent, un seul événement sera créé : Access level updated pour accorder l’accès au second utilisateur.

Voici un détail des champs relatifs à l’attribution et au partage du niveau d’accès dans les événements générés dans ce scénario :

Utilisateur B : Access level updated (envoyé lorsque l’utilisateur B se connecte et que l’accès lui est accordé)

{
  "profile_id": "00000000-0000-0000-0000-000000000000",
  "customer_user_id": UserA,
  "event_properties": {
    "profile_has_access_level": true,
  },
  "profiles_sharing_access_level": [
    {
      "profile_id": "00000000-0000-0000-0000-000000000001,
      "customer_user_id": UserB
    }
  ]
}

Flux sans partage d’accès entre utilisateurs

Avec cette option, seul le premier profil utilisateur à recevoir le niveau d’accès le conserve de façon permanente. C’est idéal si les achats doivent être liés à un seul Customer User ID iOS, Android, React Native, Flutter, et Unity .