Envoyez des notifications push, email et SMS pour les likes, abonnements, messages directs et événements de jeu avec custom_data pour vos alertes.
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.
Un external_id défini pour chaque utilisateur afin de pouvoir les cibler par votre propre identifiant. Voir Utilisateurs et alias.
Un backend capable de détecter les actions sociales et d’appeler l’API OneSignal. Voir Vue d’ensemble de l’API REST.
Des Modèles créés dans le tableau de bord si vous prévoyez d’utiliser custom_data pour la personnalisation. Un template_id est requis pour utiliser custom_data.
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.
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.
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
{ "action": "like", "sender_id": "user_b", "sender_name": "Anna", "sender_avatar": "https://cdn.yourapp.com/avatars/anna.jpg", "recipient_id": "user_a", "post_id": "xyz789", "post_title": "My Hawaii trip"}
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 :
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 correct — image/jpeg, image/png, etc.
L’hébergement depuis un CDN avec des en-têtes de cache est la configuration la plus sûre.
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 :
Accumulez les compteurs sur votre backend (par exemple, un compteur Redis indexé par destinataire + publication).
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.”
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.
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.
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 :
Lorsque le premier message arrive, démarrez un minuteur (par exemple, 60 secondes).
Si un autre message arrive avant l’expiration du minuteur, réinitialisez-le.
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 :
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.
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.
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.
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.
{{ message.custom_data.overtaker_name | default: "Another player" }} just passed you. You dropped from #{{ message.custom_data.previous_rank }} to #{{ message.custom_data.current_rank }} on the leaderboard.
{{ message.custom_data.challenger_name | default: "A player" }} challenged you to a {{ message.custom_data.game_mode | default: "duel" }}. You have {{ message.custom_data.hours_to_respond | default: "24" }} hours to accept.
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.
Email
SMS
Activité socialeIdéal pour les actions à forte valeur comme les mentions et les réponses directes.
JSON
{ "app_id": "YOUR_APP_ID", "template_id": "YOUR_EMAIL_TEMPLATE_ID", "include_aliases": { "external_id": ["user_a"] }, "custom_data": { "sender_name": "Anna", "sender_avatar": "https://cdn.yourapp.com/avatars/anna.jpg", "action": "liked your post", "post_title": "My Hawaii trip", "post_url": "https://yourapp.com/posts/xyz789" }}
Exemple de modèle email (objet) :
Liquid
{{ message.custom_data.sender_name | default: "Someone" }} {{ message.custom_data.action | default: "interacted with your post" }}
Messages directsIdéal comme récapitulatif quotidien des conversations non lues plutôt que des alertes par message.
You have {{ message.custom_data.unread_count | default: "new" }} unread message{% if message.custom_data.unread_count != "1" %}s{% endif %}
Exemple de modèle email (corps, itérant sur le tableau conversations) :
Liquid
<h2>You have {{ message.custom_data.unread_count }} unread messages</h2><ul> {% for conversation in message.custom_data.conversations %} <li> <strong>{{ conversation.sender_name }}:</strong> "{{ conversation.preview }}" <a href="{{ conversation.url }}">Open</a> </li> {% endfor %}</ul>
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.
{{ message.custom_data.sender_name | default: "Someone" }} mentioned you in "{{ message.custom_data.post_title | default: "a post" }}". Tap to reply: {{ message.custom_data.post_url }}
Messages directsIdéal pour les messages manqués individuels plutôt que pour les séquences de messages en masse.
New message from {{ message.custom_data.sender_name | default: "a user" }}: "{{ message.custom_data.message_preview }}". Reply in the app: {{ message.custom_data.conversation_url }}
JeuIdéal pour les événements urgents comme les attaques de base où le joueur doit agir immédiatement.
⚔️ ATTACK! {{ message.custom_data.attacker_name | default: "An enemy" }} is raiding your base. {{ message.custom_data.gold | default: "0" }} gold at risk. Defend now: {{ message.custom_data.game_url }}
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.
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.