Ce que vous allez configurer
- Charger vos fichiers Apple App Site Association et Android Asset Links pour qu'Elido les serve automatiquement sur votre domaine personnalisé.
- Définir les configurations iOS et Android par lien — ID d'application, chemin dans l'application et URL de secours — afin que les clics ouvrent le bon écran ou basculent vers le store.
- Mesurer le taux d'ouverture de l'application par plateforme dans l'onglet Analytics → Liens profonds du lien.
Les liens profonds ouvrent des applications natives directement depuis une URL courte. Lorsque le visiteur a votre application installée, le lien ouvre le bon écran dans l'application. Lorsqu'il ne l'a pas, il bascule vers l'App Store (iOS) ou le Play Store (Android) — ou vers toute autre URL que vous configurez.
Ce dont vous avez besoin#
Pour utiliser les liens profonds, vous avez besoin de :
- Une application iOS avec Universal Links configurés, OU
- Une application Android avec App Links configurés, OU
- Des schémas URI personnalisés (
myapp://) si vous n'avez pas encore de Universal/App Links.
Pour Universal Links et App Links, vous devrez également publier des fichiers d'association (apple-app-site-association pour iOS, assetlinks.json pour Android) sur votre domaine personnalisé. Elido les sert automatiquement une fois que vous chargez le fichier dans Paramètres → Domaines → Liens profonds.
Configurer les liens profonds sur un lien#
- Ouvrez la page de détail du lien → Ciblage → Liens profonds.
- Activez les liens profonds.
- Ajoutez une configuration iOS :
- ID d'application — par ex.
K72L8M4N9P.com.acme.myapp(l'ID d'équipe + l'identifiant de bundle de votre compte Apple Developer). - Chemin dans l'application — vers quel écran l'application doit naviguer. Le chemin est ajouté à votre hôte de lien universel ; le SDK dans l'application le lit depuis l'URL de lancement.
- URL de secours — où envoyer les visiteurs qui n'ont pas l'application. Généralement votre fiche App Store.
- ID d'application — par ex.
- Ajoutez une configuration Android :
- Nom du package — par ex.
com.acme.myapp. - Chemin dans l'application — même idée qu'iOS.
- URL de secours — généralement une URL Play Store avec votre nom de package.
- Nom du package — par ex.
- Enregistrer. Le lien effectuera maintenant un routage basé sur l'appareil à chaque clic.
Ce qui se passe au moment du clic#
Le gestionnaire de redirection retourne une page interstitielle HTML qui exécute environ 50 ms de JavaScript. L'interstitiel :
- Détecte iOS vs Android vs desktop.
- Sur iOS : essaie d'ouvrir via Universal Link. Si l'OS ouvre l'application, c'est terminé.
- Sur Android : pareil avec App Links.
- Après 1,2 secondes sans application, la page redirige vers l'URL de secours.
Les visiteurs desktop atteignent toujours directement l'URL de secours — il n'y a pas d'application à ouvrir.
Si un visiteur est sur une plateforme que nous ne reconnaissons pas (Web View dans WeChat, etc.), le lien bascule vers la destination desktop. Vous pouvez remplacer cela avec des règles de lien intelligent.
Secours avec schéma URI#
Si vous n'avez pas configuré Universal Links / App Links, vous pouvez toujours utiliser un schéma URI personnalisé :
- Schéma iOS :
myapp:// - Schéma Android :
myapp://
L'interstitiel tentera d'ouvrir le schéma et basculera vers l'App Store / Play Store après 1,2 secondes. L'inconvénient est que l'OS affiche une confirmation « Ouvrir dans Mon Application ? » au premier lancement, ce que Universal Links évite.
Analyses#
Chaque clic enregistre si l'application s'est ouverte ou si le secours a été utilisé. L'onglet Analytics → Liens profonds du lien affiche le taux d'ouverture par plateforme — utile pour mesurer l'efficacité de vos fichiers d'association.
Limites#
- Une configuration iOS et une configuration Android par lien.
- Les liens profonds sont disponibles sur Pro et Business ; le tarif gratuit ne supporte que les redirections simples.
Pièges courants#
Universal Links fonctionnent sur un vrai appareil mais pas dans le simulateur. C'est attendu — le simulateur d'Apple ne peut pas récupérer le fichier AASA. Testez sur un vrai téléphone.
L'URL de secours s'ouvre avant même que l'application ait essayé. Certains navigateurs Android (Samsung Internet, notamment) interceptent le schéma avant que l'OS ne le voit. Assurez-vous que votre configuration App Links est complète : domaine vérifié, nom du package correct, empreinte SHA-256 correspondante.
iOS affiche parfois une bannière tap-target au lieu d'ouvrir l'application. C'est iOS qui traite la page comme un site générique avec « Ouvrir dans Safari → Smart Banner ». Re-télécharger le fichier AASA avec l'ID d'application correct le résout généralement.
Le lien ouvre l'application, puis le mauvais écran. Votre routage dans l'application ne correspond pas au chemin qu'Elido transmet. Journalisez l'URL de lancement dans votre application pour confirmer ce que vous recevez réellement, puis mettez à jour la configuration du chemin pour qu'elle corresponde.