Deferred deep linking : comment ça marche et quand l’utiliser
Comprenez comment le deferred deep linking transporte l’intention initiale du lien à travers l’installation pour que les nouveaux utilisateurs arrivent sur la bonne page in-app et non sur une home générique.
Ce que le deferred deep linking résout vraiment
Un deep link classique ne fonctionne que si l’app est déjà installée. Si l’utilisateur tape un lien sans avoir l’app, l’OS l’envoie sur l’App Store ou Google Play, l’installation se termine et le contexte initial est perdu. L’app s’ouvre sur sa home par défaut sans aucun souvenir de l’intention initiale.
Le deferred deep linking transporte cette intention de l’autre côté de l’installation. Les paramètres du lien sont stockés à un endroit que l’app peut interroger au premier lancement, donc l’utilisateur arrive directement sur le produit, la campagne, le profil ou l’invitation visés. C’est la différence entre perdre l’intention à l’install et transformer les installs en vraies premières sessions.
Deep link classique
Tap sur le lien, app absente
produit · campagneApp Store ou Google Play
produit · campagneContexte perduInstallation
Premier lancement
Home génériqueDeferred deep link
Tap sur le lien, app absente
produit · campagneApp Store ou Google Play
produit · campagneInstallation
produit · campagneContexte conservéPremier lancement
L’écran viséLe fonctionnement interne du deferred deep linking
Téléphone
Service de routing
Téléphone
Tape le smart link
appy.to/go/abc
Service de routing
Enregistre le clic et son contexte
Token install referrer sur Google Play et AppGallery, sinon une trace de clic de courte durée
Téléphone
Installe depuis le store
Rien de spécial du point de vue du store
Service de routing
En attente du premier lancement
Téléphone
Premier lancement
Android lit le Play Install Referrer, iOS interroge le service de matching
Service de routing
Le lien d’origine le plus probable, ou rien
Téléphone
Ouvre l’écran prévu
Applique la campagne et reprend le parcours initial
L’utilisateur tape un smart link avec un payload
Un lien type appy.to/go/abc embarque le routing par device plus un contexte optionnel : ID produit, campagne, referrer, paramètres UTM.
Le serveur détecte l’absence de l’app et stocke le contexte
Votre service de routing enregistre le clic avec le contexte du lien. Quand le store peut transporter un token à travers l’installation (les install referrers de Google Play et de Huawei AppGallery), ce token accompagne l’installation ; sinon, le service garde brièvement une trace du clic pour la comparer au premier lancement.
L’utilisateur est redirigé vers l’App Store ou Google Play
L’installation se déroule normalement. Vu du store, rien de spécial ne se passe ; le lien initial n’est plus accessible depuis l’app.
L’app démarre pour la première fois
Sur Android, Play Install Referrer livre directement la chaîne referrer à l’app. Sur iOS, où l’App Store ne transmet rien, l’app demande au service de matching un clic récent venu du même réseau, et reçoit en retour le lien dont l’installation vient probablement, ou rien.
L’app amène l’utilisateur sur la bonne page
Une fois le payload récupéré, l’app navigue vers la page deep-linkée, applique l’attribution de campagne et poursuit le parcours initial sans landing générique.
Quand le deferred deep linking vaut le coup
Campagnes paid d’installs avec plusieurs créa
Chaque créa peut porter un payload spécifique, donc l’install arrive sur l’écran qui correspond à la pub tapée, ce qui améliore la conversion de la première session.
Flux de parrainage et d’invitation
Quiconque installe depuis un lien d’invitation est automatiquement relié au parrain, à l’élément partagé ou à l’équipe, sans saisie de code manuelle.
Codes promo et coupons
Les codes promo ou trial portés par le lien sont appliqués automatiquement au premier lancement, ce qui supprime la friction de saisie.
Partage de contenu web vers app
Quand un utilisateur partage un produit, un article ou une playlist, le destinataire qui installe arrive directement sur ce contenu, pas sur la home.
Réactivation et réinstall
Les campagnes de réactivation peuvent pré-régler l’écran, l’offre ou la personnalisation pour les utilisateurs qui ont supprimé puis réinstallé l’app.
Android
1Le smart link ajoute le referrer à l’URL Google Play
2Le token traverse l’installationreferrer=token
3Au premier lancement, l’app le lit avec InstallReferrerClient
Exact
La chaîne referrer d’origine, sans empreinte
iOS
1Le smart link enregistre le clic
2L’App Store ne transmet rien
3Au premier lancement, l’app interroge le service de matching
Exact
Un click ID est passé par le lien
Une estimation
Même réseau, même plateforme, même version d’OS
Rien
Aucun clic récent ne correspond
Deferred deep linking sur iOS
iOS n’expose pas d’API native d’install referrer. Le deferred deep linking sur iOS combine plusieurs stratégies de matching, chacune avec son compromis précision/vie privée.
- Universal Links + click ID : quand l’utilisateur tape le smart link, votre service enregistre le clic ; au premier lancement, l’app envoie le click ID reçu via le lien, ou demande au service de matching la meilleure correspondance récente.
- Matching probabiliste : le serveur compare le premier lancement aux clics récents venus du même réseau, de la même plateforme et de la même version d’OS. C’est une estimation : un bon fournisseur la distingue des correspondances exactes et vous laisse ne compter que les installations vérifiées quand il y a de l’argent en jeu. Elle s’affaiblit sur les réseaux partagés, derrière le NAT des opérateurs et quand le téléphone passe du Wi-Fi aux données mobiles entre le clic et la première ouverture.
- Pasteboard (limité) : l’utilisateur copie un token depuis une page web que l’app lit au premier lancement. iOS affiche maintenant une notification de collage visible, donc à réserver aux UX copy-link explicites.
- App Clips : alternative pour des expériences in-app courtes qui portent déjà l’intention, sans passer par le matching différé.
Deferred deep linking sur Android
Android dispose d’une API native solide : Play Install Referrer. Les paramètres du lien arrivent dans l’app de façon fiable, sans empreinte.
- Le smart link envoie l’utilisateur sur Google Play avec des paramètres referrer ajoutés à l’URL d’installation.
- Après installation, l’app appelle com.android.installreferrer.api.InstallReferrerClient et reçoit la chaîne referrer originale.
- Votre couche routing encode le payload différé dans le referrer (JSON URL-encodé ou token signé), et l’app le décode au premier lancement.
- Consommez le referrer une seule fois, persistez les valeurs parsées localement et fermez le client pour éviter les attributions dupliquées.
Un seul réseau partagé
Bureau, école, NAT opérateur
Le téléphone B ouvre l’app pour la première fois
Correspondance probabiliste
Même réseau, même OS : le lien A peut l’emporter. En attribution stricte, traitez-la comme organique.
Installation vérifiée
Le click ID est bien arrivé : vous pouvez récompenser sans risque
Chaque clic n’est réservé qu’une fois, côté serveur : un ancien payload ne peut donc pas atteindre un second téléphone.
Pièges qui cassent silencieusement le deferred deep linking
- • Compter sur le pasteboard iOS déclenche maintenant une notification de collage visible qui érode la confiance en production.
- • Traiter une correspondance probabiliste comme une certitude. Sur un réseau partagé (bureaux, écoles, NAT opérateur), le clic de quelqu’un d’autre peut l’emporter : n’accordez de récompense que pour les installations que votre fournisseur peut vérifier. Avec Appy, la consultation d’une installation indique si elle est vérifiée, et l’attribution stricte compte toutes les autres comme organiques.
- • Oublier de consommer l’Install Referrer sur Android cause un routing répété à chaque lancement et gonfle les analytics.
- • Mélanger des liens UTM-only et des deferred deep links donne des campagnes identiques côté dashboard mais différentes côté produit.
- • Oublier de réserver chaque clic à une seule installation : d’anciens payloads passent alors d’un utilisateur à l’autre quand plusieurs téléphones partagent un même réseau. Consommez chaque clic une seule fois, côté serveur.
- • Traiter le routing différé comme un sujet purement marketing : l’ingénierie doit garder une protection contre les payloads rejoués au cold launch.
Questions fréquentes
Deferred deep linking et deep link classique, c’est pareil ?
Non. Un deep link classique ne fonctionne qu’après l’install. Le deferred deep linking transporte l’intention à travers l’install pour amener le nouvel utilisateur sur la bonne page, pas sur une home générique.
La privacy iOS casse-t-elle le deferred deep linking ?
Elle change les méthodes utilisables. La lecture du pasteboard est visible, le matching type IDFA est restreint et le fingerprinting illimité est déconseillé. Les Universal Links, les click IDs transmis à travers les navigateurs in-app et les fenêtres de matching courtes qui ne touchent jamais à l’identifiant publicitaire fonctionnent toujours.
Peut-on implémenter sans SDK tiers ?
Oui sur Android : le Play Install Referrer transporte un token à travers l’installation, et chaque lien Appy y écrit déjà son slug, sur tous les plans. iOS n’a pas d’équivalent de l’install referrer : il faut donc une infrastructure de matching. Le plan Enterprise d’Appy inclut un petit SDK iOS et Android, plus une API HTTP documentée pour React Native, Flutter ou votre propre code. Dans les deux cas, Appy associe chaque installation au lien qui l’a générée.
Quelle différence avec un deep link qui renvoie simplement vers le store ou le site web (fallback) ?
Un deep link classique envoie les utilisateurs sans app vers votre site web ou un store. Le deferred deep linking mémorise en plus l’intention initiale et l’applique au premier lancement.
Combien de temps un payload différé reste valide ?
Tenez les estimations en laisse courte. Appy ne cherche que parmi les clics des deux dernières heures et conserve 24 heures les enregistrements de clic servant aux correspondances exactes par click ID. Une fenêtre plus longue augmente les fausses correspondances et les contextes périmés ; une fenêtre plus courte perd ceux qui installent lentement.
Ressources Appy associées
Continuez avec ces guides pour concevoir un routing fiable autour de l’install.
- Identifiez le lien derrière chaque installation pour voir ce qu’ajoute le SDK Appy : les installations et les revenus de chaque lien.
- Comment créer un lien unique pour App Store et Google Play pour le setup smart link de base sur lequel s’appuie tout routing différé.
- Deep Linking vs Universal Links pour comprendre les briques techniques sous tout flux différé.
- Guide complet Universal Links pour les détails iOS/Android et les conseils de validation.
Continuer à explorer
Les meilleurs outils de deep linking en 2026 : un comparatif honnête
Branch, AppsFlyer OneLink, Adjust, Airbridge, Kochava, Singular, Bitly, Dub, onelink.to et Appy, vérifiés sur leurs propres pages de tarifs et leur documentation : deep links, deferred deep linking, attribution, QR codes, assistants IA, prix et intégration.
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.
Paramètres UTM pour campagnes d’apps : guide pratique
À quoi sert chaque tag UTM, une convention de nommage qui tient dans la durée, des valeurs pour chaque canal d’app et ce qui arrive vraiment à vos tags sur l’App Store et Google Play.
Vous cherchez autre chose ? Parcourez tous les sujets sur le blog.
Déployez du deferred deep linking sans construire l’infra de matching
Les liens Appy envoient chaque visiteur vers le bon store, sur tous les plans. Sur Enterprise, le SDK d’Appy transporte le lien à travers l’installation et attribue chaque installation au lien qui l’a générée.