Ces quelques dernières années, les liaisons ciblées, les liaisons universelles, les schémas d’URI/URL et les liaisons d’application ont tous largement contribué à changer le monde de la liaison au contenu des applications mobiles. De nombreux développeurs d’application se sont retrouvés déconcertés quant à savoir quelle technologie mettre en œuvre et quelle meilleure pratique du secteur appliquer à chacune.
De plus, le paysage de la liaison ciblée mobile reste un espace à l’évolution rapide. Même si les solutions de l’an passé fonctionnent encore, aujourd’hui, elles ne représentent plus la meilleure approche, voire même, elles peuvent ne plus être possibles. Après des années d’articles obsolètes et d’informations erronées, il est temps de supprimer les idées fausses et d’apporter une nouvelle vision du monde sur la liaison ciblée mobile.
Qu’est-ce que la liaison ciblée?
D’abord, un peu de terminologie de base: la liaison ciblée est simplement un concept. Nous utilisons les liaisons ciblées tous les jours en fait, vous avez probablement déjà cliqué sur l’une d’elles pour atteindre cet article de blog. Ce terme désigne simplement toute liaison qui se dirige directement vers un fragment du contenu. Lorsque vous cliquez sur une URL comme https://example.com/my-awesome-content-page, vous ne vous attendez pas à être dirigé vershttps://example.com/ et à être obligé de naviguer dans tout le site Web pour retrouver my-awesome-content-page. En d’autres termes, la plupart des liaisons du Web sont en fait des liaisons ciblées, mais nous ne les appelons pas ainsi. Pour nous, ce ne sont que des liaisons.
La liaison ciblée dans les applications mobiles est bien plus compliquée, mais les liaisons ciblées mobiles restent le meilleur moyen d’offrir aux utilisateurs de l’application une expérience de fluidité du contenu. Les liaisons universelles, les schémas URI et les liaisons d’application correspondent aux diverses normes technologiques qui font fonctionner les liaisons ciblées mobiles, permettant ainsi d’amener un utilisateur directement au contenu dans l’application. Si vous souhaitez partager une page avec un ami à l’intérieur d’une application mobile, une liaison ciblée amènera votre ami à la bonne page. Sans liaison ciblée, votre ami aurait des difficultés à trouver la bonne page seul et il se retrouverait souvent dans l’App Store (même si l’application est installée) ou sur le Web mobile.
Le processus de mise en œuvre des liaisons ciblées mobiles a évolué au fil des années, Android et iOS ont tous les deux offert leurs propres solutions. Ceci a provoqué de la confusion au sein de la communauté de développement d’applications, obligeant même les ingénieurs expérimentés à actualiser leurs liaisons dans des situations de crise spontanée et déroutant les nouveaux ingénieurs quant à la meilleure voie vers la mise en œuvre des liaisons ciblées dans leur application.
Voici une répartition détaillée des diverses normes de liaisons ciblées mobiles actuellement en vigueur:
Remarque: ensemble, iOS et Android contrôlent 99,3% du marché mobile. C’est pour cette raison que Branch ne dispose que d’une prise en charge très limitée par les autres plateformes qui sont omises ici par souci de simplicité.
Bien sûr, aucune de ces normes n’est prise en charge sur chaque plateforme ou version du système d’exploitation:
Facebook mérite d’être particulièrement souligné pour avoir inventé une norme de liaison ciblée open-source qui était réellement prometteuse et pour l’avoir entièrement abandonné ensuite:
Analysons chacune de ces normes un peu plus en détail.
Que sont les schémas d’URI? Sont-ils différents des URL?
Si vous voulez déclencher une émeute dans une salle pleine d’ingénieurs, vous pouvez lancer un débat sur l’opposition entre les tabulations et les espaces pour la mise en retrait du code. Ou vous pouvez confondre la différence entre URI et URL. Des essais ont été écrits à ce propos mais en gros, rappelez-vous simplement que toutes les URL sont aussi des URI. C’est l’élément de départ qui importe vraiment, à savoir le schéma. Vous êtes déjà habitués aux schémas https://et https://. Il se peut même que vous ayez rencontré ftp:// ou feed://. Tous ces éléments indiquent le type de contenu demandé et votre application mobile peut enregistrer son propre schéma d’URI personnalisé. Par exemple, myapp://.
Si vous avez effectué des recherches sur les liaisons ciblées, vous êtes probablement tombé sur des contenus pertinents à propos des schémas d’URI. Tout au long de la majeure partie de l’histoire du développement des applications, les schémas d’URI ont constitué la principale méthode de liaison ciblée dans les applications à la fois dans iOS et Android.
Limites des schémas URI
Malheureusement, les schémas d’URI personnalisés présentent des inconvénients significatifs, en particulier l’incapacité à gérer facilement ces deux situations:
- Lorsque l’application n’est pas installée.
- Lorsque plus d’une application essaie de demander myapp://.
Les schémas URI n’intègrent aucune option de secours, ce qui signifie que si un utilisateur n’a pas d’application installée, lorsqu’il clique sur un lien partagé par un ami, il ne verra qu’une page d’erreur. Il n’y a pas non plus de système central d’inscription, ce qui signifie que des collisions d’URI peuvent se produire (la position officielle d’Apple est qu’il n’y a actuellement aucun processus). De nombreux développeurs ont élaboré des contournements dans le cas du premier problème en utilisant des redirections complexes de JavaScript, mais celles-ci avaient tendance à s’interrompre à chaque nouvelle version iOS. Il n’y aura probablement jamais de solution au second problème..
En raison de ces limites, iOS et Android ont tous deux développé des normes de liaison ciblée de seconde génération connues sous les noms de liaisons universelles et liens d’application, respectivement. Apple a depuis lors bloqué la possibilité de rediriger JavaScript vers des schémas d’URI, rendant ainsi les liaisons universelles essentielles pour la liaison ciblée dans iOS. Les liens d’application ont à ce stade connu une adoption beaucoup plus faible.
Ce qui diffère entre les liaisons universelles et les liens d’application
À la différence des schémas d’URI, qui représentent un type de contenu unique pour votre application, les liaisons universelles et les liens d’application ne sont que des liaisons Web ordinaires (https://example.com) qui indiquent à la fois une page Web et un élément de contenu à l’intérieur d’une application. Lorsqu’une liaison universelle ou un lien d’application est ouvert, l’appareil vérifie si une application installée est enregistrée pour ce domaine. Si tel est le cas, l’application est immédiatement lancée sans le chargement de la page Web. Dans le cas contraire, l’URL du Web (qui peut être une simple redirection vers App Store ou Play Store) est chargée dans le navigateur Web par défaut.
Si vous êtes quelque peu concerné par les mesures et les analyses, vous pourriez remarquer un problème ici: le lancement immédiat de l’application signifie que les méthodes classiques de suivi destinées au marketing à la fois Web et par courriel toutes basées sur les chaînes de redirection ne sont plus actives. Cela peut être un problème grave et les liaisons universelles ainsi que les liens d’application manquent actuellement de solutions. Votre seule option est de calculer rétroactivement les clics après l’ouverture de l’application.
Les liaisons universelles représentent la norme actuelle dans iOS, mais elles présentent des inconvénients
Les liaisons universelles ne sont en fait pas universelles. Sur les principales plates-formes comme Facebook et Twitter, les liaisons universelles ne sont absolument pas prises en charge et le bouton convivial dans le coin supérieur droit ne suggère absolument pas qu’il s’agit essentiellement d’une option à l’effet dévastateur. Il permet au visiteur de désactiver très facilement les liaisons universelles sans qu’il s’en rende compte. Une fois cela fait, il est plus qu’improbable qu’un utilisateur classique sache comment inverser le processus, ce qui l’incite à supposer qu’il s’agit d’un dysfonctionnement de votre application.
Pour aggraver les choses, le lancement des liaisons universelles a été sérieusement bâclé, et les tester est complexe dans la mesure où Apple ne fournit même pas un outil de validation.
Les schémas d’URI/URL sont-ils obsolètes?
Selon Apple, oui. À partir d’iOS 9.2, Apple ne prend officiellement plus en charge les schémas d’URI pour la liaison ciblée et les développeurs ont été obligés de mettre en œuvre les liaisons universelles afin d’obtenir des fonctionnalités équivalentes sous iOS.
En réalité, pas encore. Les liaisons universelles sont fantastiques lorsqu’elles fonctionnent, mais il y a encore beaucoup d’endroits où vous devez utiliser les schémas d’URI comme soutien, vous perdez en route une quantité non négligeable de trafic si vous ne comptez que sur eux. L’écosystème d’Android est beaucoup trop fragmenté pour ne serait-ce qu’envisager d’abandonner les schémas d’URI à tout moment dans l’avenir proche.
Liaisons ciblées différées
Un autre concept encore plus important n’a pas encore été abordé: la liaison ciblée différée. Les liaisons ciblées classiques qu’elles soient mises en œuvre par les schémas d’URI, les liaisons universelles ou les liens d’application ne fonctionnent que si l’application est déjà installée sur l’appareil. Dans le cas contraire, elles peuvent au mieux envoyer vos utilisateurs vers App Store ou Play Store. Mais que se passe-t-il si vous voulez envoyer vos utilisateurs au bon endroit dans l’application, même s’ils doivent d’abord l’installer? Les liaisons ciblées différées rendent cela possible, en conservant le contexte de l’élément spécifique du contenu tout au long du processus d’installation et en emmenant l’utilisateur au bon endroit après l’installation.
Autres normes de la liaison ciblée
Vous pouvez aussi rencontrer deux autres normes de liaison ciblée moins courantes: Les intents de Chrome et les liens d’application Facebook.
Intents de Chrome
L’équipe de Chrome a élaboré, sa propre extension maison pour personnaliser les schémas d’URI, avec pour objectif de fournir un comportement de secours lorsque l’application n’est pas installée. Bien que ce soit une solution élégante au problème sous-jacent, les intents de Chrome ne sont prises en charge que par la version Android du navigateur Chrome et par une poignée d’applications de tierces parties. Cela implique une complexité accrue de la mise en œuvre de chaque liaison ciblée, car il faut maintenant prendre en charge à la fois les technologies standard et une alternative spécifique à Chrome.
Liens d’application Facebook
Facebook a créé les liens d’application en 2014 pour qu’ils constituent des normes ouvertes apportant une solution aux limites des liaisons ciblées des schémas d’URI. Les liens d’application intègrent deux composants principaux:
- Un ensemble de balises Meta à ajouter à la destination de la page Web d’un lien https:// standard. Ces balises précisent l’emplacement du schéma d’URI personnalisé du contenu correspondant dans l’application native et le comportement probable si l’application n’est pas installée.
- Un moteur de routage à utiliser dans les applications qui prennent en charge l’ouverture des liens. Ce moteur vérifie l’URL de destination des balises des liens d’application avant de l’ouvrir et lance ensuite l’application correspondante ou exécute le comportement de secours spécifié.
https://applinks.org/documentation/
La norme des liens d’application présente une grave limite: elle requiert l’action des applications à la fois d’origine et de destination. Alors que la norme des balises Meta s’est vu largement adoptée, les seules mises en œuvre majeures du moteur de routage sont survenues dans les applications noyau de Facebook et de Messenger. Facebook préfère maintenant conserver ses utilisateurs au sein de sa plateforme et a supprimé le moteur de routage des liens d’application partout, sauf en ce qui concerne la principale application sous Android. Comme Facebook bloque aussi les liaisons universelles iOS, cela ne laisse aucun moyen fiable d’ouvrir les applications de tierces parties à partir de Facebook ou Messenger sous iOS. Branch a mis en œuvre une solution pour aider à utiliser ces limites.
Les liaisons universelles, les schémas d’URI et les liaisons ciblées en 2017.
Le paysage de la liaison ciblée d’application mobile est encore incroyablement fragmenté. Nous sommes encore loin d’une norme applicable à l’ensemble du secteur. Ce n’est cependant pas une excuse pour infliger une expérience d’utilisation médiocre à vos clients.
Vous avez besoin de liaisons ciblées et vous avez besoin de tous les différentes normes pour les obtenir. Les liaisons ciblées différées Branch sont générées par les schémas d’URI, les liaisons universelles, les liens d’application, les intents de Chrome et les liens d’application Facebook. Nous les avons tous inclus afin que vous n’ayez pas à le faire.
Êtes-vous intéressé par la mise en œuvre de liaisons ciblées qui gèrent toutes ces différentes normes et qui fournissent des analyses unifiées et les données d’attribution sans travail supplémentaire de votre part? Cliquez sur le bouton ci-dessous pour commencer.