Paiements et identifiants utilisateur

Unolink relie chaque paiement à l’installation à laquelle il appartient, et donc au lien ou à la publicité d’où vient cette installation. Cela fonctionne quel que soit le retard du paiement : quelqu’un qui appuie aujourd’hui sur votre publicité TikTok et s’abonne dans deux semaines compte quand même comme utilisateur payant venu de cette publicité. Forfait Pro et plus.

Comment les paiements tardifs sont comptés

  • Chaque événement appartient à une installation. Un paiement qui arrive une semaine ou un mois après l’installation est ajouté à cette même personne.
  • Les entonnoirs, les Parcours et le Rapport n’ont jamais de date limite. Une étape compte si la personne l’a faite à n’importe quel moment, donc un paiement tardif la fait quand même passer à « Payé ».
  • La période choisit des personnes, pas des événements. « 7 derniers jours » signifie les personnes qui ont installé au cours des 7 derniers jours, plus tout ce qu’elles ont fait ensuite. Regardez à nouveau les installations de la semaine dernière la semaine prochaine, et Payé a peut-être augmenté : ce sont des paiements tardifs qui arrivent, pas une erreur.
  • Les Parcours se mettent à jour d’eux-mêmes. Quelqu’un affiché comme « Partis » (aucune activité depuis une semaine) passe à « Terminé » quand son paiement arrive, et la ligne affiche « a payé 9 jours après l’installation · revenu ».

Où voir combien de temps les gens mettent

  • Rapport → Quand les gens paient : la part des installations qui paient en un jour, 7 jours et 30 jours, l’attente médiane, et combien sont revenus payer après une semaine ou plus de silence, pour tout le monde et par lien. « Sous 7 jours » ne compte que les installations d’au moins 7 jours, pour que les installations récentes ne fassent pas baisser le chiffre.
  • Parcours : chaque personne payante indique combien de jours après l’installation elle a payé pour la première fois, et si elle est revenue après une période d’inactivité.
  • Déjà abonné : quelqu’un qui s’était abonné avant cette installation (une réinstallation, un nouveau téléphone) envoie un renouvellement, pas un achat. Parcours l’affiche comme « Déjà abonné · renouvelé » et compte son argent dans les revenus, mais pas comme Payé : la vente n’a pas été faite par cette installation ni par le lien d’où elle vient.

Ce dont votre app a besoin

Les paiements arrivent dans Unolink de l’une de ces deux façons :

  1. RevenueCat (recommandé). Connectez son webhook dans votre app → Paramètres → RevenueCat. RevenueCat remonte les achats, les conversions d’essai, les renouvellements et les remboursements même quand l’app n’est pas ouverte, et c’est ainsi que se produisent la plupart des paiements tardifs (un essai gratuit qui se convertit une semaine plus tard, un renouvellement le mois suivant).
  2. L’appel purchase() du SDK, envoyé depuis l’app quand quelqu’un y paie. Suffisant sans RevenueCat, mais il ne voit rien de ce qui se passe en dehors de l’app.

Pour que les événements RevenueCat trouvent la bonne installation, l’app doit indiquer à Unolink qui est l’utilisateur, avec le propre identifiant utilisateur d’app de RevenueCat. Avec le SDK 0.3.2 ou plus récent, une seule ligne au lancement le tient à jour :

// iOS: once at launch, before or after configure
Unolink.connectRevenueCat { Purchases.isConfigured ? Purchases.shared.appUserID : nil }
// Android
Unolink.connectRevenueCat { Purchases.sharedInstance.appUserID }
// React Native
Unolink.connectRevenueCat(Purchases)
// Flutter
Unolink.connectRevenueCat(() => Purchases.appUserID,
    addListener: Purchases.addCustomerInfoUpdateListener,
    removeListener: Purchases.removeCustomerInfoUpdateListener);

Il lit l’identifiant de RevenueCat au lancement, quand l’app revient au premier plan et quand il change, et ne l’envoie que s’il est nouveau (sur iOS et Android, appelez aussi Unolink.revenueCatUserChanged() après logIn et logOut). Avant la 0.3.2, ou pour le faire vous-même, appelez plutôt setUserId avec l’identifiant de RevenueCat (par exemple Unolink.setUserId(Purchases.shared.appUserID)) après Purchases.configure, après chaque Purchases.logIn et Purchases.logOut, et à chaque lancement. Utilisez l’un ou l’autre, pas les deux. La page RevenueCat donne le code pour chaque plateforme.

Pour un invité, l’identifiant de RevenueCat est son identifiant anonyme, donc un achat fait avant l’inscription est relié à l’installation tout de suite. Après logIn, c’est l’identifiant du compte. Unolink conserve chaque identifiant signalé par une installation, donc l’achat de l’invité reste relié. Un paiement qui arrive avant que l’app ait envoyé l’identifiant utilisateur n’est pas perdu : il attend et est relié à l’installation dès que l’identifiant arrive. Sans RevenueCat, appelez setUserId avec votre propre identifiant utilisateur, et null (nil en Swift) à la déconnexion.

Quand quelqu’un appuie sur « continuer en invité », appelez aussi Unolink.signUpSkipped() (SDK 0.3.2 ou plus récent, React Native 0.3.1 ; SDK plus anciens : track("sign_up_skipped")), pour que l’étape Continué en invité de l’entonnoir les compte. Voir Invités et comptes.

Quand un paiement ne peut pas être relié

  • Ni RevenueCat ni setUserId, et la personne paie en dehors de l’app (par exemple sur votre site web). Rien n’en informe Unolink.
  • Elle réinstalle avant de payer. Pour Unolink, une nouvelle installation est une nouvelle personne, sauf si le même identifiant utilisateur les relie.
  • Elle paie sur un autre appareil. Là aussi, le lien ne se fait que par l’identifiant utilisateur.
  • Un invité paie, et l’app ne signale que l’identifiant du compte. RevenueCat envoie l’achat sous son identifiant anonyme, que l’app n’a jamais signalé. Il est quand même relié, mais seulement avec le prochain événement RevenueCat pour ce client qui liste les deux identifiants (par exemple le premier renouvellement) ; jusque-là, la personne apparaît comme n’ayant pas encore payé. Signaler l’identifiant propre de RevenueCat le relie tout de suite.

Avec RevenueCat connecté et son identifiant signalé (connectRevenueCat, ou setUserId avec l’identifiant de RevenueCat), tous ces cas sont couverts.

Confidentialité : ce n’est pas du fingerprinting

  • Le fingerprinting consiste à déterminer de quel appareil il s’agit à partir de ses caractéristiques (adresse IP, écran, polices, réglages) sans demander, généralement pour suivre la personne dans les apps d’autres entreprises. Apple l’interdit, et Unolink ne le fait jamais.
  • setUserId est l’identifiant utilisateur propre à votre app, transmis volontairement par votre app. Unolink n’en garde qu’un hash à sens unique avec clé (HMAC-SHA256 avec une clé propre à chacune de vos apps), jamais l’identifiant lui-même, et ne s’en sert que pour une chose : relier les paiements de votre app aux installations de votre app. Il n’est jamais partagé avec d’autres apps, des régies publicitaires ou qui que ce soit d’autre.
  • L’App Tracking Transparency d’Apple concerne le fait de relier les données de votre app aux apps ou sites web d’autres entreprises à des fins publicitaires, ou de les partager avec des courtiers en données. Relier vos propres achats à vos propres installations relève de l’analyse first-party, du même type que ce que font RevenueCat ou Firebase, donc aucune demande de suivi n’est nécessaire.

Dans les questions de confidentialité d’App Store Connect, Unolink avec setUserId revient généralement à : User ID et Purchases, collectés pour Analytics, liés à l’utilisateur, et non utilisés pour le suivi. Vos propres réponses dépendent de tout ce que fait votre app par ailleurs, vérifiez-les donc dans leur ensemble.