Deferred Deep Link : ce que c'est, comment ça fonctionne et son utilisation dans le développement

Qu'est-ce que Deferred Deep Link ?

Deferred Deep Link est un type de deep link qui fonctionne en deux étapes : d'abord l'utilisateur clique sur le lien avant l'installation de l'application, puis le système restaure le contexte après la fin de l'installation. Un deep link classique ouvre l'application uniquement si elle est déjà installée, tandis que le deferred sauvegarde tous les paramètres de transition et les transmet au premier lancement.

Cette technologie est devenue particulièrement demandée avec la croissance du marketing mobile, où les campagnes publicitaires ciblent souvent des utilisateurs qui n'ont pas encore installé l'application. Sans deferred deep link, chacune de ces transitions se terminerait simplement par le téléchargement de l'application sans aucun contexte — l'utilisateur atterrirait sur l'écran principal au lieu de l'écran cible.

Différence avec le deep link classique

Un deep link classique ouvre le contenu cible dans une application déjà installée. Si l'application n'est pas installée, le navigateur affiche une erreur. Deferred Deep Link fonctionne via un serveur intermédiaire qui redirige l'utilisateur vers le magasin et, après l'installation, notifie l'application des paramètres sauvegardés. Ainsi, un lien deferred ne nécessite pas de pré-installation de l'application et offre un parcours utilisateur de bout en bout, de la publicité au contenu.

Comment fonctionne Deferred Deep Link

Le traitement du deferred deep link se compose de trois étapes. À la première étape, l'utilisateur clique sur le lien — le serveur détermine si l'application est installée. Si ce n'est pas le cas, il génère un identifiant de session unique, sauvegarde les paramètres de transition et redirige l'utilisateur vers l'App Store ou Google Play avec cet identifiant.

À la deuxième étape, l'utilisateur installe l'application depuis le magasin. Après l'installation et le premier lancement, le SDK de la plateforme contacte le serveur, transmet l'identifiant de l'appareil et reçoit les paramètres de transition sauvegardés. À la troisième étape, l'application traite les données reçues et redirige automatiquement l'utilisateur vers l'écran cible.

Cycle de vie du lien deferred

Pour sauvegarder les paramètres entre le clic sur le lien et l'installation, divers mécanismes sont utilisés. Sur iOS, il s'agit du trousseau iCloud (iCloud Keychain) ou du presse-papiers ; sur Android, de l'Install Referrer API. Firebase Dynamic Links utilise une combinaison du localStorage du navigateur et du lien de référence du magasin pour transmettre l'identifiant de session. Branch.io emploie son propre protocole avec sauvegarde des données dans plusieurs stockages.

Deferred Deep Link sur iOS

Sur iOS, le deferred deep link est implémenté via une combinaison d'Universal Links et de Shared Web Credentials. Lorsqu'un utilisateur clique sur un Universal Link vers le site web de l'application, Safari sauvegarde les paramètres de transition dans le trousseau iCloud associé au domaine de l'application. Après l'installation de l'application depuis l'App Store, iOS vérifie la présence des données sauvegardées et les transmet à l'application au premier lancement.

Apple ne fournit pas d'API intégrée pour le deferred deep link — l'implémentation repose entièrement sur des SDK tiers. Firebase Dynamic Links utilise un mécanisme passive deferred, où les données sont sauvegardées dans les cookies du navigateur et restaurées via une redirection vers une URL spéciale au premier lancement de l'application.

Limitations sur iOS

À partir d'iOS 14, Apple a renforcé les règles de confidentialité, ce qui a affecté les mécanismes de deferred deep link. Le presse-papiers ne peut plus être utilisé pour lire des données sans autorisation explicite de l'utilisateur. Le trousseau iCloud a également des limites de volume de données — pas plus de 4 Ko par écriture. Cela fait des solutions serveur avec identifiant de session unique la méthode préférée pour transmettre le contexte.

Deferred Deep Link sur Android

Android offre des options plus flexibles pour le deferred deep link via l'Install Referrer API. Lorsqu'un utilisateur clique sur un lien vers Google Play, le magasin capture le referrer — une chaîne avec des paramètres de transition. Après l'installation, l'application reçoit cette chaîne via l'Install Referrer API et en extrait le contexte cible. C'est le mécanisme de deferred deep link le plus fiable sur Android.

Pour les applications distribuées en dehors de Google Play, Android prend en charge un BroadcastReceiver de référence. Le développeur peut envoyer une Intent personnalisée avec des paramètres après l'installation, et l'application la recevra via un BroadcastReceiver enregistré dans le manifeste. Cependant, ce mécanisme est moins fiable car il dépend de l'implémentation de l'installeur.

Install Referrer API

L'Install Referrer API fournit des informations sur la source d'installation, y compris l'URL du referrer, l'heure du clic et l'heure de l'installation. La longueur maximale de la chaîne referrer est de 8 Ko, ce qui est suffisant pour transmettre tous les paramètres nécessaires du deep link. L'API est disponible sur les appareils avec Google Play Store version 8.3.73 et supérieure, et est prise en charge sur Android 5.0 (API 21).

Implémentation avec Firebase Dynamic Links

Firebase Dynamic Links est l'outil gratuit le plus populaire pour implémenter le deferred deep link sur les deux plateformes. Firebase gère automatiquement toutes les étapes de la transition deferred : redirection vers le magasin en l'absence de l'application, stockage des paramètres sur le serveur Firebase et transmission au SDK au premier lancement de l'application.

Pour implémenter, il suffit d'intégrer le SDK Firebase dans le projet, de créer un Dynamic Link via la Firebase Console en spécifiant le deep link et les paramètres de campagne. Le SDK Firebase est automatiquement appelé au lancement de l'application et vérifie la présence d'un Dynamic Link entrant via la méthode getDynamicLink().

Exemple de configuration de traitement

Exemple de traitement d'un Firebase Dynamic Link différé dans une Activity en Kotlin. Le code fonctionne aussi bien pour le démarrage à froid que pour le démarrage à chaud au lancement de l'application.

class MainActivity : AppCompatActivity() {

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        checkDeferredLink()
    }

    private fun checkDeferredLink() {
        FirebaseDynamicLinks.getInstance()
            .getDynamicLink(intent)
            .addOnSuccessListener link ->
                val deferredLink = link?.link.toString()
                if (deferredLink.isNotEmpty()) {
                    navigateToContent(deferredLink)
                }
            }
    }
}

La méthode getDynamicLink() retourne une PendingTask avec un objet DynamicLink. Si l'application a été installée après le clic sur le lien, l'écouteur recevra les données avec les paramètres. Si l'application était déjà installée avant la transition, la méthode retournera les mêmes données qu'avec un deep link classique. Le drapeau minimumAppVersion dans les paramètres du lien permet de définir la version minimale de l'application pour le traitement.

Avantages et limitations de Deferred Deep Link

Deferred Deep Link offre des avantages significatifs pour les campagnes marketing : l'utilisateur reçoit le contenu cible après l'installation sans actions supplémentaires, ce qui augmente la conversion et la rétention. Pour les programmes de parrainage, les liens deferred permettent de lier sans ambiguïté l'invitation à l'installation et aux actions du nouvel utilisateur.

Cependant, la technologie a aussi des limites. Le deferred deep link ne fonctionne pas dans les navigateurs qui bloquent les cookies tiers, et sur iOS à partir de la version 14, une configuration supplémentaire est nécessaire pour iCloud Keychain. De plus, entre le clic sur le lien et l'installation, plusieurs jours peuvent s'écouler, et tous les SDK ne garantissent pas la conservation des données pendant cette période.

Quand utiliser le deferred deep link

Le deferred deep link est obligatoire pour les campagnes publicitaires ciblant de nouveaux utilisateurs, les newsletters par email avec invitations et les programmes de parrainage. Pour les utilisateurs déjà installés, un deep link classique suffit. Si l'application n'utilise pas de campagnes marketing ni de mécanismes de parrainage, le deferred deep link n'est pas nécessaire — les Universal Links et les App Links sont suffisants.

Lors du choix d'une implémentation, tenez compte du coût : Firebase Dynamic Links est gratuit mais dispose d'analyses limitées. Branch.io et AppsFlyer fournissent une attribution avancée mais nécessitent un abonnement. Pour les petits projets, Firebase est la solution optimale ; pour les entreprises avec des dizaines de canaux publicitaires, les MMP commerciaux sont le choix.