Passer au contenu principal

​
Vue d’ensemble

Les liens profonds dirigent les utilisateurs vers un écran spécifique de votre application lorsqu’ils appuient sur un lien — qu’il provienne d’un e-mail, d’un SMS, d’un site web, d’une notification push ou d’un message in-app. Si l’application n’est pas installée, le système d’exploitation peut rediriger les utilisateurs vers la boutique d’applications ou vers une page web de secours. Ce guide couvre :
  • Les types de liens profonds et quand utiliser chacun
  • La configuration de plateforme pour Android et iOS
  • La gestion des liens profonds dans votre application avec le SDK OneSignal
  • Le comportement spécifique aux canaux pour le push, l’e-mail et les messages in-app
Pour la configuration générale des URL et des liens (URL de lancement, paramètres UTM, URL dynamiques, suivi des liens), consultez URL, liens et liens profonds.

​
Prérequis

Avant de configurer les liens profonds, vous avez besoin de :
  • Un compte OneSignal avec une application configurée
  • Le SDK OneSignal installé dans votre application mobile
  • Un domaine que vous contrôlez, hébergé en HTTPS, pour les Universal Links ou App Links
  • L’accès au code source et à la configuration de build de votre application (Xcode pour iOS, Android Studio pour Android)

​
Types de liens profonds

Il existe trois mécanismes courants de liens profonds. Chacun a un comportement différent selon que l’application est installée ou non.
TypePlateformeFormatApplication non installée
Universal LinksiOS 9+https://yourdomain.com/pathOuvre l’URL dans Safari
App LinksAndroid 6.0+https://yourdomain.com/pathOuvre l’URL dans le navigateur
Schémas URI personnalisésiOS et Androidmyapp://pathÉchoue silencieusement ou affiche une erreur
Recommandation : Utilisez les Universal Links (iOS) et les App Links (Android) pour l’expérience la plus fiable. Ils utilisent des URL https:// standard, fonctionnent sur tous les canaux (push, e-mail, SMS) et fournissent un comportement de secours lorsque l’application n’est pas installée. Les schémas URI personnalisés (myapp://) sont plus simples à configurer mais ne fournissent pas de comportement de secours et peuvent ne pas fonctionner dans tous les contextes (par exemple, les clients de messagerie).
Les Universal Links et les App Links nécessitent l’hébergement d’un fichier de vérification sur votre domaine. Sans ce fichier, le système d’exploitation traite le lien comme une URL web ordinaire.
Utilisez l’App Links Assistant d’Android Studio pour générer la configuration requise.

​
Configurer les filtres d’intent

Ajoutez un filtre d’intent à l’Activity qui doit gérer le lien profond : 
<activity android:name=".DeepLinkActivity" android:exported="true">
  <intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    <data android:scheme="https" android:host="yourdomain.com" />
  </intent-filter>
</activity>

​
Gérer l’intent entrant

Intent appLinkIntent = getIntent();
String appLinkAction = appLinkIntent.getAction();
Uri appLinkData = appLinkIntent.getData();
Générez le fichier assetlinks.json à l’aide de l’App Links Assistant d’Android Studio et hébergez-le à : 
https://yourdomain.com/.well-known/assetlinks.json
Consultez la documentation Google Verify App Links pour le format complet du fichier et les étapes de vérification.
Les Universal Links d’Apple ouvrent votre application lorsqu’un utilisateur appuie sur une URL https:// correspondante. Pour les cas d’utilisation plus simples où l’application est garantie d’être installée, vous pouvez utiliser les schémas d’URL à la place.

​
Activer les Associated Domains

  1. Dans Xcode, sélectionnez votre cible → Signing & Capabilities → ajoutez Associated Domains
  2. Ajoutez votre domaine : applinks:yourdomain.com
func application(_ application: UIApplication,
                 continue userActivity: NSUserActivity,
                 restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool {
  guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
        let url = userActivity.webpageURL else {
    return false
  }
  // Route to the correct screen based on the URL path
  return true
}

​
Héberger le fichier Apple App Site Association

Créez un fichier apple-app-site-association (AASA) et hébergez-le à : 
https://yourdomain.com/.well-known/apple-app-site-association
Remplacez TEAMID par votre Apple Team ID et com.example.app par votre identifiant de bundle : 
{
  "applinks": {
    "apps": [],
    "details": [{
      "appID": "TEAMID.com.example.app",
      "paths": ["/path/*", "/another-path"]
    }]
  }
}
Consultez la documentation Apple Supporting Associated Domains pour la spécification complète.

​
Comportement de l’URL de lancement iOS

Le SDK iOS de OneSignal utilise openURL pour gérer l’URL de lancement (propriété url). Cela fait que le lien s’ouvre d’abord dans le navigateur, puis redirige vers l’application — ce qui peut être une mauvaise expérience utilisateur. Pour éviter cela, utilisez l’une de ces approches :
  1. Utilisez data au lieu de url dans le payload de l’API et gérez le lien profond dans votre Listener de clic de notification push
  2. Supprimez les URL de lancement en ajoutant OneSignal_suppress_launch_urls à votre Info.plist comme booléen avec la valeur YES, puis gérez toute la navigation dans le listener de clic
L’approche 1 (utiliser data + listener de clic) est recommandée car elle vous donne un contrôle total sur la navigation sans vous fier au système d’exploitation pour résoudre l’URL.

​
Gérer les liens profonds avec le SDK OneSignal

La manière la plus fiable de gérer les liens profonds des messages OneSignal est d’utiliser les listeners de clic du SDK plutôt que de compter sur la résolution des liens au niveau du système d’exploitation. Cela vous donne un contrôle total sur la navigation dans votre application.

​
Listener de clic de notification push

Utilisez addClickListener pour intercepter les clics sur les notifications et diriger l’utilisateur en fonction de l’URL du lien profond ou des données supplémentaires : 
OneSignal.Notifications.addClickListener { event ->
  val url = event.notification.launchURL
  val data = event.notification.additionalData
  // Route to the correct screen based on url or data
}
Pour la référence complète de l’API incluant Java, Objective-C et Cordova/Ionic, consultez addClickListener() Push.

​
Listener de clic de message in-app

Utilisez le listener de clic de message in-app pour gérer les liens profonds des boutons et actions de messages in-app : 
OneSignal.InAppMessages.addClickListener { event ->
  val actionId = event.result.actionId
  // Route based on the action ID (your deep link URI)
}
Pour la référence complète de l’API, consultez addClickListener() In-App.

​
Notifications push

Incluez le lien profond de l’une de ces deux façons :
MéthodePropriété APIComportement
URL de lancementurl (ou app_url pour mobile uniquement)Le SO ouvre l’URL directement. Sur iOS, cela ouvre d’abord le navigateur sauf si supprimé.
Données supplémentaires (recommandé)dataL’URL est transmise à votre listener de clic. Vous contrôlez entièrement la navigation.

​
Comportement par plateforme

  • Android : Ouvre directement l’Activity correspondante via App Links
  • iOS : Ouvre Safari, puis l’application (sauf si vous supprimez les URL de lancement et gérez la navigation dans le listener de clic)
Consultez URL, liens et liens profonds pour les détails sur url, web_url et app_url.

​
E-mails

Par défaut, OneSignal réécrit les liens d’e-mail pour le suivi des clics. Cela modifie l’URL, ce qui rompt les liens profonds car le système d’exploitation ne reconnaît plus le domaine comme correspondant au Associated Domain de votre application.

​
Activer les liens profonds dans les e-mails

Pour préserver les liens profonds, désactivez le suivi des clics en utilisant l’une de ces méthodes :
  • Tableau de bord : Décochez Track link clicks dans l’éditeur d’e-mail
  • API : Définissez disable_email_click_tracking: true
  • Par lien : Utilisez le filtre Liquid {{ 'https://yourdomain.com/path' | do_not_track_link }} pour désactiver le suivi sur des liens individuels tout en le maintenant activé pour les autres
Éditeur d'e-mail OneSignal avec la case Track link clicks décochée
Désactiver le suivi des clics signifie que vous perdez les métriques de clics dans les Rapports d’e-mail. Envisagez d’utiliser des exclusions de suivi par lien pour préserver les analyses sur les URL non liées aux liens profonds.

​
Comportement des liens profonds dans les e-mails

ScénarioRésultat
iOS + Safari + Universal Link + Suivi désactivéOuvre l’application directement
iOS + Safari + Universal Link + Suivi activéOuvre Safari, invite à ouvrir l’application
iOS + client de messagerie non-Safari + Universal LinkOuvre l’App Store si l’application n’est pas installée
Android + App Link + Suivi désactivéOuvre l’application directement
Android + App Link + Suivi activéOuvre d’abord le navigateur, puis l’application

​
Messages in-app

Les liens profonds dans les messages in-app utilisent le modèle de listener de clic. Vous définissez un identifiant d’action personnalisé dans l’éditeur de messages, puis vous le gérez dans le code de votre application.

​
Éditeur glisser-déposer

  1. Ajoutez un bouton ou un élément cliquable
  2. Définissez l’action de clic sur Custom Action ID
  3. Saisissez votre URI de lien profond comme Action Name (par exemple, https://yourdomain.com/promo ou myapp://promo)

​
Éditeur HTML

Utilisez la méthode openUrl de la bibliothèque JS In-App pour déclencher des liens profonds depuis du HTML personnalisé.

​
Gérer le clic

Utilisez le listener de clic de message in-app pour intercepter l’action et naviguer l’utilisateur dans votre application.

​
Tester les liens profonds

​
Android

Utilisez adb pour tester les App Links sans envoyer de notification : 
adb shell am start -a android.intent.action.VIEW \
  -d "https://yourdomain.com/path" \
  com.your.package
Vérifiez que votre assetlinks.json est accessible : 
curl -I https://yourdomain.com/.well-known/assetlinks.json

​
iOS

Utilisez l’outil de validation des Associated Domains d’Apple pour vérifier votre fichier AASA. Vous pouvez également tester les Universal Links en :
  1. Collant le lien dans l’application Notes
  2. Appuyant longuement sur le lien pour confirmer que l’option “Ouvrir dans [App]” apparaît
  3. Appuyant sur le lien pour vérifier qu’il ouvre votre application
Les Universal Links ne fonctionnent pas lorsqu’ils sont saisis directement dans la barre d’adresse de Safari — ils doivent être touchés depuis une autre application (Notes, Mail, Messages, etc.).

​
Messages de test OneSignal

  1. Envoyez un push de test depuis le tableau de bord OneSignal avec une URL de lien profond comme URL de lancement ou dans les Données supplémentaires
  2. Vérifiez que la notification ouvre le bon écran dans votre application
  3. Vérifiez les journaux de votre listener de clic pour confirmer que l’URL ou les données ont été reçues

​
Dépannage

​
Le lien profond iOS ouvre Safari au lieu de l’application

C’est le problème le plus courant. Causes possibles :
  • Fichier AASA non hébergé correctement — Vérifiez qu’il est à https://yourdomain.com/.well-known/apple-app-site-association avec Content-Type: application/json et sans redirections
  • Associated Domains non configurés — Vérifiez dans Xcode → Signing & Capabilities → Associated Domains qu’il inclut applinks:yourdomain.com
  • Comportement de l’URL de lancement — Le SDK iOS de OneSignal utilise openURL pour la propriété url, ce qui déclenche le comportement navigateur en premier. Utilisez data + listener de clic ou supprimez les URL de lancement
  • Test dans Safari — Les Universal Links ne s’activent pas depuis la barre d’adresse de Safari. Testez depuis Notes, Mail ou une autre application.

​
Le lien profond Android ouvre le navigateur

  • autoVerify manquant — Assurez-vous que votre filtre d’intent inclut android:autoVerify="true"
  • assetlinks.json introuvable — Vérifiez que le fichier est à https://yourdomain.com/.well-known/assetlinks.json et renvoie HTTP 200
  • Incompatibilité d’empreinte SHA256 — L’empreinte dans assetlinks.json doit correspondre au certificat de signature de votre application. Les builds de débogage et de publication utilisent des certificats différents.

​
Le lien profond fonctionne en push mais pas en e-mail

Le suivi des clics d’e-mail réécrit les URL, rompant la vérification du domaine. Désactivez le suivi des clics pour les e-mails qui contiennent des liens profonds.

​
Le lien profond est reçu mais l’application ne navigue pas

  • Vérifiez que votre listener de clic est enregistré tôt dans le cycle de vie de l’application (par exemple, dans Application.onCreate() ou AppDelegate.didFinishLaunchingWithOptions)
  • Vérifiez que l’URL ou l’ID d’action correspond à ce qu’attend votre logique de routage
  • Sur iOS, confirmez que vous ne dépendez pas de url sans supprimer les URL de lancement — le navigateur peut consommer le lien avant que votre listener ne se déclenche

​
FAQ

​
Que se passe-t-il si l’application n’est pas installée ?

Avec les Universal Links (iOS), l’URL s’ouvre dans Safari comme une page web ordinaire. Avec les App Links (Android), l’URL s’ouvre dans le navigateur par défaut. Dans les deux cas, vous pouvez configurer votre page web pour rediriger vers la boutique d’applications appropriée. Les schémas URI personnalisés (myapp://) échouent silencieusement ou affichent une erreur si l’application n’est pas installée.

​
Dois-je utiliser l’URL de lancement ou les Données supplémentaires pour les liens profonds ?

Les Données supplémentaires (data) sont recommandées pour les liens profonds mobiles car elles vous donnent un contrôle total sur la navigation via le listener de clic. L’URL de lancement (url) est plus simple mais présente des limitations sur iOS (redirection du navigateur) et ne permet pas de logique de routage personnalisée.

​
Puis-je personnaliser les liens profonds avec des données utilisateur ?

Oui. Utilisez les URL dynamiques avec la syntaxe Liquid pour injecter des propriétés utilisateur, des tags ou des données personnalisées dans vos URL de liens profonds. Par exemple : https://yourdomain.com/profile/{{subscription.external_id}}.

​
Puis-je utiliser des liens profonds avec des schémas URI personnalisés ?

Oui. Définissez votre schéma personnalisé (par exemple, myapp://screen) comme valeur d’URL de lancement ou de Données supplémentaires. Les schémas personnalisés fonctionnent bien pour le push et les messages in-app mais peuvent ne pas fonctionner dans les clients de messagerie. Ils ne fournissent pas non plus de solution de secours si l’application n’est pas installée.

​
Les liens profonds fonctionnent-ils avec OneSignal Journeys ?

Oui. Lors de la configuration d’une étape de message dans un Journey, définissez l’URL de lancement ou les Données supplémentaires sur votre lien profond. Le comportement est le même que pour un push ou un message in-app autonome.

URL, liens et liens profonds

URL de lancement, paramètres UTM, URL dynamiques et configuration du suivi des liens.

Référence du SDK mobile

Référence complète de l’API pour les listeners de clic et la gestion des événements de notification.

Actions de clic In-App

Configurez les actions de clic pour les boutons et éléments de messages in-app.

Configuration push mobile

Configuration des notifications push spécifique à la plateforme pour Android et iOS.