Chaque utilisateur de votre application dispose d’un profil Adapty qui suit ses achats, événements et état d’abonnement. Comprendre comment les profils sont créés et associés vous aide à éviter les bugs d’intégration, la fragmentation des données, et à interpréter les données de la section Profiles.

Création du profil

Adapty crée automatiquement un profil la première fois qu’un utilisateur ouvre votre application.

Sans Customer User ID, le profil est anonyme. Un nouveau profil anonyme est créé à chaque fois que :

• Un utilisateur réinstalle l’application
• Un utilisateur se déconnecte de votre application (quand votre application appelle Adapty.logout())

Les achats sont liés à l’installation de l’application, et non à une identité utilisateur persistante.

Avec un Customer User ID, le profil persiste après les réinstallations et sur différents appareils. L’utilisation d’un customer user ID vous permet de :

1. Suivre un utilisateur lors des réinstallations d’application et sur plusieurs appareils.
2. Retrouver des utilisateurs par leur customer user ID dans la section Profiles.
3. Utiliser le customer user ID dans l’API côté serveur.
4. Adapty envoie le customer user ID à toutes les intégrations.

Le comportement du profil avec un customer user ID dépend du moment où vous le définissez :

• Lors de l’activation du SDK : Adapty utilise le profil existant associé à cet identifiant utilisateur (pour les utilisateurs récurrents) ou crée un nouveau profil (pour les nouveaux utilisateurs).
• Après l’activation du SDK : Adapty crée un profil anonyme lors de l’activation. Lorsque vous identifiez l’utilisateur ultérieurement, Adapty associe l’identifiant utilisateur au profil anonyme (pour les nouveaux utilisateurs) ou bascule vers le profil existant correspondant à cet identifiant (pour les utilisateurs récurrents).

Quelle approche utiliser :

• Identifiant utilisateur disponible au lancement de l’application (par exemple, stocké depuis une session précédente) — passez-le à activate() lors de l’initialisation du SDK.
• Les utilisateurs se connectent après le lancement de l’application — appelez identify() après l’authentification. Adapty associe l’identifiant au profil actuel (si l’identifiant est nouveau) ou bascule vers le profil existant (si l’identifiant existe déjà).
• Les utilisateurs peuvent effectuer un achat avant de se connecter — appelez identify() après la connexion. Si l’identifiant utilisateur existe déjà dans Adapty, récupérez le profil ensuite pour synchroniser le niveau d’accès actuel.

Pour les détails d’implémentation, consultez le guide SDK identification des utilisateurs.

Profils parent et héritiers

Lorsqu’un même abonnement côté store est associé à plusieurs profils Adapty, Adapty les traite comme une chaîne : un profil parent et un ou plusieurs profils héritiers qui partagent l’accès depuis le même achat.

Cela se produit quand :

• Le partage d’accès payant entre comptes utilisateurs est activé et un utilisateur se connecte sur un appareil où un profil différent a effectué l’achat.
• Un utilisateur réinstalle l’application sans customer_user_id, et le nouveau profil récupère l’achat de l’installation précédente.
• Des utilisateurs identifiés différents restaurent les achats sur le même appareil.
• Une application est transférée entre des Team IDs Apple et la nouvelle application récupère les achats effectués sous l’ancien Team ID.

Comment le parent est sélectionné.

Le parent est le premier profil à enregistrer l’achat — déterminé par l’ordre des reçus d’achat dans Adapty, et non par l’ordre de création des profils. Par exemple : vous installez l’application sans effectuer d’achat, puis vous la réinstallez et souscrivez un abonnement. Le second profil devient le parent car c’est lui qui a effectué l’achat. Le premier profil devient l’héritier et obtient l’accès par partage.

Comment les événements sont distribués :

• Événements transactionnels (achats, renouvellements, annulations, problèmes de facturation, délais de grâce, remboursements) : Apparaissent uniquement sur le profil parent qui a effectué l’achat. Tous les renouvellements et mises à jour d’abonnement continuent d’apparaître sur ce profil.
• Événements access_level_updated : Apparaissent sur les deux profils, parent et héritier, chaque fois que l’état du niveau d’accès change. Cela permet à tous les profils connectés d’être informés de leur statut d’accès actuel.

Le profil parent affiche l’historique complet des transactions. Les profils héritiers n’affichent que leurs mises à jour de niveau d’accès et un lien vers le profil parent dans la section Access level.

Suivre le même abonnement sur plusieurs profils.

Chaque profil héritier possède son propre profile_id, donc le profile_id n’est pas stable d’un bout à l’autre d’une chaîne. Pour identifier le même abonnement sur plusieurs profils — par exemple lors de la réconciliation d’événements webhook ou de la correspondance entre profils du tableau de bord et un utilisateur sous-jacent — utilisez plutôt l’identifiant côté store.

Champ	Utilisation
store_original_transaction_id	Identifier une chaîne d’abonnements entre plusieurs profils. Unique par abonnement Apple.
profiles_sharing_access_level (champ webhook)	Tous les profils actuellement autorisés par l’abonnement, lorsque le partage est activé.
profile_id	Non adapté au suivi inter-profils — chaque héritier possède le sien.

Transactions sans profil

Certaines transactions dans Adapty ne sont rattachées à aucun profil — elles apparaissent dans les analyses et les exports, mais pas dans la liste des profils. Cela se produit pour les notifications S2S (serveur à serveur) du store envoyées pour des utilisateurs dont les comptes ne se sont jamais connectés à votre application via le SDK Adapty. Les sources connues sont :

• Notifications S2S de l’App Store (y compris les événements de remboursement)
• Notifications S2S de Google Play
• Événements webhook Stripe et Paddle

Ces transactions :

• Apparaissent dans les graphiques d’analyse (ils comptent dans les métriques globales)
• Apparaissent dans les exports (S3, GCS, BigQuery) avec profile_id défini sur null
• N’apparaissent pas dans la liste des profils — il n’y a pas de profil auquel les rattacher

Si vous constatez plus d’événements dans les analyses ou les exports que dans l’interface Profils, la différence correspond probablement à ces transactions sans profil. Pour les retrouver dans un export, filtrez les lignes où profile_id IS NULL.

Partager l’accès payant entre les comptes utilisateurs

Pour définir votre politique de partage de niveau d’accès, rendez-vous sur la page des paramètres General et sélectionnez une option de partage. Vous pouvez définir une politique distincte pour l’environnement sandbox.

Activé (par défaut)

Les utilisateurs identifiés (ceux avec un Customer User ID) peuvent partager le même niveau d’accès fourni par Adapty 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 un autre e-mail — il conserve 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.

Même si le niveau d’accès est partagé, toutes les transactions passées et futures sont enregistrées comme événements dans le Customer User ID d’origine pour maintenir des analyses cohérentes et conserver un historique complet des transactions — incluant les périodes d’essai, les achats d’abonnements, les renouvellements et plus encore, liés au même profil.

Transférer l’accès au nouvel utilisateur

Les utilisateurs identifiés peuvent continuer à accéder au niveau d’accès fourni par Adapty, même s’ils se connectent avec un Customer User ID différent ou réinstallent l’application, tant que l’appareil est connecté au même identifiant Apple/Google.

Contrairement à l’option précédente, Adapty transfère l’achat entre les utilisateurs identifiés. Cela garantit que le contenu acheté est disponible, mais un seul utilisateur peut y avoir accès à la fois. Par exemple, si UserA achète un abonnement et que UserB se connecte sur le même appareil et restaure ses transactions, UserB obtient l’accès à l’abonnement, et celui-ci est révoqué pour UserA.

Si l’un des utilisateurs (nouveau ou ancien) n’est pas identifié, le niveau d’accès sera quand même partagé entre ces profils dans Adapty.

Bien que le niveau d’accès soit transféré, toutes les transactions passées et futures sont enregistrées comme événements dans le Customer User ID d’origine pour maintenir des analyses cohérentes et conserver un historique complet des transactions — incluant les périodes d’essai, les achats d’abonnements, les renouvellements et plus encore, liés au même profil.

Après être passé à Transférer l’accès au nouvel utilisateur, les niveaux d’accès ne seront pas transférés entre les profils immédiatement. Le processus de transfert pour chaque niveau d’accès spécifique est déclenché uniquement lorsqu’Adapty reçoit un événement du store, comme le renouvellement d’un abonnement, une restauration, ou lors de la validation d’une transaction.

Désactivé

Le premier profil d’utilisateur identifié à obtenir un niveau d’accès le conservera indéfiniment. C’est la meilleure option si votre logique métier exige que les achats soient liés à un seul Customer User ID.

Notez que les niveaux d’accès sont toujours partagés entre les utilisateurs anonymes.

Vous pouvez « dissocier » un achat en supprimant le profil de l’utilisateur propriétaire. Après la suppression, le niveau d’accès devient disponible pour le premier profil utilisateur qui le réclame, qu’il soit anonyme ou identifié.

La désactivation du partage n’affecte que les nouveaux utilisateurs. Les abonnements déjà partagés entre utilisateurs continueront d’être partagés même après la désactivation de cette option.

Quel paramètre choisir ?

Mon application…	Option à choisir
N’a pas de système de connexion et utilise uniquement les identifiants de profil anonymes d’Adapty.	Utilisez l’option par défaut, car les niveaux d’accès sont toujours partagés entre les identifiants de profil anonymes pour les trois options.
Dispose d’un système de connexion optionnel et permet aux clients d’effectuer des achats avant de créer un compte.	Choisissez Transférer l’accès au nouvel utilisateur pour garantir que les clients qui achètent sans compte peuvent quand même restaurer leurs transactions ultérieurement.
Exige que les clients créent un compte avant d’acheter, mais permet que les achats soient liés à plusieurs Customer User IDs.	Choisissez Transférer l’accès au nouvel utilisateur pour garantir qu’un seul Customer User ID a accès à la fois, tout en permettant aux utilisateurs de se connecter avec un Customer User ID différent sans perdre leur accès payant.
Exige que les clients créent un compte avant d’acheter, avec des règles strictes liant les achats à un seul Customer User ID.	Choisissez Désactivé pour garantir que les transactions ne sont jamais transférées entre comptes.

Horodatages d’événements avec des dates futures (Apple/iOS)

Ce comportement est spécifique à l’App Store d’Apple. Le système de notifications de Google Play n’envoie pas d’événements à l’avance.

Les horodatages d’événements dans les profils et les intégrations peuvent afficher des dates futures, car Apple envoie les événements de renouvellement à l’avance.

• Pourquoi cela se produit : Apple procède ainsi pour s’assurer que les abonnements se renouvellent automatiquement avant leur expiration, évitant ainsi toute interruption de service pour l’utilisateur. Pour plus de détails, consultez le Forum des développeurs Apple : Server Notifications for Subscriptions.
• Types d’événements concernés : En général, cela s’applique aux renouvellements d’abonnement et aux conversions d’essai en abonnement payant. Ces événements peuvent avoir des horodatages futurs, car Apple en notifie les systèmes à l’avance.
• Autres types d’événements : Les achats intégrés supplémentaires et les changements de formule d’abonnement sont enregistrés avec leurs horodatages réels, car ces événements ne peuvent pas être anticipés.
• Impact sur Analytics et le fil d’événements : Ces événements n’apparaîtront dans Analytics et dans l’Event Feed qu’une fois leurs horodatages dépassés. Les événements dont l’horodatage est dans le futur ne sont affichés dans aucune de ces deux sections.
• Impact sur les intégrations : Adapty envoie les événements aux intégrations dès leur réception. Si un événement a un horodatage futur, Adapty le transmet à votre intégration avec cet horodatage futur inchangé.

Étapes suivantes

• Pour utiliser le tableau de bord Profiles afin de trouver et gérer les utilisateurs, consultez Profiles.
• Pour configurer l’identification des utilisateurs dans votre app, consultez le guide SDK identifier les utilisateurs.
• Pour configurer la politique de partage d’accès, consultez Partager l’accès payant entre les comptes utilisateurs.