Deferred deep linking sans SDK : comment ça marche vraiment sous le capot
On peut transporter le contexte d’un lien à travers une installation sans embarquer de SDK d’attribution. Voici ce qui survit réellement à la frontière du store sur Android et iOS, ce qui casse, et le coût de chaque contournement en matière de vie privée.
Le contexte meurt à la frontière du store
Quelqu’un touche un lien vers /product/42. L’app n’est pas installée, votre redirection l’envoie donc vers le store. Il installe, ouvre l’app et atterrit sur un écran d’accueil générique. La requête HTTP qui portait son intention s’est arrêtée à la fiche du store : l’app fraîchement installée démarre sans URL, sans cookie, sans referrer. Rien du clic n’a survécu.
Transporter ce contexte à travers l’installation, c’est le deferred deep linking, et la réponse standard est « embarquez un SDK de MMP ». Beaucoup d’équipes n’en veulent pas — le fil 772811 des Apple Developer Forums n’est qu’un exemple parmi d’autres demandant comment faire sans SDK tiers — et l’audience s’est élargie en août 2026, quand AppsFlyer a sorti le deferred deep linking de son plan gratuit. Alors, peut-on le construire soi-même ? Sur Android, oui, proprement et officiellement. Sur iOS, à peu près, via des contournements aux coûts bien réels.
Une note de périmètre : ce qu’est le deferred deep linking et quand il rapporte, nous le couvrons dans un autre article. Ce billet ne parle que de la tuyauterie : quel transport peut faire passer un jeton à travers une installation, et à quel point s’y fier.
Ce qui survit à l’installation, et ce qui ne survit pas
Android : l’Install Referrer API, la bonne nouvelle honnête
Google Play résout cela nativement. L’URL du store accepte un paramètre referrer, Play stocke cette chaîne avec l’installation, et l’app la relit à l’identique après le premier lancement via l’Install Referrer API. C’est tout le mécanisme : pas de fingerprinting, pas de presse-papiers, pas de devinette.
Ce n’est pas tout à fait « zéro code » : lire la valeur demande la librairie com.android.installreferrer, un petit artefact qui parle localement à l’app Play Store. Aucun appel réseau vers qui que ce soit, aucun SDK d’analytics qui téléphone à la maison, et rien à ajouter à vos déclarations de confidentialité au-delà de ce que vous faites de la chaîne.
Ce que vous mettez dans le paramètre vous appartient : un ID de lien, une campagne, une cible de deep link encodée. Restez court et URL-encodé — le referrer de play.google.com/store/apps/details?id=com.example&referrer=tok_8f2 revient exactement tel qu’envoyé.
La boucle complète, de bout en bout
- 1Au tap, votre redirection ajoute referrer=<token> à l’URL Play ; le jeton pointe vers le contexte du clic stocké côté serveur.
- 2Au premier lancement, l’app connecte un InstallReferrerClient et lit la chaîne installReferrer.
- 3L’app échange le jeton auprès de votre API contre le contexte stocké — chemin du deep link, campagne — et route l’utilisateur.
- 4Votre serveur marque le jeton comme consommé. La chaîne persiste sur l’appareil ; l’usage unique doit donc vivre côté serveur.
Les limites sont étroites et prévisibles : l’API ne couvre que les installations passées par Google Play. Sideload, Huawei AppGallery et autres stores ne portent pas de referrer Play, et la valeur doit être lue une fois, peu après le premier lancement.
Les liens Appy font déjà la moitié Android
Depuis septembre 2026, chaque lien Appy qui envoie quelqu’un vers une fiche Google Play ajoute le paramètre referrer tout seul. Rien à configurer, aucun SDK à ajouter. Le referrer contient toujours appy_slug, le slug du lien touché, pour que l’app sache quel lien a amené l’installation. Cette partie fonctionne sur toutes les offres, Free comprise.
Si la transmission des paramètres est activée sur le lien, la query string du clic entre aussi dans le referrer. Un QR code qui pointe vers appy.to/summer?screen=product-42&utm_source=poster arrive au premier lancement sous la forme de la chaîne ci-dessous. Rien n’est stocké de notre côté pour cela, et rien n’est deviné par rapprochement.
- Scanné ou touché
- https://appy.to/summer?screen=product-42&utm_source=poster
- Envoyé à Google Play
- https://play.google.com/store/apps/details?id=com.example.app&referrer=appy_slug%3Dsummer%26screen%3Dproduct-42%26utm_source%3Dposter&screen=product-42&utm_source=poster
- Lu par l’app au premier lancement
- appy_slug=summer&screen=product-42&utm_source=poster
Le réglage dans le tableau de bord
La transmission des paramètres est un interrupteur par lien sur l’offre Business. À la création d’un lien, c’est l’option « Activer la transmission des paramètres » ; sur un lien existant, le même réglage s’appelle « Transmettre les paramètres entrants ». Désactivé, le referrer contient toujours appy_slug, et rien d’autre.
Quelques règles utiles. Ce que vous avez écrit vous-même dans l’URL Play est prioritaire : si la destination contient déjà referrer=utm_source%3Dposter, Appy garde cette valeur et ajoute appy_slug à côté. appy_slug ne peut pas être écrasé depuis la query string, un lien ne peut donc pas s’attribuer les installations d’un autre. Et si les paramètres transmis faisaient dépasser 1 Ko au referrer, Appy les abandonne et ne garde que le slug.
Les paramètres circulent en clair. Pour un nom de campagne ou un identifiant d’écran, aucun souci. Pour une donnée personnelle, ou plus de quelques valeurs, transmettez un jeton court et résolvez-le sur votre serveur, comme dans le schéma décrit plus bas.
Le lire dans l’app
Ajoutez la bibliothèque Install Referrer, lisez la valeur une fois au premier lancement et analysez-la comme une query string. Voici tout le côté client :
implementation("com.android.installreferrer:installreferrer:2.2")fun readAppyReferrer(context: Context, onResult: (Map<String, String>) -> Unit) {
val client = InstallReferrerClient.newBuilder(context).build()
client.startConnection(object : InstallReferrerStateListener {
override fun onInstallReferrerSetupFinished(responseCode: Int) {
val raw = if (responseCode == InstallReferrerClient.InstallReferrerResponse.OK) {
runCatching { client.installReferrer.installReferrer }.getOrNull()
} else null
client.endConnection()
val uri = Uri.parse("?" + raw.orEmpty())
onResult(uri.queryParameterNames.associateWith { uri.getQueryParameter(it).orEmpty() })
}
override fun onInstallReferrerServiceDisconnected() = Unit
})
}
readAppyReferrer(this) { params ->
val slug = params["appy_slug"] ?: return@readAppyReferrer
params["screen"]?.let { openScreen(it) }
analytics.logInstallSource(slug, params["utm_source"])
}Exécutez-le seulement au premier lancement après l’installation, et retenez que c’est fait. Le referrer reste sur l’appareil : le lire à chaque démarrage à froid renverrait les gens sans cesse vers le même écran. Les installations depuis AppGallery ou par APK arrivent sans referrer ; ouvrez simplement l’écran d’accueil normal.
iOS : pas d’équivalent officiel, trois contournements classés
Apple ne fournit rien qui ressemble à l’Install Referrer. Une fiche App Store ne transporte pas de paramètres arbitraires à travers l’installation ; tout ce qui suit est un contournement bâti sur cette absence. Du moins mauvais au plus niche :
Passage par le presse-papiers
01 · fiabilité moyenne, sous permissionVotre page de clic écrit un jeton court dans le presse-papiers — derrière un tap de bouton, Safari exigeant un geste utilisateur pour copier — puis renvoie vers l’App Store. À la première ouverture, l’app lit le presse-papiers, trouve le jeton et l’échange avec votre serveur.
Le hic est arrivé avec iOS 16 : lire le presse-papiers déclenche l’invite de collage du système. L’utilisateur voit « Autoriser à coller depuis Safari ? » sur le tout premier écran d’une app installée trente secondes plus tôt, et beaucoup refusent. Le refus est une perte silencieuse — indiscernable de « aucun jeton n’existait ». UIPasteboard.detectPatterns vérifie un motif sans invite, mais ne lit pas la valeur. Et le presse-papiers peut être écrasé entre le tap et l’ouverture. Ça marche, souvent et mesurablement, mais la deuxième face de la pièce est bien visible.
Le matching probabiliste, fait honnêtement
02 · une estimation avec score, jamais une certitudeAu clic, le serveur garde une trace brève : quel lien, quelle plateforme, la version d’OS tirée du user agent, un horodatage et un moyen de reconnaître le réseau d’où vient le clic. À la première ouverture, l’app demande un clic récent qui ressemble au même téléphone sur le même réseau. Aucun jeton ne voyage. La correspondance est une estimation ; toute la question est de savoir si l’outil l’admet.
Fait à la légère, il mérite sa mauvaise réputation : des adresses IP brutes gardées pendant des jours, le meilleur candidat renvoyé comme s’il était certain, et un inconnu sur le même Wi-Fi de bureau capable de s’approprier le parrainage d’un autre. Les signaux sont aussi plus faibles qu’ils n’en ont l’air. iCloud Private Relay masque les adresses, le CGNAT met de nombreux téléphones derrière une seule, Chrome sur Android annonce Android 10 pour tous les téléphones, et Safari sur iOS 26 fige sa version à 18.6.
Fait avec soin, cela reste une estimation, mais une estimation utile. Attribuez un score à chaque candidat et renvoyez-le avec les signaux qui l’expliquent. Ne laissez jamais une estimation atteindre la certitude. Laissez l’app choisir son seuil, et ne consommez pas un clic dont le score est inférieur, pour que le téléphone qui a vraiment cliqué puisse encore le réclamer. Gardez la fenêtre courte et ne stockez aucune adresse IP. Le SDK Enterprise d’Appy garde tout cela côté Appy. Votre app reçoit le lien ou rien, votre backend peut savoir si une installation a été vérifiée, et les réseaux sont reconnus grâce à un hash à clé de l’adresse, qui change chaque jour et expire au bout de deux heures. Avec l’attribution stricte, seules les installations vérifiées comptent ; tout le reste est organique.
App Clips et autres voies de niche
03 · fiable mais étroitUn App Clip invoqué depuis votre lien reçoit l’URL complète et peut transmettre le contexte à l’app complète via un conteneur partagé après installation. Dans sa niche, c’est la voie iOS la plus fiable — mais il faut construire et maintenir un App Clip, et cela ne convient qu’aux flux où une expérience instantanée légère a du sens. Les shared web credentials règlent la continuité de session, pas le contexte général du lien. Bon à savoir, rarement la réponse.
Le motif de conception qui tient quel que soit le mécanisme
Quel que soit le transport du jeton — chaîne referrer, presse-papiers, voire ID de correspondance probabiliste — l’architecture côté serveur est la même, et la réussir compte plus que le transport. Ne fourrez pas tout le deep link dans le canal : stockez le contexte du clic sur votre serveur et ne déplacez qu’une clé à courte durée de vie.
Stockez le contexte sous un jeton aléatoire
Au clic, écrivez {deep_link, campagne, horodatage} sous un jeton court et aléatoire, et ne mettez que le jeton dans le transport. Les charges restent petites, les données de campagne ne traînent ni dans les presse-papiers ni dans les logs, et vous pouvez changer la définition du « contexte » sans toucher au client.
Expirez agressivement
Un TTL de 30 à 60 minutes couvre le vrai trajet tap-installation. Une route différée résolue une semaine après le clic se trompe plus souvent qu’elle ne tombe juste.
Imposez l’usage unique
Consommez le jeton au premier échange. Les chaînes referrer persistent et un presse-papiers se lit deux fois ; sans usage unique, une réinstallation ou un second appareil peut rejouer le contexte de quelqu’un d’autre.
Échouez vers le défaut, pas vers une supposition
Pas de jeton, jeton expiré, invite refusée : posez l’utilisateur sur l’écran d’accueil normal. Une première ouverture générique déçoit un peu ; atterrir dans le panier d’un autre utilisateur, c’est un ticket de support.
La fiabilité, dite honnêtement
Chiffres approximatifs d’équipes qui exploitent ces mécanismes en production. Votre mix de sources, le délai d’installation et la version iOS de votre audience font bouger chaque nombre.
| Mécanisme | Plateforme | Fiabilité | Notes |
|---|---|---|---|
| Play Install Referrer | Android | Élevée | API officielle, survit aux installations différées, aucune invite. Installations Play uniquement. |
| Jeton presse-papiers | iOS | Moyenne | Conditionné par l’invite de collage d’iOS 16+ ; les refus sont silencieux ; le presse-papiers est volatil. |
| Matching probabiliste avec score | iOS, Android sans referrer | Moyenne, avec score | Même réseau, version d’OS et délai. Solide sur le même Wi-Fi quelques minutes après le clic ; faible d’un réseau à l’autre, derrière un CGNAT ou Private Relay. À n’utiliser qu’avec un score visible et un seuil. |
| Relais App Clip | iOS | Élevée, étroite | Déterministe, mais seulement pour les flux qui justifient un App Clip. |
Ce que cela signifie pour votre stack
Si votre besoin de routage différé est Android uniquement, il vous faut très peu : un lien qui ajoute le paramètre referrer, la petite librairie et un endpoint d’échange de jetons. C’est une après-midi de travail, et c’est réellement sans SDK au sens qui compte : aucun code tiers n’observe vos utilisateurs.
iOS est là où les solutions managées gagnent leur pain, parce que les contournements y sont le produit : l’infrastructure de matching, un modèle de score qu’il faut garder honnête, et chaque version d’OS qui déplace le terrain, comme iOS 26 qui fige la version de Safari. C’est pourquoi le SDK iOS et Android d’Appy, avec le deferred deep linking et l’attribution des installations, fait partie du plan Enterprise, alors que le referrer Android est fourni avec chaque lien.
Soyez honnête sur le problème que vous avez. Si votre vrai besoin est « les utilisateurs qui ont déjà l’app doivent atterrir sur le bon écran », c’est du deep linking standard, sans frontière d’installation. Le shim de deep links d’Appy couvre ce cas sur le plan Pro à 9,99 $/mois, redirige vers le store quand l’app n’est pas installée, toujours sans SDK. Mesurez la part de votre entonnoir qui est vraiment « installation neuve avec contexte » avant d’acheter la machinerie lourde.
À lire ensuite
Questions fréquentes
L’Install Referrer fonctionne-t-il depuis un scan de QR ?
Oui, à condition que le QR se résolve via un lien qui ajoute le paramètre referrer à l’URL Play. Le mécanisme ignore comment le clic a commencé — scan, tap ou NFC — seul compte le fait que l’URL du store portait le referrer à l’ouverture de Play. Un QR pointant vers une URL Play nue ne transporte rien.
Pourquoi mon approche par jeton presse-papiers a-t-elle soudain cassé ?
Presque certainement l’invite de collage d’iOS. Depuis iOS 16, la première lecture du presse-papiers déclenche un dialogue de permission, et une part significative des utilisateurs refuse. Votre code n’a pas régressé ; votre lecture a désormais un humain dans la boucle. Vérifiez si votre taux de jetons trouvés a baissé plutôt que tombé à zéro : c’est la signature.
Le matching probabiliste est-il autorisé sur iOS ?
Le contrat développeur d’Apple interdit de dériver des données d’un appareil pour l’identifier de façon unique, et App Review peut rejeter les apps dont les SDK le font. Une empreinte qui reconnaît un téléphone d’une app à l’autre, et pendant des semaines, franchit cette limite. Comparer un clic et une première ouverture sur le même réseau en moins de deux heures, pour votre propre lien, sans stocker d’IP et avec un score, est bien plus restreint, mais vous déclarez tout de même ces données dans vos informations de confidentialité. Quel que soit l’outil, demandez ce qu’il stocke, pendant combien de temps, et s’il vous prévient quand il devine.
Ai-je vraiment besoin de deferred deep linking ?
Seulement si l’écran d’atterrissage post-installation change matériellement votre entonnoir. Si la plupart des installations viennent de campagnes génériques sans destination précise, un bon onboarding rapporte plus. Mesurez d’abord : comptez les clics avec une vraie cible de deep link et une app non installée. Si le nombre est petit, investissez ailleurs.
Continuer à explorer
Identifiez le lien derrière chaque installation : le SDK iOS et Android d’Appy
Appy suit désormais vos liens au-delà du store. Le nouveau SDK montre les installations, les événements in-app et les revenus de chaque lien, QR code et campagne, et ouvre l’app des nouveaux utilisateurs sur le bon écran.
Chrome dit à chaque serveur que votre téléphone tourne sous Android 10
Chrome sur Android annonce Android 10, modèle K, pour tous les téléphones. Ce que cela a cassé dans le matching des deferred deep links, pourquoi Critical-CH compterait chaque clic deux fois, et comment les Client Hints permettent de retrouver la vraie version et le vrai modèle.
Deferred deep linking : comment ça marche et quand l’utiliser
Transportez l’intention initiale du lien à travers l’installation pour que les nouveaux utilisateurs arrivent sur la bonne page et non sur la home par défaut.
Vous cherchez autre chose ? Parcourez tous les sujets sur le blog.
Routez les installations que vous avez déjà gagnées
L’install referrer de Google Play sur chaque lien, et, dès le plan Pro, des deep links qui redirigent vers le store quand l’app n’est pas installée, sans SDK dans votre app. Quand il vous faut des deferred deep links et l’attribution des installations sur iOS et Android, le SDK Enterprise rattache chaque installation au lien qui l’a générée.
Commencer avec Appy