Liens profonds. Open the app. Fall back gracefully.
Manifestes Universal Links et App Links servis depuis votre domaine personnalisé. iOS ouvre votre application au toucher ; Android fait de même. Retour au navigateur sur ordinateur.
- Universal Links (iOS) and App Links (Android) served from your domain
- Deferred deep links — context survives app install
- Smart platform detection with graceful fallbacks
- No SDK required — works with standard OS mechanisms
Universal Links & App Links
Manifest files, auto-served from your domain
iOS Universal Links require an apple-app-site-association file. Android App Links require assetlinks.json. Elido generates and serves both from your custom domain automatically — no separate hosting, no manual file management.
- iOS Universal LinksBundle ID + Team ID → AASA served at /.well-known/ automatically
- Android App LinksPackage name + SHA-256 fingerprint → assetlinks.json, HTTPS enforced
- Smart-link fallbackApp not installed → App Store / Play Store via rule-based routing
- UTM passthroughUTM parameters preserved to store URL — attribution doesn't break
- No SDK in your appOS-level interception only; intent-filter and continueUserActivity
{ "applinks": { "apps": [], "details": [ { "appID": "TEAMID.com.yours.app", "paths": [ "/product/*", "/referral/*", "/invite/*" ] } ] } }
[{ "relation": [ "delegate_permission/ common.handle_all_urls" ], "target": { "namespace": "android_app", "package_name": "com.yourcompany.app", "sha256_cert_fingerprints": [ "AB:12:CD:34:EF:56:..." ] } }]
Served from your custom domain automatically. Configure bundle ID + Team ID (iOS) or package name + SHA-256 fingerprint (Android) in domain settings — Elido generates and hosts both files.
Deferred deep links
Context that survives the install
When the app isn’t installed, the user goes to the store, installs, and opens the app. Deferred deep-linking passes the original deep-link context through that journey so the app can land the user on exactly the right screen after first launch.
- 01
Clicks link
User taps an Elido short link — from email, social, QR.
go.yourcompany.com/p/12345 - 02
No app → Store
App not installed. OS detects from AASA / assetlinks check. Falls back to App Store or Play Store.
iOS → App Store · Android → Play Store - 03
Installs app
User installs from the store. The install referrer carries the click context as a query parameter.
click_id + UTM preserved in referrer URL - 04
Opens app
App opens for the first time. MMP reads install referrer; maps click_id to the install event.
Appsflyer / Adjust / Branch picks it up - 05
Lands on exact page
App routes to the originally linked screen — product/12345 — as if the user had the app already.
product/12345 — context preserved through install
The click_id and UTM parameters from the original short link are passed as query parameters to the store URL. Mobile Measurement Platforms (MMPs) that capture the install referrer — Appsflyer, Adjust, Branch — can match the install to the originating click. Full deferred deep-linking (passing in-app context through install) requires the MMP SDK in your app; Elido covers the link layer.
Smart platform detection
One link. Three redirect paths.
The edge reads User-Agent and platform signals at the redirect layer — before any JS runs. iPhone gets Universal Links, Android gets App Links, desktop gets your web fallback. No JavaScript redirect delay; no client-side platform detection.
- UA parsing at the edge, sub-millisecond
- iOS → Universal Link interception by the OS
- Android → App Link interception via intent-filter
- Desktop → web URL, no store detour
- In-app browsers detected and redirected to system browser
- Composes with smart-link rules — geo + device + deep-link
What you can do
- Association de site d'application Apple
- Liens d'actifs Android
- Règles de liens intelligents pour le retour au magasin
- Testé avec adb et xcrun
Comment fonctionnent réellement les deep links — et où ils échouent
Les Universal Links et App Links sont des mécanismes au niveau de l'OS. La mise en place est simple ; les cas limites ne le sont pas. Voici le tableau complet.
apple-app-site-association servi automatiquement depuis votre domaine personnalisé
Les Universal Links nécessitent un fichier apple-app-site-association (AASA) à /.well-known/apple-app-site-association sur votre domaine personnalisé. iOS télécharge ce fichier lors de l'installation de votre app ; il associe votre domaine au bundle ID et au team ID de votre app. Si l'association est correcte, appuyer sur un lien HTTPS de votre domaine dans n'importe quelle app iOS (Safari, Mail, Twitter, Instagram) ouvre directement votre app au lieu du navigateur. Elido génère et sert le fichier AASA depuis le chemin well-known de votre domaine personnalisé automatiquement, en fonction du bundle ID et du team ID que vous configurez dans les paramètres du domaine. Vous n'hébergez pas le fichier séparément. iOS met en cache le fichier AASA et le re-télécharge périodiquement ; si vous modifiez la configuration du bundle ID dans les paramètres de domaine d'Elido, le nouveau AASA est en ligne en quelques secondes, mais les appareils iOS le récupèreront lors du prochain rafraîchissement du cache (généralement 24-48 heures, ou lors de la réinstallation de l'app). Testé avec le validateur AASA d'Apple à chaque version d'Elido.
assetlinks.json servi automatiquement — empreinte SHA-256 de votre clé de signature
Les Android App Links nécessitent un fichier Digital Asset Links à /.well-known/assetlinks.json sur votre domaine. Le fichier associe votre domaine au nom de package de votre app et à l'empreinte SHA-256 de votre certificat de signature. Android vérifie ce fichier lors de l'installation de l'app et périodiquement ensuite. Elido le sert depuis votre domaine personnalisé automatiquement, en fonction du nom de package et de l'empreinte SHA-256 que vous configurez. La vérification Android nécessite HTTPS (assuré par le TLS d'Elido sur le domaine personnalisé) et le fichier doit répondre en quelques secondes (également géré). Un mode de défaillance courant : les clés de signature debug et release ont des empreintes SHA-256 différentes. Configurez les deux empreintes dans les paramètres de domaine d'Elido si vous testez avec un build debug ; les builds de production n'ont besoin que de l'empreinte release. Testé avec adb shell pm get-app-links à chaque version.
App installée → deep link. App non installée → store. Desktop → web. UTM préservés tout au long.
La chaîne de fallback est définie par lien ou par domaine dans les paramètres d'Elido. Pour un lien court avec une configuration deep-link : si l'OS intercepte le tap (app installée, domaine vérifié), l'app s'ouvre. Sinon (app non installée), le lien s'ouvre dans le navigateur ; la destination doit être votre lien App Store / Play Store ou un fallback web. Les règles smart-link gèrent cela proprement : configurez une règle iOS → URL App Store, une règle Android → URL Play Store, et un fallback vers la destination web. Les paramètres UTM du lien court original sont préservés dans les URL de fallback pour que l'attribution ne soit pas rompue quand l'utilisateur atteint le store. Le deferred deep-linking (transmettre un chemin deep-link spécifique à travers une installation, pour que l'app s'ouvre sur le bon écran après installation) nécessite un SDK dans l'app — Elido ne fournit pas cela. Pour le deferred deep-linking, vous avez toujours besoin d'Appsflyer, Adjust ou Firebase App Distribution.
Retargeting post-installation : click ID transmis à la destination pour l'attribution
Lors d'une redirection deep-link, Elido transmet le click_id comme paramètre de requête à l'URL de fallback. Si l'utilisateur arrive sur l'App Store et installe l'app, le click_id est dans l'URL de referral mais n'est pas automatiquement propagé dans l'app après l'installation — cela nécessite SKAdNetwork sur iOS ou un SDK de deferred deep-link sur Android. Ce qu'Elido fait : transmettre le click_id et les paramètres UTM à l'URL du store pour qu'une plateforme d'attribution mobile (MMP) capturant le referrer d'installation puisse les récupérer. Cela fonctionne avec Appsflyer et Adjust si vous transmettez le click_id dans le paramètre campaign de l'URL du store. Si vous n'utilisez pas de MMP, le click_id dans l'URL du store est effectivement perdu après l'installation.
Migration depuis Firebase Dynamic Links (arrêté en 2025)
Firebase Dynamic Links a été arrêté par Google en 2025. Elido peut gérer le schéma de base : un seul lien court HTTPS qui ouvre le bon écran dans une app installée, redirige vers le store si non installée, et vers le web sur desktop. Configurez l'AASA et l'assetlinks.json dans les paramètres de domaine d'Elido (remplace l'hébergement Firebase de ces fichiers), mettez à jour vos liens de partage pour pointer vers des liens courts Elido au lieu des URL page.link, et configurez la chaîne de fallback via les règles smart-link. Ce qu'Elido ne réplique pas : le deferred deep-linking de Firebase (contexte deep-link post-installation via le SDK Firebase), et les deep links Firebase App Distribution. Si votre app dépend fortement du deferred deep-linking, vous aurez besoin d'Appsflyer, Adjust ou Branch en complément d'Elido pour la couche d'attribution. Pour les apps qui ont juste besoin de « ouvrir le bon écran si installée, sinon aller au store », Elido remplace complètement Firebase Dynamic Links.
Équipes mobiles utilisant les deep links Elido
Les noms sont des exemples fictifs pour l'instant — les vrais noms de clients apparaîtront ici lorsque les études de cas seront publiées.
“Nous avons migré depuis Firebase Dynamic Links la semaine de l'annonce de l'arrêt. La configuration AASA et assetlinks.json dans Elido a pris une demi-journée. La chaîne de fallback smart-link a remplacé la logique du SDK Firebase que nous avions dans l'app pour le routage vers le store.”
“Les analytics de clics par lien sur les deep links nous ont montré que 35 % de nos liens de partage étaient cliqués sur desktop — nous n'avions aucun fallback web configuré. Ajouter le fallback a pris 10 minutes ; le taux de conversion des liens de partage a augmenté car les utilisateurs desktop pouvaient désormais compléter l'action.”
“Nous utilisons les liens courts Elido avec configuration deep-link pour les programmes de parrainage. La transmission UTM vers l'URL App Store signifie que notre MMP récupère correctement le referrer d'installation — l'attribution fonctionne sans travail SDK personnalisé de notre côté.”
Deep links Elido vs Branch.io vs Adjust vs Firebase Dynamic Links (arrêté)
Branch et Adjust sont des plateformes d'attribution mobile complètes — plus puissantes pour le deferred deep-linking et l'attribution MMP. Elido est le bon outil quand les deep links font partie d'une configuration de raccourcisseur plus large, pas le produit principal.
| Feature | Elido | Branch.io | Adjust |
|---|---|---|---|
| Universal Links (iOS) | AASA servi automatiquement depuis votre domaine | Entièrement géré à grande échelle | Non — MMP uniquement, pas hébergeur de deep-link |
| App Links (Android) | assetlinks.json servi automatiquement depuis votre domaine | Entièrement géré | Non |
| SDK requis dans l'app | Non — interception au niveau de l'OS | Oui — SDK Branch | Oui — SDK Adjust |
| Deferred deep-linking | Non — nécessite un SDK dans l'app | Oui — fonctionnalité principale | Oui — avec le SDK Adjust |
| Attribution mobile (MMP) | Transmission du click ID ; intégration MMP manuelle | MMP natif — intégrations Appsflyer, Kochava | Plateforme MMP complète |
| Transmission UTM vers le store | Oui — via paramètre de requête sur l'URL de fallback | Oui, avec contexte d'attribution | Oui |
| Analytics sur les clics de liens | ClickHouse — géo, appareil, par lien | Analytics d'attribution mobile approfondies | Données d'attribution installation + événement |
| Remplacement Firebase Dynamic Links | Oui pour le schéma de base ; pas de deferred deep-link | Remplacement complet incluant le deferred | Partiel — côté MMP uniquement |
Questions sur les deep links
Ai-je besoin d'un SDK Branch ou de tout autre SDK dans mon app pour utiliser les deep links Elido ?
Non. Les deep links Elido utilisent les iOS Universal Links et les Android App Links — des mécanismes au niveau de l'OS. Votre app doit simplement gérer l'URL entrante de manière standard iOS (scene:openURLContexts ou application:continueUserActivity) ou Android (intent-filter dans le manifest). Aucun SDK tiers n'est installé ; l'OS gère l'interception en se basant sur les fichiers AASA et assetlinks.json qu'Elido sert depuis votre domaine.
Quel est le processus de configuration AASA ?
Dans les paramètres de domaine Elido → Deep links : entrez le bundle ID de votre app iOS (ex. com.votreentreprise.app) et l'Apple Team ID (chaîne de 10 caractères de votre compte Apple Developer). Elido génère le JSON AASA et le sert à /.well-known/apple-app-site-association sur votre domaine personnalisé. Vérifiez qu'il est accessible avec curl avant de soumettre votre app sur TestFlight ou l'App Store. iOS télécharge le fichier AASA lors de l'installation de l'app sur les appareils iOS 9+.
Puis-je avoir plusieurs apps sur un seul domaine ?
Oui — le fichier AASA supporte plusieurs entrées d'apps. Configurez le bundle ID et le Team ID de chaque app dans les paramètres de domaine ; Elido génère un AASA combiné avec toutes les apps listées. L'assetlinks.json Android supporte également plusieurs combinaisons nom de package + empreinte. Cas d'usage courant : app principale et un App Clip, ou app principale et une extension widget.
Arrêt de Firebase Dynamic Links — quel est le chemin de migration ?
Remplacez les URL courtes page.link par des liens courts Elido (votre domaine personnalisé ou le domaine partagé Elido). Configurez l'AASA et l'assetlinks.json dans les paramètres de domaine Elido. Mettez en place la chaîne de fallback via les règles smart-link (règle iOS → App Store, règle Android → Play Store, fallback → web). Mettez à jour la génération de liens de partage dans votre app pour appeler l'API create_link d'Elido au lieu de Firebase. Ce qui ne migre pas : si votre app dépend du deferred deep-linking de Firebase (transmission d'intention post-installation), vous aurez besoin de Branch ou Adjust pour cette partie.
Comment tester les Universal Links avant publication sur l'App Store ?
Utilisez xcrun simctl openurl booted 'https://go.votreentreprise.com/test-slug' avec votre app installée sur un simulateur. Sur un appareil physique avec un build debug, appuyez longuement sur un lien dans Safari et regardez si « Ouvrir dans Votre App » apparaît. Apple fournit également l'App Association File Validator sur developer.apple.com — collez votre URL AASA et il vérifie l'accessibilité, le Content-Type et la validité JSON. L'AASA d'Elido passe les trois vérifications.
Qu'est-ce que le deferred deep-linking et pourquoi Elido ne le fait-il pas ?
Le deferred deep-linking transmet un contexte (ex. « l'utilisateur consultait le produit ID 123 ») du clic sur le lien à travers une installation d'app et jusqu'au premier lancement de l'app. Cela nécessite un SDK de fingerprinting ou d'attribution dans l'app (Branch, Appsflyer, Adjust) qui associe l'installation au clic pendant le processus d'installation. Elido n'installe pas de code SDK dans votre app ; nous ne servons que l'AASA et l'assetlinks.json. Sans le SDK, il n'y a pas de mécanisme pour transmettre le contexte à travers une installation. Pour le cas d'usage basique « ouvrir le bon écran si installée », Elido est suffisant. Pour transmettre l'intention à travers l'installation, vous avez besoin d'un MMP.
Puis-je utiliser les deep links sur le domaine partagé Elido (s.elido.me) ?
Non. Les Universal Links et App Links nécessitent votre propre domaine — vous ne pouvez pas déclarer *.elido.me comme domaine Universal Link pour votre app. Les deep links nécessitent un domaine personnalisé sur Pro ou Business. Le domaine personnalisé est celui que vous configurez dans votre AASA et assetlinks.json, et Elido sert ces fichiers depuis celui-ci.
Comment gérer le cas où le navigateur de l'utilisateur bloque l'interception de l'app ?
Certains navigateurs (notamment Chrome sur Android pré-6.0, et certains navigateurs in-app comme celui d'Instagram) bloquent l'interception App Links ou Universal Links. L'URL de fallback est ce qu'ils voient. Pour les navigateurs in-app : redirigez d'abord vers le navigateur système en utilisant une URL intent (Android) ou une invite utilisateur. Pour les navigateurs in-app Instagram / TikTok : l'approche standard est d'afficher une invite « appuyez pour ouvrir dans votre navigateur ». Elido n'injecte pas cette invite automatiquement — l'URL de fallback est votre destination, et vous contrôlez ce qui s'y passe.
Keep reading
Configuration de domaine personnalisé — requis pour les deep links ; AASA et assetlinks.json servis depuis votre hostname.
iOS → App Store, Android → Play Store, desktop → web — la chaîne de fallback avec les règles smart-link.
Comment les équipes produit utilisent les deep links avec les variantes A/B et les règles smart-link.
Intégrations MMP — Appsflyer, Adjust et Branch pour le deferred deep-linking en complément d'Elido.
Prêt à essayer ?
Commencez avec le forfait gratuit, passez à la version supérieure lorsque vous avez besoin d'un domaine personnalisé.