Campagnes Push Déclenchées : Guide des Workflows Contextuels

C'est la deuxième semaine du trimestre et votre tableau de bord de rétention affiche six déclencheurs « automatisés » en cours d'exécution, tous au vert. Le déclencheur d'abandon de panier continue de s'activer pour les abonnés qui ont déjà payé. Le rappel de réengagement chevauche l'alerte de baisse de prix pour le même client inactif. La série de bienvenue envoie des notifications indépendamment de la relance du premier achat. La demande d'avis post-achat est envoyée aux abonnés qui ont retourné la commande hier.

Chacune des six campagnes push déclenchées est un pipeline pointant vers la même liste d'abonnés, chacune prétendant que les cinq autres n'existent pas. Le taux d'achat répété a cessé d'évoluer il y a douze mois et personne dans l'équipe ne peut attribuer de revenus par déclencheur car les déclencheurs ne partagent pas d'état.

C'est la réalité opérationnelle dans la plupart des systèmes de rétention du marché intermédiaire. Le problème n'est pas la stratégie. La stratégie est bonne. Le problème est l'architecture. Une notification déclenchée en 2024 était un message unique qui s'activait lors d'un événement unique. En 2026, ce primitif n'est pas suffisant. Le parcours doit se souvenir de ce que l'abonné a fait, s'y ramifier et en sortir lorsqu'il convertit.

Cet article présente le cas architectural. Il définit la frontière entre les notifications push broadcast, déclenchées et contextuelles, explique la différence entre les déclencheurs d'événements et les déclencheurs d'audience, nomme les six types de nœuds qui transforment un déclencheur unique en un flux de travail contextuel, et propose trois modèles de migration qui consolident six déclencheurs autonomes en trois parcours contextuels avec des critères de sortie partagés et des analyses par flux de travail.

Contextuel, déclenché, broadcast : trois primitives, pas une

Trois primitives sous-tendent chaque programme de notification push. La plupart des équipes les regroupent dans un seul bloc appelé « campagnes », ce qui est le point de départ du problème d'architecture.

Broadcast. La même notification est envoyée à l'ensemble de l'audience correspondante, planifiée. Vente flash à midi. Alerte nouvelle collection le jour du lancement. Le broadcast est la primitive appropriée pour les annonces limitées dans le temps où chaque destinataire reçoit la même charge utile. C'est la primitive incorrecte pour tout ce qui dépend de l'état de l'abonné.

Déclenché. Une notification unique s'active lorsqu'un événement unique se produit. L'abonné abandonne un panier, la notification d'abandon de panier s'active. L'abonné consulte une page produit, la notification de consultation s'active. L'abonné achète, la notification post-achat s'active. Le déclencheur n'a pas de mémoire. Il ne sait pas ce qui s'est passé il y a cinq minutes ni ce qui est prévu pour mardi prochain. Chaque déclencheur est un pipeline ignorant de tous les autres déclencheurs.

Contextuel. Un workflow utilise le déclencheur comme point d'entrée, puis s'adapte à l'état de l'abonné. Le même événement d'abandon de panier lance un parcours en plusieurs étapes : une attente d'une heure, un premier rappel, une attente de 24 heures, une décision qui vérifie si le panier est toujours ouvert, un second rappel avec une réduction, une attente de 48 heures, un troisième rappel, et une règle de sortie qui annule le workflow dès que l'abonné achète. La campagne est le workflow, pas le déclencheur. Les notifications push contextuelles sont la manière dont les messages déclenchés se comportent une fois que l'architecture est à jour.

Les trois primitives correspondent proprement à trois charges de travail. Utilisez ce tableau lorsque vous auditez votre pile actuelle.

Capacité	Diffusion	Déclenché	Contextuel
État par abonné	Non	Non	Oui
Branchement basé sur le comportement	Non	Non	Oui
Critères de sortie	Non	Non	Oui
Routage multicanal au sein d'une campagne	Non	Non	Oui
A/B intégré (heure d'envoi, copie, canal)	Non	Non	Oui
Bonne charge de travail	Ventes flash, annonces de lancement	Pings transactionnels ponctuels (faible volume)	Parcours de cycle de vie (accueil, panier, reconquête, renouvellement)

La plupart des programmes de cycle de vie nécessitent du contextuel. La plupart des équipes expédient du déclenché. Cet écart est le sujet de cet article. Les workflows d'automatisation marketing qui expédient des parcours contextuels ne ressemblent pas à une longue liste de déclencheurs ; ils ressemblent à un ensemble plus restreint de parcours multi-étapes composés à partir d'un vocabulaire partagé. Les workflows de notifications push que vous voulez réellement sont trois parcours contextuels, pas neuf déclencheurs.

Les déclencheurs d'événements et les déclencheurs d'audience se comportent très différemment

Avant l'anatomie des nœuds, un point de taxonomie que presque tous les articles sur ce sujet font mal. Un « déclencheur » dans les workflows de notifications push n'est pas une primitive unique. Ce sont deux primitives qui se ressemblent de l'extérieur et se comportent très différemment en interne.

Les déclencheurs d'événements se déclenchent par abonné lors d'un événement réel. Les événements pris en charge dans les Workflows PushEngage incluent PushEngage.Subscriber.Added, PushEngage.Subscriber.AddSegment, PushEngage.Subscriber.RemoveSegment, PushEngage.Subscriber.UpdateField, PushEngage.Subscriber.UpdateAttribute, PushEngage.Goal.Tracked et PushEngage.CustomEvent. Lorsque l'événement se déclenche, le système évalue les workflows actifs, vérifie les critères de filtrage d'événements, vérifie les règles de sortie et met en file d'attente le workflow correspondant pour cet abonné. L'écart entre le déclencheur et la mise en file d'attente est de quelques secondes. Les déclencheurs d'événements sont la primitive appropriée pour toute campagne réactive : abandon de panier, abandon de navigation, suivi d'achat, accueil de bienvenue après ajout à un segment. Les campagnes push déclenchées par événement sont le cas dominant dans l'e-commerce, l'intégration SaaS et tout programme avec des signaux en temps réel.

Les déclencheurs d'audience activent un filtre à un moment programmé. Le filtre sélectionne les abonnés correspondant à des critères spécifiques, tels que last_active > 30 days, loyalty_tier = gold, ou city = New York AND segments includes "vip". Le planificateur récupère l'ensemble des abonnés correspondants par lots de 1000, décale l'exécution de 15 secondes à 2 minutes, et crée une instance de workflow par abonné. Les déclencheurs d'audience sont l'outil idéal pour la ré-engagement, les campagnes d'anniversaire, les promotions géographiques, et tout programme où l'ensemble est défini par un attribut plutôt que par un événement.

Les différences sont importantes sur le plan opérationnel, pas seulement conceptuel :

Aspect	Déclencheur d'événement	Déclencheur d'audience
Initiation	Temps réel sur événement d'abonné	Programmé via planificateur
Vitesse	En quelques secondes	Par lots, délai de 1 à 2 minutes
Sélection d'abonnés	Un abonné par événement	Sélection en masse uniquement au moment du démarrage du workflow
Nouveaux abonnés après le démarrage	Inclus automatiquement lors du prochain événement	NON inclus automatiquement après le démarrage du workflow
Modification du filtre après le démarrage	N/A	La modification du filtre N'AJOUTE PAS de nouveaux abonnés
Données d'événement disponibles	Oui (pour le remplacement de variables)	Non

La troisième ligne est le piège. Un workflow basé sur l'audience sélectionne son ensemble d'abonnés une seule fois, au démarrage du workflow. Les abonnés qui deviennent inactifs après le démarrage du workflow ne sont pas automatiquement ajoutés. La modification du filtre d'audience sur un workflow actif n'attire pas de nouveaux candidats. Une équipe de rétention qui lance un workflow « réactivation pour les abonnés inactifs depuis plus de 30 jours » et le laisse s'exécuter pendant quatre-vingt-dix jours verra la même cohorte fixe pendant toute la durée, même si de nouveaux abonnés franchissent le seuil de 30 jours chaque jour.

La réponse architecturale consiste à dupliquer le workflow d'audience selon une planification récurrente, mensuelle ou hebdomadaire, de sorte que chaque duplicata capture les candidats qui ont franchi le seuil depuis la dernière exécution. Il s'agit d'une note opérationnelle d'une ligne dans la documentation et d'une source récurrente de tickets de support « pourquoi cet abonné n'a-t-il pas reçu la campagne ? » dans les équipes qui traitent les déclencheurs d'audience comme des déclencheurs d'événements.

Les six nœuds qui transforment un déclencheur en une campagne contextuelle

Une fois le déclencheur activé, le workflow lui-même est composé de six types de nœuds. Le vocabulaire est suffisamment restreint pour être appris en cinq minutes et suffisamment vaste pour composer toute campagne contextuelle qu'une équipe de rétention a jamais souhaité expédier.

DÉMARRAGE. Le point d'entrée. Un nœud DÉMARRAGE définit le déclencheur (basé sur un événement ou une audience) et les critères de filtrage. Un workflow a exactement un DÉMARRAGE. Le point d'entrée détermine la taxonomie du déclencheur de la section précédente et définit le contexte des données d'événement que les nœuds en aval peuvent lire.

ATTENDRE. Un délai. Un nœud ATTENDRE retient l'abonné pendant une durée spécifiée (minutes, heures, jours) ou jusqu'à une heure spécifique du calendrier. Les attentes permettent à un workflow de respecter l'état de l'abonné et le fuseau horaire de l'abonné. Le workflow peut attendre une heure pour un rappel d'abandon de panier, trois jours pour une mise en avant de fonctionnalité dans une série de bienvenue, ou jusqu'à mardi 10h dans le fuseau horaire local de l'abonné pour un envoi pendant les heures ouvrables. Les attentes vous permettent également de composer une série d'envois en plusieurs étapes sans envoyer tous les messages dans les soixante premières secondes.

DÉCISION. Une branche à deux voies. Un nœud DÉCISION vérifie un filtre d'événement ou un filtre d'audience et dirige l'abonné vers le chemin OUI ou le chemin NON. L'abonné a-t-il acheté ? Est-il toujours dans le segment des abandonneurs de panier ? Son niveau de fidélité a-t-il changé ? Les nœuds de décision permettent aux notifications push comportementales de cesser de traiter tous les abonnés de la même manière et de commencer à s'adapter à ce que chaque abonné a réellement fait. Les opérateurs pris en charge incluent égal à, différent de, dans, pas dans, supérieur à, inférieur à, et existe, ce qui est suffisant pour exprimer toute logique de décision dont une équipe de rétention a besoin.

SPLIT_PATH. Une bifurcation basée sur un pourcentage pour les tests A/B. Un nœud SPLIT_PATH dirige les abonnés sur deux chemins ou plus en fonction de pourcentages configurés : 50/50 pour un test à deux voies, 33/33/34 pour un envoi à trois voies, 90/10 pour un groupe de contrôle. Le système utilise un algorithme d'équilibrage de charge qui dirige chaque nouvel abonné vers le chemin le moins utilisé, ce qui maintient la précision de la distribution même avec de petits échantillons. Une fois que le test atteint une signification, définissez winner_edge_id et le workflow promeut 100 % du trafic vers la variante gagnante sans reconstruire le workflow.

ACTION. Le travail lui-même. Les nœuds ACTION font plus qu'envoyer une notification push. PushEngage Workflows prend en charge onze types d'actions : SendPushNotification, AddSegment, RemoveSegment, UpdateField, UpdateAttribute, Update (combiné), HttpRequest, CustomEvent.Send, SendTriggerCampaignEvent, Workflow.Start et Workflow.Stop. Les quatre plus courants dans les programmes de rétention sont SendPushNotification, AddSegment (pour marquer l'abonné comme converti, intégré ou à risque de désabonnement), UpdateAttribute (pour incrémenter un compteur de fidélité ou définir une date de dernier achat) et HttpRequest (pour synchroniser l'état avec un CRM, déclencher une alerte Slack pour un prospect de grande valeur ou appeler un service en aval).

FIN / SORTIE. Le terminal. Les nœuds FIN et SORTIE marquent la fin du workflow et mettent à jour les analyses. FIN est la conclusion naturelle. SORTIE est généralement placé sur le chemin NON d'une décision lorsque l'abonné n'est pas qualifié, ou sur une branche de chemin divisé conçue comme groupe de contrôle. Le système prend également en charge les critères de sortie au niveau du workflow : un audience_filter ou un trigger_event qui annule le workflow actif avant l'exécution de chaque nœud. La règle de sortie se déclenche quel que soit le nœud sur lequel se trouve actuellement l'abonné. C'est ce qui empêche le workflow d'abandon de panier d'envoyer des rappels aux abonnés qui ont déjà acheté.

Chaque campagne contextuelle de cet article est composée de ces six éléments. Les modèles de migration ci-dessous se lisent rapidement une fois le vocabulaire partagé.

Trois modèles de migration : six déclencheurs autonomes deviennent trois flux de travail contextuels

La plupart des solutions de rétention pour le marché intermédiaire comportent entre quatre et huit déclencheurs autonomes. Le schéma est cohérent : notification de bienvenue, coup de pouce pour le premier achat, abandon de panier, abandon de navigation, demande d'avis post-achat, reconquête, réactivation, VIP inactif. Chacun d'eux est un déclencheur distinct avec sa propre copie, son propre propriétaire et ses propres analyses. Aucun d'entre eux ne connaît l'existence des autres. Les trois mêmes workflows contextuels peuvent générer le même revenu avec un tiers de la surface.

Modèle 1 — Consolidation de l'onboarding

Regroupez la série de bienvenue et le coup de pouce pour le premier achat en un seul workflow avec une décision sur le statut d'achat.

• DÉMARRAGE : Événement PushEngage.Subscriber.Added
• Type d'exécution : Unique (refroidissement de 90 jours après achèvement)
• Flux : ATTENDRE 1 jour → ACTION envoyer notification de bienvenue → ATTENDRE 3 jours → DÉCISION : l'abonné a-t-il acheté ? → chemin OUI : ACTION envoyer remerciements + ACTION AddSegment à customers + FIN → chemin NON : ACTION envoyer offre de 10 % pour le premier achat → ATTENDRE 4 jours → DÉCISION : l'abonné a-t-il acheté ? → chemin OUI : ACTION envoyer remerciements + FIN → chemin NON : ACTION envoyer dernier coup de pouce + FIN
• Critères de sortie : Aucun au niveau du workflow ; les branches de décision gèrent l'abonné converti
• Remplace : Déclencheur de bienvenue + déclencheur de premier achat (2 déclencheurs → 1 workflow)

L'état partagé est le but principal. La troisième notification ne se déclenche que pour les abonnés qui ne se sont pas convertis au quatrième jour. Le déclencheur de premier achat dans l'ancienne architecture se déclenchait pour chaque nouvel abonné, y compris ceux qui achetaient lors de leur première session. Le workflow cesse de les déranger.

Modèle 2 — Chaîne panier-avis

Regroupez la récupération d'abandon de panier et la demande d'avis post-achat en un seul workflow avec une transition de chaînage de workflow.

• DÉMARRAGE : Événement personnalisé cart_abandoned
• Type d'exécution : Plusieurs parallèles (chaque panier abandonné est sa propre instance)
• Flux : ATTENDRE 1 heure → ACTION rappel n°1 → ATTENDRE 24 heures → DÉCISION : le panier est-il toujours abandonné ? → chemin OUI : ACTION rappel n°2 avec 10 % → ATTENDRE 48 heures → DÉCISION : le panier est-il toujours abandonné ? → chemin OUI : ACTION dernier rappel avec 20 % → FIN
• Critères de sortie (niveau du workflow) : Goal.Tracked = purchase correspondant au cart_id de l’événement déclencheur. Au moment où l’abonné achète, le workflow est annulé.
• Transfert : En cas de sortie due à un achat, le système déclenche PushEngage.Workflow.Start ciblant le workflow de demande d’avis. Le workflow d’avis ne démarre que pour les abonnés qui ont effectivement acheté. Le chemin de sortie dû à un non-achat saute entièrement le transfert.
• Remplace : Déclencheur de panier + déclencheur d’avis post-achat + ticket de support des demandes d’avis adressées aux abonnés qui n’ont jamais acheté (3 problèmes → 1 workflow)

L’enchaînement via Workflow.Start est la réponse architecturale à la progression du cycle de vie. Au lieu de deux déclencheurs se lançant indépendamment et se chevauchant sur les mêmes abonnés, la sortie du workflow de panier en cas d’achat est ce qui démarre le workflow d’avis. L’avis ne se déclenche que pour les abonnés convertis. Le panier ne se déclenche jamais après la conversion. Le transfert est appliqué par le moteur.

Modèle 3 — Consolidation de la ré-engagement

Fusionner les campagnes de reconquête, de réactivation et de VIP inactifs en un seul workflow avec un déclencheur d’audience et trois branches de décision.

• DÉMARRAGE : Filtre d’audience last_active > 30 jours
• Type d’exécution : Unique (une tentative de réengagement par abonné par fenêtre de 90 jours)
• Flux : DÉCISION : niveau de fidélité ? → Branche Or : ACTION envoyer « vous nous manquez, VIP » avec une offre de 20 % → Branche Argent : ACTION envoyer « vous nous manquez » avec une offre de 10 % → Branche sans niveau : ACTION envoyer « vous nous manquez » standard avec une offre de livraison gratuite → ATTENDRE 5 jours → DÉCISION (par branche) : l’abonné a-t-il interagi ou visité le site ? → Chemin OUI : ACTION AddSegment à réengagé + FIN → Chemin NON : ACTION envoyer « dernière chance » avec une offre plus avantageuse + FIN
• Critères de sortie (niveau du workflow) : Filtre d’audience last_active < 7 jours. L’abonné est redevenu actif de lui-même et le travail du workflow est terminé.
• Remplace : Déclencheur de reconquête + déclencheur de réactivation + déclencheur de VIP inactif (3 déclencheurs → 1 workflow)
• Note opérationnelle : Conformément à l’astuce du déclencheur d’audience dans la section précédente, ce workflow n’inclut pas automatiquement les abonnés qui franchissent le seuil de 30 jours après le démarrage du workflow. Dupliquez le workflow mensuellement afin que chaque duplicata capture les nouveaux candidats. Un seul workflow d’audience à exécution longue est le mauvais outil ici.

Après ces trois migrations, l’équipe de rétention gère trois parcours contextuels au lieu de six (ou huit) déclencheurs autonomes. Le volume total de messages push reste à peu près le même. La sur-messagerie disparaît, car les critères de sortie et les branches de décision partagés arrêtent le workflow lorsque l’état de l’abonné ne correspond plus. L’analyse passe de « six tableaux de bord que je ne peux pas réconcilier » à « trois entonnoirs que je peux défendre ». C’est à quoi ressemblent les campagnes push déclenchées par événement lorsqu’elles arrivent à maturité.

Ce que les flux de travail contextuels font et que les déclencheurs autonomes ne peuvent pas faire

Quatre capacités existent à l’intérieur d’un workflow contextuel et ne peuvent pas être composées entre des déclencheurs autonomes. Chacune est une source réelle de revenus ou d’économies.

Critères de sortie inter-workflows. Un déclencheur autonome se déclenche lorsque l’événement se produit, point final. À l’intérieur d’un workflow, la règle de sortie se déclenche quel que soit le nœud où se trouve l’abonné. Le workflow d’abandon de panier se termine lors de l’achat. Le workflow de reconquête se termine lors de la réactivation. Le workflow de renouvellement se termine lors d’un renouvellement anticipé. Le déclencheur auquel personne n’a dit de s’arrêter est le workflow qui définit une règle de sortie.

Routage multi-canal dans un seul workflow. Avec des outils distincts à canal unique, « envoyer une notification push, puis un e-mail, et enfin WhatsApp » nécessite trois connexions à des fournisseurs, deux moteurs de segmentation et au moins un flux Zapier. À l’intérieur d’un moteur de workflow, il s’agit de trois nœuds ACTION avec deux nœuds DECISION entre eux, partageant une seule identité d’abonné et un seul ensemble de critères de sortie. Pour un traitement plus approfondi, consultez l’article sur l’orchestration des notifications push et des e-mails multi-canaux.

Heures de silence avec replanification comme solution de repli. Les notifications push qui arriveraient à 3 h du matin dans le fuseau horaire local de l’abonné seront retenues jusqu’à 8 h 01 si les heures de silence sont configurées avec reschedule comme solution de repli. L’alternative, skip, supprime silencieusement la notification et ne met pas à jour les analyses de notification pour l’action ignorée. Pour la plupart des équipes de rétention, reschedule est le bon choix par défaut, car les analyses supprimées signifient une attribution des revenus perdue. Les notifications push contextuelles qu’une équipe de rétention souhaite réellement envoyer respectent les fuseaux horaires des abonnés sans disparaître du funnel.

Chaînage de workflows. Les actions Workflow.Start et Workflow.Stop font de la progression du cycle de vie une véritable architecture. Le workflow de bienvenue se termine, ce qui démarre le workflow d’engagement. Le workflow de panier se termine lors de l’achat, ce qui démarre le workflow d’évaluation. Comparé à un dossier de déclencheurs qui se déclenchent tous indépendamment, il s’agit d’une machine à états : un graphe de workflows, chacun avec sa propre condition d’entrée, sa propre condition de sortie et son transfert vers l’étape suivante. Les déclencheurs ne se connaissent pas. Les workflows, si.

Analyses par flux de travail : comment lire l'entonnoir

Un workflow que vous ne pouvez pas défendre lors de la prochaine revue du compte de résultat est un workflow qui est supprimé. PushEngage Workflows suit trois chiffres à chaque nœud (queued_users, completed_users, exited_users) plus les totaux au niveau du workflow pour les entrées totales, les actifs actuels, les terminés et les sortis. Le travail du responsable de la rétention est de lire ce funnel et d’indiquer à la finance ce que chaque élément a produit.

Voici à quoi ressemblent les analyses au niveau des nœuds pour la chaîne panier-évaluation du Modèle 2 ci-dessus. Chiffres illustratifs, tirés d’une liste réaliste de 200 000 abonnés avec un taux d’abandon de panier mensuel de 6 %.

Nœud	En file d'attente	Terminé	Sorti	Notes
DÉMARRAGE (panier_abandonné)	0	12,400	320	320 abonnés ont correspondu aux critères de sortie au début du workflow (achetés entre l’événement panier et le scan du workflow)
ATTENDRE 1 heure	180	11,900	320	Profondeur de file d'attente normale
ACTION : rappel n°1	0	11,900	0	Envoyé
ATTENDRE 24 heures	240	9,800	1,860	1 860 abonnés ont acheté après le rappel n° 1 (sortie à l’objectif achat)
DÉCISION : panier toujours abandonné	0	9,800	0	Branche évaluée
ACTION : rappel n°2 (10%)	0	9,800	0	Envoyé
ATTENDRE 48 heures	90	6,300	3,410	3 410 abonnés ont acheté après le rappel n°2
ACTION : rappel final (20%)	0	6,300	0	Envoyé
FIN	N/A	6,300	N/A	6 300 abonnés n'ont pas acheté ; le workflow d'examen n'est pas enchaîné pour ceux-ci
Workflow.Start → workflow d'examen	N/A	5,270	N/A	Déclenché pour les 5 270 abonnés (1 860 + 3 410) qui ont acheté

Les 5 270 transferts en chaîne sont la nouvelle métrique que cette architecture met en évidence. Le workflow du panier a récupéré un taux de panier de 42,5 % (5 270 sur 12 400 entrés) et seuls ces 5 270 abonnés reçoivent le workflow de demande d'avis. L'ancienne architecture envoyait la demande d'avis à tous ceux qui avaient déjà acheté, y compris les abonnés qui n'avaient jamais abandonné de panier, les abonnés qui avaient retourné la commande et les abonnés qui avaient déjà soumis un avis. La correction architecturale est minime. Les économies sur la sur-messagerie sont importantes.

Deux modèles de goulots d'étranglement méritent d'être connus. Un nœud de sortie élevé (comme les deux nœuds WAIT ci-dessus) est le workflow qui fait son travail : les abonnés achètent pendant les fenêtres d'attente, les critères de sortie se déclenchent, le rappel suivant n'est jamais envoyé. Le modèle inverse, des sorties élevées aux nœuds d'action associées à des sorties faibles aux nœuds d'attente, signifie que le calendrier est erroné et que les attentes doivent être raccourcies. Un nœud de file d'attente élevée signifie un blocage pendant les heures calmes, une longue attente ou un délai de sonde en aval ; vérifiez la configuration du calendrier avant de supposer que le workflow est défectueux.

Pour un traitement plus approfondi de ces modèles spécifique au e-commerce, l'article compagnon sur cinq workflows de notifications push pour le e-commerce présente les parcours panier, navigation, post-achat, bienvenue et reconquête comme des parcours autonomes. Le hub des notifications push e-commerce couvre le paysage plus large des types de campagnes, la séquence de récupération d'abandon de panier présente le réglage de la cadence par plateforme, et l'aperçu des notifications push automatisées présente l'ancienne liste des types d'automatisation aux côtés de cette architecture de workflow.

La même forme d'analyse fonctionne dans tous les secteurs. Le SaaS a un entonnoir de renouvellement et une conversion d'essai à payant. Les éditeurs ont un entonnoir d'engagement d'articles et une ré-entrée dans les archives. Le voyage a un entonnoir de réservation et un flux d'alertes de baisse de prix. Les notifications push comportementales qu'une équipe SaaS utilise pour convertir les essais en payant ressemblent structurellement aux notifications qu'une équipe e-commerce utilise pour convertir les paniers en achats : un START sur un événement en temps réel, trois ou quatre étapes avec des branches de décision, des critères de sortie sur conversion, un transfert optionnel vers le workflow suivant. Le secteur modifie les noms des déclencheurs et le texte de l'offre. L'architecture reste.

Intégrez-le dans les Workflows PushEngage

Chacun des trois modèles de migration ci-dessus correspond directement aux composants des Workflows PushEngage.

Modèle	Types de nœuds utilisés	Types d'actions utilisés	Option de workflow	Point de départ de modèle suggéré
Consolidation de l'intégration	DÉMARRER, ATTENDRE, DÉCISION, ACTION, TERMINER	SendPushNotification, AddSegment	Type d'exécution : Unique	« Série de bienvenue avec branche de premier achat »
Chaîne panier-avis	DÉMARRER, ATTENDRE, DÉCISION, ACTION, TERMINER	SendPushNotification, Workflow.Start	Type d'exécution : Plusieurs parallèles ; critère de sortie Goal.Tracked = purchase	« Escalade d'abandon de panier »
Consolidation de la ré-engagement	START (audience), DÉCISION, ACTION, ATTENTE, FIN	SendPushNotification, AddSegment	Type d'exécution : Unique ; déclencheur d'audience ; duplication mensuelle	« Ré-engagement avec offre basée sur les niveaux »

Le moteur Workflows est livré avec plus de 60 modèles préconfigurés couvrant chacun des modèles de migration ci-dessus. Chaque modèle est un point de départ. Les modèles s'installent en moins de cinq minutes sur Shopify, Shopify Plus, WooCommerce, BigCommerce et Magento dans le générateur PushEngage Workflows, ou sur n'importe quelle pile SaaS, éditeur ou de voyage via le SDK JavaScript et l'API d'événements.

Le plan gratuit vous donne 200 abonnés, tous les canaux (web push, app push, WhatsApp et chat en direct), et le moteur Workflows complet dès le premier jour. C'est suffisant pour migrer l'un des trois modèles de votre pile de déclencheurs actuelle et prouver l'architecture avant de demander un budget. Commencez avec le plan gratuit et déployez le premier workflow contextuel en moins d'une heure.

Si vous retenez une chose de cet article, retenez ceci : une campagne de push déclenchée n'est plus la notification. C'est le workflow. Six déclencheurs autonomes fonctionnant de manière déconnectée sont six pipelines pointant vers la même liste d'abonnés, chacun ignorant les autres.

Trois workflows contextuels fonctionnant avec un état partagé, des branches de décision, des critères de sortie et des transferts en chaîne constituent un parcours par abonné, ramifié et délimité. Les workflows d'automatisation marketing qui produisent un entonnoir défendable par workflow et un taux d'achats répétés qui se compose ne sont pas une liste plus longue de déclencheurs ; ce sont un ensemble plus petit et plus précis de parcours contextuels. L'architecture est la campagne. Le déclencheur est la porte.