Skip to main content
Notifiez les utilisateurs lorsque quelque chose qui les concerne se produit : un like, une réponse, un abonnement, un message entrant ou un événement compétitif dans un jeu. Ces notifications favorisent le réengagement même lorsque les utilisateurs ne sont pas actuellement actifs dans votre application.
OneSignal n’est pas conçu pour la communication en temps réel. Les notifications push sont mieux utilisées comme solution de secours lorsque les utilisateurs ne sont pas activement dans l’application. Pour la messagerie in-app en temps réel, utilisez la couche de messagerie existante de votre application et déclenchez des notifications OneSignal uniquement lorsque le destinataire est hors ligne ou inactif.

Activité sociale

Notifiez les utilisateurs lorsque quelqu’un les like, les commente, les mentionne, les tague ou s’abonne à eux.

Messages directs

Alertez les utilisateurs des nouveaux messages entrants avec du debouncing et des liens profonds vers la conversation.

Alertes de jeu

Envoyez des événements compétitifs urgents comme les attaques de base, les défis et l’activité de guilde.

Prérequis

Avant de commencer, assurez-vous d’avoir :
Gardez les charges utiles custom_data sous 2 Ko. Le champ custom_data a une limite de taille stricte. L’envoi de charges utiles volumineuses — listes de conversations complètes, tableaux de classement, images en base64 ou HTML — risque la troncature ou le rejet. Pour du contenu riche, passez un identifiant (par exemple, digest_id ou summary_url) et faites en sorte que l’appareil du destinataire récupère la charge utile complète depuis votre backend au moment du tap. Voir Personnaliser les messages avec custom_data via l’API pour les détails de la limite de taille et les modèles d’itération de tableaux.

Notifications d’activité sociale

Envoyez une notification push lorsqu’un utilisateur est impliqué dans une action sociale. Utilisez custom_data pour injecter le nom de l’expéditeur, son avatar et le contexte pertinent dans le message au moment de l’envoi. Aucune donnée n’est stockée dans OneSignal.

Actions sociales courantes

Configuration

1

Détecter l'action sur votre backend

Lorsqu’une action sociale se produit, votre backend identifie l’expéditeur et le destinataire, ainsi que tout contexte pertinent comme l’ID de la publication ou son contenu :
JSON
2

Créer un modèle push

Dans le tableau de bord, allez dans Messages > Templates > New Push Template. Utilisez la syntaxe Liquid pour référencer les champs custom_data :Titre :
Liquid
Message :
Liquid
Image (optionnel, affiche l’avatar de l’expéditeur) :
Liquid
Enregistrez le modèle et notez son template_id.
3

Appeler l'API Create Message

Depuis votre backend, envoyez la notification au destinataire :
JSON
OneSignal effectue le rendu du modèle au moment de l’envoi en utilisant les valeurs de custom_data. Le nom et l’avatar de l’expéditeur apparaissent dans la notification sans être stockés dans OneSignal.
4

Optionnel : ajouter des solutions de secours email et SMS

Pour atteindre les utilisateurs qui ont désactivé le push ou dont la notification n’a pas été livrée, voir Solutions de secours email et SMS ci-dessous.
Utilisez des filtres | default: dans chaque espace réservé Liquid afin que le message reste naturel si un champ est manquant. Par exemple : {{ message.custom_data.sender_name | default: "Someone" }}. Voir Utiliser la syntaxe Liquid pour plus de filtres.
Exigences pour les URL d’avatar et d’image. L’URL sender_avatar (et toute autre image de notification) doit être :
  • HTTPS — iOS rejette les URL HTTP.
  • Accessible publiquement — APNs et FCM ne peuvent pas envoyer de requêtes authentifiées.
  • Inférieure à ~1 Mo — la limite iOS est de 10 Mo mais les fenêtres de livraison pratiques favorisent des ressources plus petites.
  • Servie avec l’en-tête Content-Type correctimage/jpeg, image/png, etc.
L’hébergement depuis un CDN avec des en-têtes de cache est la configuration la plus sûre.

Limiter les actions à fort volume

Une publication virale peut générer des milliers d’événements like par seconde. N’envoyez pas un push pour chacun — cela inonde le destinataire et conduit à ce que votre application soit mise en sourdine ou désinstallée. Le modèle à suivre :
  1. Accumulez les compteurs sur votre backend (par exemple, un compteur Redis indexé par destinataire + publication).
  2. Après une fenêtre de calme (10 minutes est une valeur par défaut raisonnable), envoyez un seul push récapitulatif : “12 personnes ont aimé votre publication.”
  3. Si d’autres likes arrivent après le récapitulatif, démarrez une nouvelle fenêtre — n’envoyez pas immédiatement un nouveau push.
La même logique s’applique aux commentaires, abonnements et réactions. Voir Limitation pour les limites de débit côté OneSignal si votre backend ne peut pas faire de debouncing.

Messages directs (utilisateur à utilisateur)

Notifiez un utilisateur lorsqu’il reçoit un nouveau message direct, et amenez-le directement dans la conversation via un lien profond.
N’envoyez un push que lorsque le destinataire n’est pas activement dans le chat. Notifier quelqu’un qui est déjà en train de lire la conversation crée une mauvaise expérience. Utilisez la logique propre à votre application pour vérifier si le destinataire est actuellement actif avant de déclencher une notification. OneSignal ne suit pas si un utilisateur utilise actuellement votre application.

Configuration

1

Détecter l'envoi d'un message et vérifier l'activité

Lorsque l’utilisateur A envoie un message à l’utilisateur B, vérifiez si l’utilisateur B est actuellement actif dans cette conversation. Si l’utilisateur B est hors ligne ou n’est pas dans la conversation, procédez à l’envoi d’un push.
2

Éviter d'envoyer un push par message

Si l’utilisateur A envoie plusieurs messages d’affilée, attendez une courte période après le dernier message avant de déclencher une notification. Voici comment faire dans votre backend :
  1. Lorsque le premier message arrive, démarrez un minuteur (par exemple, 60 secondes).
  2. Si un autre message arrive avant l’expiration du minuteur, réinitialisez-le.
  3. Lorsque le minuteur expire sans nouveaux messages, envoyez un seul push résumant le nombre de messages non lus.
OneSignal ne consolide pas automatiquement plusieurs appels API, donc si vous appelez l’API cinq fois, cinq notifications sont envoyées.
3

Envoyer la notification push

Envoyez un push à l’utilisateur B avec un lien profond vers la conversation :
JSON
Votre application lit data.conversation_id à l’ouverture de la notification et navigue vers le bon écran. Voir Liens profonds pour la configuration spécifique à chaque plateforme.
4

Optionnel : ajouter des solutions de secours email et SMS

Pour atteindre les utilisateurs qui ont désactivé le push ou dont la notification n’a pas été livrée, voir Solutions de secours email et SMS ci-dessous.
Regroupez nativement les notifications par conversation. Le debouncing côté backend réduit combien de notifications sont émises, mais iOS et Android peuvent également regrouper visuellement plusieurs notifications en un seul fil. Définissez un identifiant de fil ou de regroupement (par exemple, le conversation_id) pour que l’OS regroupe les messages du même chat. Voir Regroupement de notifications.
Mettez à jour le compteur de badge à chaque nouveau message. La plupart des applications de chat souhaitent que le badge iOS/Android reflète le total des messages non lus dans toutes les conversations. Passez le nombre de messages non lus via l’API à chaque push afin que le badge reste exact même lorsqu’un utilisateur efface une notification mais en a d’autres en attente. Voir Badges.
Confidentialité sur l’écran de verrouillage. iOS affiche le contenu des notifications sur l’écran de verrouillage par défaut — y compris l’aperçu du message (“Anna: ‘Hey, you around?’”). Pour les applications de messagerie avec du contenu sensible (santé, finance, rencontres, professionnel), envisagez d’envoyer un aperçu générique (“Nouveau message d’Anna”) et laissez les utilisateurs activer les aperçus complets via vos paramètres in-app.

Jeu : alertes compétitives et sociales

Les jeux compétitifs bénéficient d’alertes urgentes qui créent un sentiment d’urgence. Utilisez custom_data pour rendre ces notifications spécifiques et personnelles. Une notification qui nomme l’attaquant ou affiche des compteurs de ressources exacts est bien plus percutante qu’une alerte générique.

Événements compétitifs courants

Configuration

1

Détecter l'événement de jeu sur votre backend

Lorsqu’un événement compétitif se produit, le backend de votre jeu identifie le joueur concerné et capture le contexte pertinent :
JSON
2

Créer un modèle push

Dans le tableau de bord, créez un modèle push avec des références Liquid :Titre :
Liquid
Message :
Liquid
Enregistrez le modèle et notez son template_id.
3

Envoyer la notification

Appelez l’API Create Message depuis le backend de votre jeu :
JSON
L’url amène le joueur directement à l’écran de défense via un lien profond. L’objet data transmet le contexte au gestionnaire de notifications de votre application afin qu’il puisse charger le bon état de bataille.
4

Optionnel : ajouter des solutions de secours email et SMS

Pour atteindre les joueurs qui ont désactivé le push ou dont la notification n’a pas été livrée, voir Solutions de secours email et SMS ci-dessous.
Respectez les heures de calme pour les alertes non urgentes. Les push d’attaque de base à 3 h du matin heure locale sont une cause connue de désabonnement. Divisez vos alertes de jeu en deux niveaux :
  • Urgentes (guerre de guilde commençant dans 30 minutes, base attaquée en ce moment même) — envoyez immédiatement quelle que soit l’heure locale.
  • Non urgentes (troupes prêtes, récompense quotidienne disponible, récapitulatif hebdomadaire) — utilisez la Livraison intelligente ou l’Heure personnalisée par fuseau horaire pour qu’elles arrivent pendant les heures d’éveil dans le fuseau horaire local du joueur.
La plupart des désabonnements aux alertes de jeu proviennent de la deuxième catégorie envoyée au mauvais moment, et non de la première catégorie trop fréquente.
Envisagez les Live Activities pour les événements en cours. Pour les matchs, raids ou événements en direct en cours sur iOS 16.1+, une Live Activity sur l’écran de verrouillage et la Dynamic Island offre souvent une meilleure expérience que des notifications push répétées mettant à jour le même contexte. Utilisez les Live Activities pour l’état en direct (“23 minutes restantes, vous êtes #4”) et réservez le push pour les moments clés ou de fin.

Plus d’exemples d’alertes de jeu

Message du modèle :
Liquid
Requête API :
JSON

Solutions de secours email et SMS

Ajoutez une solution de secours email ou SMS à tout type de notification pour atteindre les utilisateurs qui ont désactivé le push ou dont la notification n’a pas été livrée. Utilisez l’API View Message pour vérifier une réception confirmée ou un clic. Si aucun n’est enregistré pendant votre fenêtre de délai, envoyez un suivi en utilisant la même approche custom_data avec un modèle Email ou SMS.
Activité socialeIdéal pour les actions à forte valeur comme les mentions et les réponses directes.
JSON
Exemple de modèle email (objet) :
Liquid
Messages directsIdéal comme récapitulatif quotidien des conversations non lues plutôt que des alertes par message.
JSON
Exemple de modèle email (objet) :
Liquid
Exemple de modèle email (corps, itérant sur le tableau conversations) :
Liquid
Voir Personnaliser les messages avec custom_data via l’API pour la référence complète d’itération de tableaux, y compris les objets imbriqués et le rendu conditionnel.JeuIdéal pour les récapitulatifs non urgents comme les résumés hebdomadaires de classement, les résultats de guerre de guilde ou les jalons débloqués.
JSON
Exemple de modèle email (objet) :
Liquid
Donnez aux utilisateurs le contrôle de leurs préférences de secours. Un opt-in comme “Me notifier par SMS si je manque un message” aide à éviter les messages indésirables pour les utilisateurs qui ont intentionnellement désactivé le push.

FAQ

OneSignal peut-il envoyer des notifications en temps réel, comme une application de chat ?

Non. Les notifications push sont livrées via l’infrastructure d’Apple (APNs) et de Google (FCM), ce qui introduit des délais de livraison variables et aucune garantie de livraison. Utilisez la couche de messagerie existante de votre application pour la communication in-app en temps réel et utilisez OneSignal comme solution de secours lorsque le destinataire n’est pas activement dans l’application.

Comment éviter de notifier un utilisateur qui est déjà dans l’application ?

OneSignal ne suit pas si un utilisateur est actuellement actif dans votre application. Votre propre logique backend doit déterminer s’il faut déclencher la notification. N’appelez l’API OneSignal que lorsque vous avez confirmé que le destinataire est hors ligne ou n’est pas sur l’écran concerné.

Comment éviter plusieurs notifications lors de séquences de messages rapides ?

Ajoutez un court délai dans votre backend avant d’envoyer une notification. Lorsque le premier message arrive, démarrez un minuteur. Si un autre message arrive avant son expiration, réinitialisez-le. Lorsque le minuteur expire, envoyez un seul push avec le nombre de messages non lus. OneSignal ne consolide pas automatiquement plusieurs appels API, donc si vous appelez l’API cinq fois, cinq notifications sont envoyées.

Le custom_data est-il enregistré dans le profil de l’utilisateur après l’envoi du message ?

Non. custom_data est éphémère et n’existe que pendant la requête API, utilisé pour le rendu du modèle au moment de l’envoi. Il n’est pas stocké dans OneSignal et ne peut pas être réutilisé dans de futurs messages ou Journeys. Pour des données utilisateur persistantes, utilisez les Tags.

Puis-je cibler plusieurs destinataires en un seul appel API ?

Oui. Passez plusieurs valeurs external_id dans le tableau include_aliases. Si chaque destinataire a besoin d’un contenu personnalisé différent (par exemple, des noms d’attaquants différents), utilisez le modèle de personnalisation en masse dans custom_data. Voir Personnaliser les messages avec custom_data via l’API pour l’approche complète. Le plafond exact de destinataires par appel et les limites de débit sont documentés dans la référence de l’API Create Message — pour de très grandes audiences, le ciblage par segment est plus efficace que de passer des milliers de valeurs external_id par appel.

Dois-je localiser les messages pour les utilisateurs internationaux ?

Oui pour toute audience multilingue. Les champs headings et contents acceptent plusieurs codes de langue (par exemple, { "en": "...", "es": "...", "fr": "..." }) et OneSignal sélectionne la bonne variante en fonction de la langue de chaque abonnement. Le même modèle s’applique aux champs des modèles. Voir Messagerie multilingue pour la référence complète, y compris le comportement de la langue de secours.

Pages associées

Personnaliser les messages avec custom_data via l'API

Injectez des données dynamiques spécifiques au message dans les modèles en utilisant custom_data et la syntaxe Liquid.

Personnalisation des messages

Vue d’ensemble de toutes les options de personnalisation dans OneSignal, y compris les Tags, les attributs utilisateur et la segmentation.

Liens profonds

Dirigez les utilisateurs vers un écran spécifique de votre application lorsqu’ils tapent sur une notification.

Créer un fil d'activité

Affichez un historique des alertes sociales dans votre application en utilisant la boîte de réception de notifications de OneSignal.

Modèles

Créez et gérez des modèles de messages réutilisables pour le push, l’email et le SMS.

API Create Message

Référence API complète pour envoyer des messages avec custom_data, le ciblage et tous les champs disponibles.