Dépannage

Commencez par activer les logs de debug : ils disent exactement ce que le SDK a fait et pourquoi. Voir Logs de debug. Cherchez le tag Unolink dans Logcat, ou [Unolink] dans la console Xcode.

Rien n’apparaît dans le tableau de bord

  • Activez Inclure les appareils de test dans Entonnoir ou Parcours. Les builds de debug sont des appareils de test et sont masqués par défaut.
  • Vérifiez que configure s’exécute. Il doit être appelé une seule fois, tôt : Application.onCreate() sur Android, l’init() de l’App @main sur iOS, le layout racine en React Native, main() en Flutter.
  • Envoyez les événements maintenant. Les événements partent toutes les 15 secondes tant que l’app est ouverte, et quand elle passe en arrière-plan. Appuyez sur le bouton d’accueil, ou appelez flush().
  • Vérifiez le réseau. Hors ligne, les événements attendent sur l’appareil et sont envoyés dès que le réseau revient.

"Invalid SDK key (401)"

La clé est fausse, appartient à une autre app ou a été révoquée. Copiez-la à nouveau depuis votre app → Paramètres → Clés SDK. Si vous ne l’avez pas enregistrée à sa création, créez une nouvelle clé : la clé complète n’est affichée qu’une fois. Après un 401, rien n’est envoyé avant le lancement suivant.

Le SDK fait partie du forfait Pro et plus. Le propriétaire de l’app doit mettre à niveau son forfait dans Facturation. En attendant, le SDK n’envoie rien et ne garde rien en file d’attente.

Des événements manquent

  • Nom invalide. Les noms d’événements commencent par une lettre et n’utilisent que des lettres, des chiffres, _ et ., 64 caractères au maximum. Les noms invalides sont rejetés et logués.
  • Trop de propriétés. Au maximum 20 par événement, des chaînes de 200 caractères au plus, 4 Ko au total.
  • Identifiants d’écran d’onboarding invalides. step et flow suivent la même règle que les noms d’événements : how_heard, pas how-heard. Dans les builds de développement, le SDK React Native (0.3.1 ou ultérieur) affiche un avertissement dans la console.
  • Très au-delà de l’allocation mensuelle. Rien n’est bloqué à votre allocation. Ce n’est qu’au-delà du double de l’allocation que vos propres événements (personnalisés) sont rejetés, avec quota_exceeded ; les événements standard de l’entonnoir sont toujours enregistrés.
  • Appelé avant configure. Les SDK natifs iOS et Android ignorent les appels faits avant configure. React Native (0.3.1 ou ultérieur) les garde et les envoie juste après.
  • Suivi désactivé. setEnabled(false) arrête le suivi, et ce choix est conservé d’un lancement à l’autre.

Achats ou essais comptés deux fois, ou pas du tout

  • RevenueCat est connecté ? Alors RevenueCat remonte les essais et les achats, et les appels de l’app à purchase et trialStarted sont ignorés. Supprimez-les si vous voulez ; ils ne font aucun mal.
  • Les achats RevenueCat ne sont pas reliés à l’installation ? Signalez le propre identifiant utilisateur d’app de RevenueCat. Avec le SDK 0.3.2 ou plus récent, connectRevenueCat le tient à jour (voir RevenueCat). Sinon, appelez setUserId avec (Purchases.shared.appUserID, Purchases.sharedInstance.appUserID, Purchases.getAppUserID() ou Purchases.appUserID) après Purchases.configure, après chaque Purchases.logIn et Purchases.logOut, et à chaque lancement. Un achat qui arrive avant que l’app ait remonté son utilisateur attend, et est relié dès que c’est fait. Chaque identifiant utilisateur remonté par une installation compte, donc un invité qui achète puis crée un compte garde son achat. Si l’app ne signale que l’identifiant du compte, l’achat d’un invité n’est relié qu’avec le prochain événement RevenueCat pour ce client (par exemple le premier renouvellement). Voir Invités et comptes.
  • Pas de RevenueCat ? Appelez purchase avec le prix en nombre décimal et un code de devise à trois lettres, une fois que le store a confirmé l’achat.
  • Sur iPhone, c’est normal. Apple n’a pas de referrer d’installation, donc les liens profonds différés sont réservés à Android.
  • Installez depuis Google Play. Les installations hors store et depuis Android Studio n’ont pas de referrer Play. Utilisez les tests internes, ou debugInstallReferrer dans un build de debug. Voir Tests.
  • Premier lancement uniquement. Le referrer est lu une fois par installation. Désinstallez l’app, ou effacez ses données, pour tester à nouveau.
  • Définissez un deep link sur le lien. Dans le tableau de bord, Liens → ⋯ → Modifier → Deep link. Un lien sans deep link attribue quand même l’installation, mais il n’y a rien à ouvrir.
  • Enregistrez le listener. Il peut être ajouté après configure : un lien arrivé plus tôt est quand même transmis. Sur React Native, il faut pour cela la version 0.3.1 ou ultérieure ; avec 0.3.0, abonnez-vous juste après configure.
  • L’écran se trouve derrière l’onboarding ou la connexion ? Le listener ne s’exécute qu’une fois par installation. Une fois l’onboarding terminé, lisez getPendingDeferredDeepLink(), ouvrez le lien, puis appelez consumeDeferredDeepLink(). À partir de 0.3.3, le lien attend que vous le consommiez, même si l’app est fermée entre-temps (jusqu’à 30 jours). Voir L’ouvrir après l’onboarding.
  • Le même lien s’ouvre à chaque lancement ? Appelez consumeDeferredDeepLink() une fois que vous l’avez ouvert.

Chaque clic n’est attribué qu’à une seule installation. Après une réinstallation, Google Play peut transmettre à nouveau le même referrer à l’app, et cette seconde installation n’est pas attribuée une seconde fois au lien. Unolink ne devine jamais.

React Native et Flutter

  • Expo Go ne fonctionne pas. Le SDK contient du code natif : faites un build de développement (npx expo prebuild ou EAS Build).
  • "Native module not found" ou MissingPluginException. Recompilez l’app après l’installation. Un rechargement JavaScript ou un hot restart Flutter ne charge pas le nouveau code natif.
  • Le build iOS échoue après l’installation. Lancez pod install dans le dossier ios (React Native sans Expo), puis recompilez.

Toujours bloqué ?

Écrivez à [email protected] avec le nom de votre app, la plateforme, la version du SDK et le log de debug d’un lancement de l’app.