Suivi d’affiliation pour apps mobiles : installations et abonnements sans MMP

Pourquoi le suivi est plus difficile dans une app que sur le web

Sur le web, le suivi d’affiliation est un problème résolu. Un visiteur touche le lien d’un créateur, un cookie ou un paramètre d’URL enregistre la recommandation, et le paiement sur le même site rattache la vente au créateur. Une app mobile rompt cette chaîne à deux endroits : l’App Store ou Google Play s’intercale entre le lien et le premier lancement, et le paiement passe par Apple ou Google plutôt que par votre propre caisse.

Le suivi d’affiliation mobile comprend donc deux tâches distinctes. L’attribution répond à la question : quel créateur a amené cet utilisateur ? La vérification répond à une autre : cet achat est-il réel, et quelle est sa valeur ? Un MMP fait la première pour la publicité payante. Un programme créateurs a besoin des deux, personne par personne, car en fin de mois vous versez de l’argent à quelqu’un.

Les méthodes d’attribution, et ce que chacune peut voir

Chaque méthode ci-dessous connaît le créateur avec certitude ou fait une estimation. Utilisez les méthodes exactes partout où c’est possible, et laissez la solution de repli attraper le reste.

• Un code saisi par l’utilisateur. Le créateur dit « utilisez le code MAYA » dans une vidéo ou un podcast, et l’utilisateur le saisit dans un champ de votre onboarding ou de votre paywall. C’est une action explicite de l’utilisateur, identique sur iOS et Android, qui ne demande aucune autorisation. C’est aussi la seule méthode qui fonctionne sans lien à toucher : audio, lives, bouche-à-oreille.

• Un lien qui transmet le code à l’app. Quand l’app est déjà installée, un universal link ou un Android App Link peut l’ouvrir avec le code dans l’URL ; les apps web, les PWA et les apps Capacitor ou Cordova peuvent lire le code dans leur URL de lancement. Ce qui ne marche pas sur iOS, c’est de transmettre un paramètre à travers une installation depuis l’App Store : l’App Store ne transmet rien du lien à votre app au premier lancement.

• Le Google Play Install Referrer. Sur Android, Google Play conserve le paramètre referrer du lien Play Store et permet à votre app de le lire après l’installation via l’API Play Install Referrer, avec les horodatages du clic et de l’installation. Un lien de créateur qui place le code dans le referrer donne une correspondance exacte. iOS n’a pas d’équivalent.

• Un code que votre app connaît déjà. Si votre propre deep link ou parcours promo capture le code, enregistrez-le sur l’utilisateur. Avec RevenueCat, cela revient à l’écrire comme attribut d’abonné, de sorte que chaque événement d’achat porte le code du créateur.

• Le rapprochement des clics, en solution de repli. Quand quelqu’un touche le lien d’un créateur, installe l’app depuis le store et que le code n’arrive jamais dans l’app, l’installation peut être rattachée au clic récent sur ce lien. C’est une méthode au mieux : limitez-la à une courte fenêtre et à votre propre app, et laissez toute méthode exacte prévaloir.

• Attribution publicitaire. SKAdNetwork et AdAttributionKit sur iOS, ainsi que les liens de suivi des MMP, mesurent les installations issues de publicités. Ils sont conçus pour les campagnes payantes, pas pour rémunérer chaque créateur (plus de détails ci-dessous).

Quand les méthodes se contredisent, la règle doit être simple et écrite. Chez InfluTo, un code saisi l’emporte sur un clic de lien, le plus récent de plusieurs clics gagne, et dès que le premier achat d’un utilisateur est attribué, ce créateur le garde pour tous les renouvellements.

Méthode par méthode : ce qui est exact et où ça marche

Exact signifie que le créateur est connu avec certitude, sans modélisation.

Ce qu’Apple autorise sans IDFA ni ATT

Apple exige l’invite App Tracking Transparency pour le suivi. Elle le définit comme le fait de relier les données de votre app à celles d’apps, de sites web ou de points de vente d’autres entreprises à des fins de publicité ciblée ou de mesure publicitaire, ou de les partager avec des courtiers en données. L’IDFA, l’identifiant publicitaire d’Apple, n’est disponible qu’après accord de l’utilisateur.

Apple interdit aussi le fingerprinting, avec ou sans consentement. Son contrat développeur précise que vous ne pouvez pas tirer d’un appareil des données pour l’identifier de façon unique, et les apps qui intègrent des SDK le faisant peuvent être refusées. Cela exclut de rapprocher des installations en combinant modèle d’appareil, taille d’écran, fuseau horaire ou signaux similaires.

L’attribution directe des créateurs n’a besoin ni de l’un ni de l’autre. Un code saisi est une donnée fournie par l’utilisateur, et un lien exact transmet un code, pas une identité. InfluTo ne lit jamais l’IDFA ni aucun identifiant publicitaire, et sa documentation indique de ne pas demander l’ATT pour cela. Son rapprochement par clic de lien ne compare jamais les caractéristiques de l’appareil, comme le modèle, la taille d’écran ou le fuseau horaire, ne relie rien entre d’autres apps ou sites web, et tranche uniquement entre « recommandé par ce créateur » et organique.

Où SKAdNetwork a sa place, et où il n’en a pas

SKAdNetwork, et AdAttributionKit qui s’appuie dessus, sont les cadres d’Apple pour l’attribution publicitaire respectueuse de la vie privée. Un réseau publicitaire enregistré signe ses impressions. Si l’utilisateur installe et ouvre l’app dans la fenêtre d’attribution, l’appareil envoie un postback différé au réseau publicitaire, et à vous si vous l’activez, avec une valeur de conversion et sans identité d’utilisateur.

Cette conception explique pourquoi il ne peut pas faire tourner un programme de créateurs. La légende ou le lien en bio d’un créateur n’est pas une impression publicitaire signée, un postback ne dit pas lequel de vos 50 créateurs a généré une installation, et il ne peut pas suivre les renouvellements et remboursements d’un abonné mois après mois. Si vous sponsorisez la vidéo d’un créateur comme une publicité payante, mesurez-la avec le réseau publicitaire et votre MMP, comme n’importe quelle campagne, et gardez le code et le lien du créateur pour la commission.

Payez sur des achats vérifiés, pas sur des installations

Une installation est une mauvaise base de paiement. Beaucoup d’installations n’atteignent jamais le paywall, beaucoup d’essais ne se convertissent pas, et le nombre d’installations est le chiffre le plus facile à gonfler. Pour une app d’abonnement, ce qui compte, c’est un achat payant, et il doit être vérifié auprès du store avant tout mouvement d’argent :

• Un achat peut être faux ou être un test. Un achat signalé uniquement par l’app peut venir d’un compte sandbox, de TestFlight ou d’un client modifié. Apple et Google peuvent confirmer si une transaction est réelle et de quel environnement elle provient.

• Les renouvellements se font sans l’app. Un abonné qui renouvelle au septième mois n’a peut-être pas ouvert votre app depuis des semaines. Seul le store, ou un service qui l’écoute, voit ce renouvellement.

• Les remboursements viennent du store. Apple et Google traitent les remboursements et les rétrofacturations. Votre système de commissions doit en être informé pour annuler ce qu’il a crédité.

Il existe deux façons courantes d’obtenir des événements d’achat vérifiés : un webhook RevenueCat si vous utilisez déjà RevenueCat, ou directement l’App Store Server API et la Google Play Developer API. InfluTo prend en charge les deux, avec un seul chemin par plateforme. Il n’enregistre une commission qu’une fois l’achat confirmé par le store, l’annule en cas de remboursement, et ne verse jamais d’argent pour des achats sandbox.

Une configuration qui fonctionne sans MMP

1. 1

   Donnez à chaque créateur un code et un lien. Le même code court fonctionne saisi ou dans le lien : un créateur peut le dire dans une vidéo et le mettre dans sa bio.

2. 2

   Ajoutez un champ de code avant le premier achat. Une étape facultative « Vous avez un code ? » dans l’onboarding touche la plupart des gens, et un petit lien sur le paywall touche les autres. Préremplissez-la quand l’installation a déjà été rapprochée : l’utilisateur n’a plus qu’à confirmer.

3. 3

   Vérifiez l’attribution au premier lancement. Interrogez le SDK au lancement, avant que le paywall décide quoi afficher. Ainsi, un rapprochement par clic de lien ou un code porté par l’URL de lancement ou l’Install Referrer est pris en compte dans la même session.

4. 4

   Connectez une source d’achats vérifiés. Soit le webhook RevenueCat, avec le code du créateur écrit comme attribut d’abonné, soit la validation directe auprès des stores avec vos identifiants App Store et Google Play.

5. 5

   Testez un achat parrainé de bout en bout. Sur un build sandbox, installez l’app via le lien d’un créateur de test ou saisissez son code, achetez, puis vérifiez que l’achat apparaît bien attribué à ce code avant d’inviter de vrais créateurs.

Quand avez-vous encore besoin d’un MMP ? Quand vous achetez de la publicité sur plusieurs réseaux et voulez une vue unique du réseau qui mérite le crédit. Les deux couches ne s’opposent pas : le MMP continue de mesurer les campagnes payantes, et la plateforme créateurs paie sur des achats vérifiés par les stores. Le guide MMP et plateformes d’affiliation, plus bas, détaille la répartition.