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.
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.
Matching probabiliste
02 · fiabilité faible–moyenne, hostile à la vie privéeAu clic, le serveur enregistre l’IP, le modèle d’appareil et la version d’OS tirés du user agent, et un horodatage. À la première ouverture, l’app appelle votre endpoint, qui cherche un clic aux signaux concordants dans une fenêtre courte, généralement sous la demi-heure. Aucun jeton ne voyage : la correspondance est une supposition.
Nous le décrivons parce que des fournisseurs le vendent, pas pour que vous le construisiez. Les signaux se dégradent : iCloud Private Relay masque les IP, le CGNAT met des milliers d’utilisateurs derrière une adresse, et les modèles d’appareils sont des catégories grossières. Apple décourage explicitement le fingerprinting et, à l’ère des privacy manifests, collecter ces signaux est quelque chose qu’App Review peut vous demander de justifier. La précision baisse chaque année et les faux positifs envoient de vrais utilisateurs sur le mauvais écran.
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 | iOS | Faible–moyenne | IP + modèle + fenêtre temporelle. Se dégrade sous Private Relay et CGNAT ; découragé par Apple. |
| 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 : maintenir l’infrastructure de matching, concevoir autour de l’invite de collage et suivre chaque version d’OS qui déplace le terrain. C’est aussi pourquoi c’est tarifé comme de l’infrastructure — Appy propose le deferred deep linking au niveau Enterprise, où cette maintenance devient le problème du fournisseur.
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, fallback store compris, toujours sans SDK. Mesurez la part de votre entonnoir qui est vraiment « installation neuve avec contexte » avant d’acheter la machinerie lourde.
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 par fingerprint est-il vraiment autorisé sur iOS ?
C’est une zone grise, et le terrain bouge contre lui. Les règles d’Apple interdisent le fingerprinting à des fins de tracking, les privacy manifests exigent de déclarer les signaux collectés, et App Review a déjà rejeté des apps pour cela. Certains fournisseurs le proposent encore. Si vous le construisez vous-même, le risque est le vôtre — et supposez que la précision continuera de baisser.
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
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.
Guide complet des Universal Links pour iOS et Android
Guide complet sur les universal links, deep links et app links : implémentation et bonnes pratiques pour le marketing mobile.
Link Tracking Protection sur iOS 26 : quels paramètres d’URL survivent ?
Safari supprime les click IDs comme gclid et fbclid, les UTM passent. Ce que cela change pour la mesure des installations et comment les liens first-party préservent l’attribution.
Vous cherchez autre chose ? Parcourez tous les sujets sur le blog.
Routez les installations que vous avez déjà gagnées
Deep links standard avec fallback store sur Pro, deferred deep linking sur Enterprise — les deux sans mettre de SDK dans votre app.
Commencer avec Appy