Passer au contenu principal
Event Streams vous permet d’envoyer les données de messages hors de OneSignal en temps réel vers la destination de votre choix. Les event streams sont un excellent moyen de connecter OneSignal à d’autres produits de votre écosystème marketing. Ils permettent à votre équipe de déclencher des messages correspondants, de conserver des enregistrements et bien plus encore.

Cas d’usage courants

  1. 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.
  2. 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.
  3. 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é.
  4. 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.
  5. 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.
  6. 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.
  7. 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.
  8. 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 :
  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. Testez et dépannez : effectuez des tests pour vous assurer que tout fonctionne correctement avant la mise en production.
En travaillant en étroite collaboration avec votre équipe technique, vous pouvez débloquer la puissance de la diffusion d’événements pour améliorer votre stratégie de croissance.

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

Les données qui peuvent être envoyées avec ces événements sont toutes suffisamment similaires pour que vous puissiez envoyer des événements déclenchés par plusieurs canaux via le même event stream. Une autre approche consisterait à définir plusieurs event streams, chacun pour un seul canal ou événement, pour un contrôle plus granulaire ou pour réduire l’échelle des données envoyées.

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

Les identifiants de message et de modèle peuvent être copiés en naviguant vers Messages > Push, Email, SMS, ou Templates, en cliquant sur le bouton d’action du message ou modèle souhaité, et en sélectionnant Copy Message ID ou Copy Template ID dans le menu d’action.

Copying the Template ID of a template

Alternativement, vous pouvez copier l’identifiant de message/modèle de ce que vous visualisez directement depuis l’URL :
  • 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_TOKEN est 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}}
Remarque : OneSignal ne fournit pas de services de chiffrement

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-length
  • referer
  • metadata-flavor
  • x-google-metadata-request
  • host
  • x-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

À droite, vous pouvez voir un exemple de requête cURL construit à partir de ce qui a été saisi lors de la configuration de l’event stream

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 :
{
  "Event Data": {
    "event.kind": "{{ event.kind }}",
    "event.id": "{{ event.id }}",
    "event.timestamp": "{{ event.timestamp }}",
    "event.datetime": "{{ event.datetime }}",
    "event.app_id": "{{ event.app_id }}",
    "event.subscription_device_type": "{{ event.subscription_device_type }}",
    "event.subscription_id": "{{ event.subscription_id }}",
    "event.onesignal_id": "{{ event.onesignal_id }}",
    "event.external_id": "{{ event.external_id }}"
  },
  "Message Data": {
    "message.id": "{{ message.id }}",
    "message.name": "{{ message.name }}",
    "message.title": "{{ message.title.en }}",
    "message.contents": "{{ message.contents.en }}",
    "template_id": "{{ message.template_id }}",
    "message.template_id": "{{ message.template_id }}",
    "message.url": "{{ message.url }}",
    "message.app_url": "{{ message.app_url }}",
    "message.web_url": "{{ message.web_url }}"
  }
}

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înesDoivent être enveloppées dans des guillemets.
  • NombresNe doivent pas être enveloppés dans des guillemets.
  • ObjetsNe doivent pas être enveloppés dans des guillemets.
Exemples

Chaînes

✅ Correct
// Wrap string values in quotes
{
  "user_id": "{{ user.onesignal_id }}"
}
❌ Incorrect
{
  "user_id": {{ user.onesignal_id }}
}

Nombres et booléens

✅ Correct
// Don't wrap numbers or booleans in quotes
{
  "user_score": {{ user.tags.score }}
}
❌ Incorrect
{
  "user_score": "{{ user.tags.score }}"
}

Objets

✅ Correct
// Don't wrap objects in quotes.
{
  "user_data": {{ user.tags }}
}
❌ Incorrect
{
  "user_data": "{{ user.tags }}"
}
Meilleures pratiques pour gérer les conditionnels multilingues dans la syntaxe liquid Pour éviter les problèmes avec les conditionnels basés sur la langue
  1. Utilisez des vérifications de langue directes : Vérifiez toujours user.language directement dans les conditionnels, pas dans des variables comme userLang, pour une meilleure compatibilité.
  2. Commencez simplement : Commencez par des phrases de base, puis ajoutez progressivement de la complexité.
  3. Évitez l’imbrication excessive : Gardez les conditionnels plats pour éviter les problèmes d’analyse.
  4. Testez d’abord la ponctuation de base : Commencez par des phrases simples et de la ponctuation avant d’utiliser des caractères spéciaux.
  5. Utilisez des solutions de secours : Assurez-vous d’avoir une langue par défaut (par ex. anglais) en cas de traductions manquantes.
  6. Tenez-vous-en aux clés standard : Utilisez des clés OneSignal standard comme content/title/en pour la fiabilité.
Cette approche minimise les erreurs d’analyse et garantit la compatibilité avec le système.
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 un event.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 le message_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

Définissez les événements que vous souhaitez suivre. Dans cet exemple, nous utiliserons les événements push, mais tous fonctionneront.

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

Dans cet exemple, nous utiliserons l’Exemple de corps ci-dessus. Enregistrez l’événement et mettez-le en ligne. Envoyez un message pour déclencher l’événement. Dans webhook.site, nous verrons l’événement avec les données suivantes :

Example using webhook.site

Cela montre ce qui suit :
  • 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.