Cas d’usage courants
- Cartographie du parcours client et personnalisation : diffusez des événements vers un CRM ou une plateforme de données clients (CDP) pour créer des profils clients complets et adapter les campagnes à travers différents points de contact.
- Analyse et reporting : envoyez des événements de messages (par ex. envois, ouvertures, clics) vers un entrepôt de données pour analyser les modèles d’engagement ou les tendances à long terme à travers les canaux.
- Conformité et reporting réglementaire : diffusez toutes les données de messages envoyés vers un entrepôt de données à des fins d’audit et de conformité.
- IA et modèles prédictifs : envoyez des données d’événements de messages vers des IA internes ou des modèles prédictifs pour créer des cohortes clients complètes et comprendre les risques de désabonnement—tels que les désabonnements d’e-mails ou les rejets de messages, qui peuvent indiquer un désabonnement potentiel.
- Automatisation marketing : envoyez des événements d’engagement (comme les ouvertures ou clics de messages) vers d’autres outils pour déclencher automatiquement les prochaines étapes du parcours utilisateur ou mettre à jour les profils clients et l’activité récente.
- Fragmentation des données : les données clients précieuses résident souvent dans des outils séparés (tels que les plateformes d’engagement client, CRM, outils d’analyse et entrepôts de données). La diffusion d’événements aide à centraliser ces données, augmentant la visibilité des données first-party précieuses et permettant des résultats de revenus plus rapides.
- Communication lente entre les systèmes : en envoyant des événements d’engagement en direct vers d’autres systèmes, vous pouvez déclencher des actions immédiatement après qu’un événement se produise, plutôt que d’attendre des heures ou des jours pour des mises à jour par lots. Cela élimine la dépendance aux importations manuelles ou aux synchronisations de données.
- Inflation des dépenses et dette technique : au lieu de gérer plusieurs outils intermédiaires, vous pouvez connecter directement OneSignal avec votre entrepôt de données. Cela réduit les frais généraux coûteux de gestion de multiples intégrations ou pipelines de données personnalisés, diminue la dette technique et préserve des ressources techniques précieuses pour le produit et le marketing.
Comment collaborer avec votre équipe technique
La configuration d’Event Streams nécessite une collaboration avec votre équipe technique. Voici quelques conseils pour faciliter la conversation :- Expliquez les avantages : partagez votre stratégie d’utilisation de ces données et comment elles peuvent améliorer les campagnes marketing, personnaliser les expériences utilisateur, consolider les données et réduire la dette technique.
- Définissez la portée : identifiez où vous souhaitez envoyer les données, quels événements vous souhaitez suivre et le volume de données estimé. Cela aidera à configurer correctement les endpoints.
- Fournissez la documentation technique : partagez la documentation technique et les instructions de configuration de OneSignal. Votre équipe de développement devra configurer les endpoints destinataires et l’event stream dans OneSignal, en s’assurant que les données sont acheminées correctement.
- Discutez du volume de données et de la gestion : confirmez que vos systèmes peuvent gérer les flux de données en temps réel. Il est recommandé que le gestionnaire d’API enregistre les événements sans traitement en ligne supplémentaire pour maintenir des temps de réponse faibles.
- Testez et dépannez : effectuez des tests pour vous assurer que tout fonctionne correctement avant la mise en production.
Configuration
Vous pouvez configurer un nouvel event stream pour votre application OneSignal sous Data > Event Streams.Exigences
Les événements ne peuvent pas être envoyés à moins que les exigences suivantes soient remplies :- Une URL ou adresse IP valide pointant vers votre serveur HTTP(S)
- Les URL et adresses IP doivent être accessibles publiquement
- Les domaines doivent inclure un domaine de premier niveau reconnu (par ex. “.com”, “.net”)
Sélection d’événements
Cliquez sur “Select Events” pour sélectionner votre choix d’événements pour déclencher un event stream.
Trigger Webhook

Event Selection
Filtres d’event stream
Vous pouvez optionnellement affiner davantage les événements en spécifiant les identifiants d’un ou plusieurs messages ou modèles, vous permettant de recevoir uniquement des événements liés à des messages spécifiques dans votre application. Référez-vous aux instructions ci-dessous pour activer le filtrage d’event stream.
Filtering events by template

Copying the Template ID of a template
- Template –
https://dashboard.onesignal.com/apps/{APP_ID}/templates/{TEMPLATE_ID} - Push –
https://dashboard.onesignal.com/apps/{APP_ID}/notifications/{MESSAGE_ID} - Email –
https://dashboard.onesignal.com/apps/{APP_ID}/email/{MESSAGE_ID} - SMS –
https://dashboard.onesignal.com/apps/{APP_ID}/sms/{MESSAGE_ID}
Configurer l’Event Stream
Sélectionnez la méthode HTTP, l’URL et ajoutez des en-têtes pour l’event stream. C’est ici que l’authentification doit être configurée pour assurer une communication sécurisée entre OneSignal et vos systèmes. L’URI et les en-têtes peuvent contenir de la syntaxe liquid qui proviendra à la fois des propriétés utilisateur et des propriétés de l’event stream.En-têtes d’authentification
Vous pouvez ajouter des en-têtes d’authentification pour valider que les requêtes vers votre endpoint proviennent véritablement de OneSignal. Les méthodes d’authentification courantes incluent :- En-tête Authorization : Ajoutez un en-tête
Authorization, oùYOUR_TOKENest fourni par votre système ou un tiers comme :Basic {{YOUR_TOKEN}}Bearer {{YOUR_TOKEN}}ApiKey {{YOUR_API_KEY}}
- En-têtes personnalisés : Vous pouvez également ajouter des en-têtes personnalisés comme :
X-API-Key: {{YOUR_API_KEY}}
Tester votre configuration
Si vous cherchez un moyen facile de tester, utilisez webhook.site. Trouvez “Your unique URL” au centre de la page. Copiez cette URL et utilisez-la dans le champ URL de votre configuration d’event stream.
Configure Webhook
En-têtes non autorisés
Les en-têtes suivants sont restreints et ne peuvent pas être définis.content-lengthreferermetadata-flavorx-google-metadata-requesthostx-onesignal*
Corps
Le corps d’un event stream sera en JSON. Le JSON du corps peut être défini soit comme des paires clé/valeur individuelles, soit comme un bloc de code modifiable. Pour changer la méthode de saisie, utilisez le premier menu déroulant sous l’en-tête du corps et sélectionnez le corps personnalisé.
Event Stream Body Options

cURL Preview of Event Stream
Personnalisation
Vous pouvez personnaliser tous les champs de votre Event Stream avec des données Event Streams prédéfinies. Ces données peuvent être ajoutées en utilisant la syntaxe Liquid. Cela vous donne la flexibilité d’utiliser les event streams pour presque tous les cas d’usage.Voir Données Event Streams pour une liste de toutes les données d’événements, de messages et d’utilisateurs disponibles pour la personnalisation.
Exemple de corps
Sélectionnez “Custom Body” dans le menu déroulant :
Custom Body
Utilisation de la syntaxe Liquid dans JSON
Lors de l’utilisation de la syntaxe Liquid dans JSON, les guillemets appropriés dépendent du type de données : Directives pour le formatage JSON- Chaînes → Doivent être enveloppées dans des guillemets.
- Nombres → Ne doivent pas être enveloppés dans des guillemets.
- Objets → Ne doivent pas être enveloppés dans des guillemets.
Chaînes
✅ CorrectNombres et booléens
✅ CorrectObjets
✅ Correct- Utilisez des vérifications de langue directes : Vérifiez toujours
user.languagedirectement dans les conditionnels, pas dans des variables commeuserLang, pour une meilleure compatibilité. - Commencez simplement : Commencez par des phrases de base, puis ajoutez progressivement de la complexité.
- Évitez l’imbrication excessive : Gardez les conditionnels plats pour éviter les problèmes d’analyse.
- Testez d’abord la ponctuation de base : Commencez par des phrases simples et de la ponctuation avant d’utiliser des caractères spéciaux.
- Utilisez des solutions de secours : Assurez-vous d’avoir une langue par défaut (par ex. anglais) en cas de traductions manquantes.
- Tenez-vous-en aux clés standard : Utilisez des clés OneSignal standard comme
content/title/enpour la fiabilité.
Pour des détails et des options sur comment personnaliser vos messages en utilisant la syntaxe Liquid, consultez notre Guide d’utilisation de la syntaxe Liquid.
Résultats et débogage
Vous pouvez voir les performances de votre event stream sur une période de temps sur la page de rapport d’event stream sous l’onglet Report. Cela inclura les chiffres de tous les temps, le statut actuel de votre event stream et les données de séries chronologiques montrant quel type de réponses le hook a reçu. Toute réponse HTTP dans la plage 200 indique qu’un événement a été reçu avec succès, tandis que les réponses dans les 400 et 500 indiquent des erreurs. Un timeout signifie que le serveur de l’autre côté n’a pas réussi à répondre dans un délai raisonnable, donc OneSignal a fermé la connexion et a supposé qu’elle avait échoué. Vous pouvez voir un échantillon de requêtes récentes sous l’onglet Logs pour encore plus de détails. Cela montrera les requêtes réelles et les réponses de l’autre côté (si applicable). Si votre event stream a des problèmes, c’est un excellent endroit pour regarder en premier. Si vous devez modifier/mettre à jour votre event stream, vous pouvez le modifier sur la page du formulaire et envoyer des requêtes de test pour voir tous les détails dont vous avez besoin jusqu’à ce que vous ayez raison.
Event Stream Logs and Metrics
Nouvelles tentatives / Désactivation
Lorsqu’une requête Event Stream échoue pour une raison récupérable (par exemple, code de statut 429), OneSignal tentera de renvoyer l’événement après un court délai. Cela se produira quelques fois avec des délais croissants entre les requêtes. Si suffisamment de tentatives échouent d’affilée, le hook sera marqué comme ‘échoué définitivement’ et ne sera plus retenté. Si trop de requêtes séparées échouent d’affilée, c’est probablement à cause d’un problème du côté destinataire ; le côté destinataire pourrait avoir des erreurs ou avoir changé/désactivé quelque chose. OneSignal continuera à envoyer des requêtes jusqu’à un certain point, mais si les requêtes continuent d’échouer, l’event stream pourrait être désactivé par OneSignal. Si cela se produit, assurez-vous de passer du temps à dépanner, corriger puis tester l’event stream avant de le réactiver. Une API peu performante pourrait conduire à la désactivation de l’event stream. Il est important que l’API qui ingère un event stream soit capable de gérer le volume d’événements produit par les envois de messages. L’examen du volume d’envois de messages produits par votre application reflétera les performances requises de votre API. Nous recommandons que l’API recevant l’event stream enregistre un événement sans aucun autre traitement en ligne. Cela maintiendra les temps de réponse faibles et évitera tout problème lié à la latence. Un temps de réponse lent ou des réponses avec code de statut 429 de votre API peuvent causer un arriéré d’événements. Un arriéré constant d’événements conduira OneSignal à désactiver l’event stream afin que vous puissiez mettre à jour votre API pour gérer le débit requis. OneSignal enverra des e-mails aux administrateurs d’applications et aux administrateurs d’organisation lorsqu’un event stream commence à connaître un volume important d’événements échoués (mais n’a pas encore été désactivé) ainsi qu’un e-mail lorsque l’event stream est désactivé lorsque trop d’événements n’ont pas pu être envoyés. Il y aura également une bannière sur la page d’index des event streams notifiant un utilisateur OneSignal des problèmes avec l’un de leurs event streams. Chaque Event Stream a unevent.id unique pour chaque événement. Cela peut être utilisé comme en-tête ou dans le corps du message comme moyen de vérifier et potentiellement dédupliquer les requêtes si vous voyez les mêmes passer.
Conseils pour réussir
- Vous voudrez généralement que les event streams se connectent à vos propres serveurs, pas aux services tiers.
- Bien qu’il n’y ait rien de mal à se connecter directement à un tiers, ce qui suit peut être plus difficile à gérer : Il sera plus difficile de configurer/déboguer
- Le volume de requêtes ne sera pas géré dans OneSignal.
- Les événements d’event stream seront envoyés aussi rapidement que les utilisateurs atteignent les étapes de votre journey et cela pourrait submerger d’autres services, atteindre les limites de débit, ou faire monter VOTRE facture de manière inattendue. C’est particulièrement courant lorsque vous essayez d’utiliser un autre canal de messagerie pour quelque chose comme SMS. La flexibilité des event streams signifie que OneSignal ne sait pas ce que vous essayez d’accomplir avec eux, donc vous voudrez peut-être créer un service simple de votre propre qui accepte les requêtes d’event stream et gère ensuite correctement vos limites de connexion tierces, limites de débit et file d’attente.
- De nombreux services ont des API HTTP publiques, ce qui signifie que vous pouvez vous y connecter avec un event stream ; recherchez leurs docs API et des exemples de comment faire une requête HTTP pour trouver le bon endroit pour commencer.
Limitations des données d’événements de message
Les données des messages envoyés via nos Journeys ou API ne sont disponibles dans notre système que pendant 30 jours. Cela signifie que tous les événements de message (comme les clics, ouvertures, désabonnements, etc.) qui se produisent 30+ jours après l’envoi du message Journey ou API, ne seront pas disponibles dans l’event stream. Cela peut apparaître comme des données vides ou manquantes dans votre analyse. Pour contourner cette limitation, vous pouvez corréler lemessage_id de ces événements cliqués/ouverts/désabonnés avec l’événement d’envoi original qui a le même message_id. L’événement sent original devrait avoir les données de message pertinentes (titre, modèle, etc).
Tests
Utilisez un outil comme https://webhook.site/ et définissez l’Your unique URL fournie dans le paramètre URL de l’Event Stream avec la méthode POST.
The URL matches the "Your unique URL" from webhook.site

Push message events selected, but any can be used for testing.

Example using webhook.site
- Host : l’adresse IP d’où provient la requête. Voir Aperçu de l’API REST pour une liste des IP possibles.
- Request Content : les données envoyées dans le corps de l’event stream.