Automatisation des notifications push pour l'e-commerce : 5 modèles de flux de travail

C'est le troisième vendredi du trimestre et vous regardez votre tableau de bord de rétention. La séquence de panier abandonné est en cours. Le déclencheur d'abandon de navigation est en cours. La demande de révision post-achat est en cours. L'alerte de baisse de prix est en cours. Les notifications de bienvenue sont envoyées à chaque inscription. Six notifications push « automatisées ». Six déclencheurs connectés au cours des dix-huit derniers mois. Votre taux d'achats répétés a cessé d'évoluer il y a douze mois.

Voici à quoi ressemble l'automatisation des notifications push pour l'e-commerce dans la plupart des piles de rétention du marché intermédiaire : six déclencheurs déconnectés, chacun expédiant du contenu d'un propriétaire de campagne différent, aucun n'étant conscient des autres. La série d'abandons de panier continue d'envoyer des notifications aux abonnés qui ont déjà acheté. La campagne de reconquête chevauche l'alerte de baisse de prix pour le même client. Il n'y a pas de logique partagée, pas de critères de sortie partagés, pas d'identité partagée. Juste six tuyaux séparés, chacun pointant vers la même liste d'abonnés, chacun prétendant que les cinq autres n'existent pas.

L'automatisation des notifications push pour l'e-commerce ne devrait pas fonctionner ainsi. Elle devrait fonctionner comme une seule architecture de flux de travail : un ensemble de parcours multi-nœuds avec des déclencheurs partagés, une logique de décision partagée et des critères de sortie partagés, s'exécutant sur le push web, le push mobile, WhatsApp et le chat en direct à partir d'une seule identité d'abonné. Cet article explique à quoi ressemble cette architecture, propose cinq modèles complets de flux de travail que vous pouvez adopter, et montre comment lire l'entonnoir par flux de travail afin que la ligne budgétaire soit défendable auprès des finances.

La plupart des « notifications push automatisées » ne sont pas réellement automatisées

Le mot automatisation a fait beaucoup de travail non mérité sur le circuit des blogs d'e-commerce. Lorsque la plupart des articles disent « notifications push automatisées », ce qu'ils veulent dire, ce sont des « notifications push déclenchées » : des notifications uniques qui se déclenchent lorsqu'un événement se produit, sans état supplémentaire, sans attentes, sans branchements, sans conditions de sortie. Un abonné abandonne un panier, la notification d'abandon de panier se déclenche. Un abonné consulte un produit, la notification de navigation se déclenche. Un abonné achète, la notification post-achat se déclenche. Chaque déclencheur est son propre pipeline, ignorant tous les autres déclencheurs.

Un flux de travail est quelque chose de différent. Un flux de travail est un parcours en plusieurs étapes avec un état. Il sait où l'abonné est entré, où il se trouve actuellement, à quelle heure il est entré dans chaque nœud, et quelles conditions annulent le parcours. Le flux de travail d'abandon de panier ne se contente pas d'envoyer une notification à l'heure H. Il envoie à H, attend un jour, vérifie si le panier est toujours abandonné, envoie un deuxième contact avec une remise, attend deux jours supplémentaires, envoie un dernier contact, et sort du flux de travail au moment où l'abonné achète, quelle que soit l'étape sur laquelle il se trouvait.

Cette dernière clause fait la différence. Le déclencheur n'a pas de mémoire. Le flux de travail en a une. Si votre « automatisation de panier abandonné » continue d'envoyer des rappels après que le client a déjà payé, vous n'avez pas d'automatisation. Vous avez un déclencheur que personne n'a dit d'arrêter.

Pour une équipe de rétention e-commerce de taille moyenne, cette distinction fait la différence entre un taux d'achats répétés qui croît et un taux qui stagne. Six déclencheurs fonctionnant en parallèle produisent six canaux de bruit. Cinq workflows fonctionnant en coordination produisent un parcours par abonné, ramifié et délimité. La plupart des résultats de recherche de la première page pour ce mot-clé présentent le problème comme « quels types de notifications envoyer » et répondent avec une liste de neuf, douze ou quinze modèles. Ce n'est pas la question. La question est de savoir comment composer le parcours.

L'anatomie d'un workflow de notification push

Avant les plans, le vocabulaire. Un workflow de notification push est construit à partir de six types de nœuds. Une fois que vous savez ce que chacun fait, chaque plan de cet article se lit comme un diagramme, pas une description.

DÉMARRER. Le point d'entrée. Un nœud DÉMARRER définit comment le workflow est déclenché, soit par un événement d'abonné (panier abandonné, page consultée, segment rejoint, objectif d'achat suivi) soit par un filtre d'audience qui sélectionne les abonnés correspondant à des critères spécifiques à une heure programmée. Un workflow a exactement un DÉMARRAGE.

ATTENDRE. Un délai. Un nœud ATTENDRE maintient l'abonné à ce point pendant une durée spécifiée (minutes, heures, jours) ou jusqu'à une heure calendaire spécifique (mardi 10h dans le fuseau horaire de l'abonné, 15 décembre à 20h heure du site). Les attentes sont la façon dont un workflow apprend à ne pas être une diffusion unique.

DÉCISION. Une branche à deux voies. Un nœud DÉCISION vérifie une condition (l'abonné a-t-il acheté, est-il toujours dans le segment des abandonneurs de panier, son niveau de fidélité est-il « or ») et le dirige vers le chemin OUI ou le chemin NON. Les décisions sont la façon dont un workflow arrête de traiter tous les abonnés de la même manière.

DIVISER_CHEMIN. Une fourche basée sur un pourcentage. Les nœuds DIVISER_CHEMIN dirigent les abonnés sur plusieurs chemins en fonction de pourcentages configurés : 50/50 pour un test A/B, 33/33/34 pour un test de temps d'envoi à trois voies. Une fois que vous avez un gagnant, vous promouvez le chemin gagnant à 100 % et le workflow continue de fonctionner sur la variante éprouvée.

ACTION. Le travail lui-même. Les nœuds ACTION envoient une notification push, ajoutent l'abonné à un segment, mettent à jour ses attributs, déclenchent un webhook, démarrent un autre workflow ou en arrêtent un. Les Workflows PushEngage prennent en charge onze types d'actions. Les plus courants dans l'e-commerce sont SendPushNotification, AddSegment, UpdateAttribute et HttpRequest.

FIN / SORTIE. Le terminal. Les nœuds FIN et SORTIE marquent le workflow comme terminé et mettent à jour les analyses. FIN est la conclusion naturelle. SORTIE est généralement utilisé pour terminer tôt : sur le chemin NON d'un nœud Décision lorsque l'abonné ne remplit pas les conditions, ou sur une branche Split Path conçue comme groupe de contrôle.

Chaque workflow ci-dessous est composé de ces six éléments. Une fois le vocabulaire partagé, les plans se lisent rapidement.

Cinq plans de workflow pour l'e-commerce

Ce ne sont pas des « exemples ». Ce sont des plans de travail fonctionnels. Chacun liste son déclencheur, son type d'exécution, sa séquence de nœuds, ses critères de sortie et sa métrique de rétention prévue. Vous pouvez les importer directement dans le constructeur de Flux PushEngage et les faire fonctionner en moins d'une heure.

Plan de travail 1 — Série de bienvenue

• Déclencheur (DÉMARRAGE) : Événement PushEngage.Subscriber.Added
• Type d'exécution : Unique (un parcours de bienvenue par abonné, avec un délai de 90 jours avant la réadmission)
• Flux : Notification de bienvenue (immédiate) → ATTENDRE 2 jours → notification de mise en avant de fonctionnalité → ATTENDRE 3 jours → DÉCISION : l'abonné a-t-il effectué un achat ? → chemin OUI : envoyer une notification de remerciement et ajouter au segment clients → chemin NON : envoyer une remise sur le premier achat → FIN
• Critères de sortie : Aucun. Le parcours est suffisamment court pour que chaque abonné puisse le terminer.
• Métrique de rétention : Délai jusqu'au premier achat. Les nouveaux abonnés qui terminent la série de bienvenue achètent plus rapidement que ceux qui ne la terminent pas, car le troisième contact intervient au moment où l'intention d'un premier achat s'est matérialisée ou a stagné.

Plan de travail 2 — Abandon de navigation

• Déclencheur (DÉMARRAGE) : Événement personnalisé page_view filtré sur les pages de détails de produit où l'abonné n'a pas non plus déclenché add_to_cart dans les 30 minutes
• Type d'exécution : Plusieurs parallèles (un abonné peut abandonner la navigation sur plusieurs produits au cours d'une session, et chacun obtient sa propre instance de flux)
• Flux : ATTENDRE 30 minutes → DÉCISION : l'abonné navigue-t-il toujours sur le site ? → chemin OUI : FIN (ne pas interrompre une session active) → chemin NON : envoyer une notification de rappel avec le produit consulté → ATTENDRE 24 heures → DÉCISION : a-t-il ajouté au panier ? → chemin OUI : FIN (le flux d'abandon de panier prend le relais à partir d'ici) → chemin NON : envoyer un deuxième contact avec une recommandation de produits similaires → FIN
• Critères de sortie : Objectif add_to_cart (le flux de panier hérite du parcours) ou objectif purchase (plus de messages nécessaires)
• Métrique de rétention : Taux de conversion de la navigation au panier sur les produits précédemment consultés. L'article de blog PushEngage sur les campagnes d'abandon de navigation couvre le travail de segmentation dont hérite ce plan de travail.

Plan de travail 3 — Escalade d'abandon de panier

• Déclencheur (DÉMARRAGE) : Événement personnalisé cart_abandoned
• Type d'exécution : Plusieurs parallèles (chaque panier abandonné constitue son propre parcours, donc un abonné qui abandonne un deuxième panier alors que le premier est toujours actif obtient une deuxième instance simultanée)
• Flux : ATTENDRE 1 heure → rappel n°1 (pas de remise, ton amical) → ATTENDRE 24 heures → DÉCISION : le panier est-il toujours abandonné ? → chemin OUI : rappel n°2 avec une remise de 10 % → ATTENDRE 48 heures → DÉCISION : le panier est-il toujours abandonné ? → chemin OUI : dernier rappel avec une remise de 20 % et un cadre d'urgence → FIN
• Critères de sortie : Objectif purchase correspondant au cart_id de l’événement déclencheur. Au moment où l’abonné achète, le workflow s’annule pour ce panier, peu importe où il se trouve actuellement.
• Métriques de rétention : Valeur du panier récupérée par panier abandonné, par canal. C’est le workflow ayant le plus d’impact sur la page et le plus facile à justifier sur un compte de résultat. Pour une couverture plus approfondie de la séquence de récupération de panier abandonné spécifiquement, le guide PushEngage sur les paniers abandonnés explique comment la cadence est ajustée au comportement de la plateforme (les flux de paiement Shopify Plus diffèrent de WooCommerce d’une manière qui affecte la première attente).

Blueprint 4 — Demande d’avis post-achat

• Déclencheur (DÉMARRAGE) : Événement PushEngage.Goal.Tracked où goal_name = purchase
• Type d’exécution : Séquentiel multiple (un parcours de demande d’avis actif à la fois par abonné, mais le prochain achat déclenche une nouvelle instance)
• Flux : ATTENDRE 7 jours (assez longtemps pour recevoir le produit et se faire une opinion) → DIVISER LE PARCOURS 50/50 : envoi le matin (9h, heure locale de l’abonné) contre envoi le soir (19h, heure locale de l’abonné) → notification de demande d’avis → ACTION : requête HTTP vers le CRM enregistrant l’envoi de la demande d’avis → FIN
• Heures de silence : 22h à 8h dans le fuseau horaire de l’abonné, avec reschedule en secours. Les notifications push qui devraient arriver pendant la nuit attendent 8h01 plutôt que d’être envoyées. Le réglage reschedule est le bon défaut pour ce workflow car skip ignore silencieusement les notifications et les exclut des analyses, ce que la plupart des équipes de rétention ne souhaitent pas.
• Critères de sortie : Objectif review_submitted
• Métriques de rétention : Taux de soumission d’avis par variante d’heure d’envoi. La division du parcours rend le test A/B partie intégrante du workflow, et non une réflexion après coup attachée à un rapport de campagne.

Blueprint 5 — Réactivation

• Déclencheur (DÉMARRAGE) : Filtre d’audience last_active > 30 days
• Type d’exécution : Unique (une tentative de réactivation par abonné par fenêtre de 90 jours)
• Flux : Notification « Vous nous manquez » → ATTENDRE 3 jours → DÉCISION : l’abonné a-t-il interagi avec la notification ou visité le site ? → chemin OUI : ajouter au segment re-engaged, envoyer un remerciement et une réduction, FIN → chemin NON : envoyer une offre plus forte avec une réduction plus importante → ATTENDRE 5 jours → DÉCISION : toujours inactif ? → chemin OUI : notification finale « dernière chance » → FIN
• Critères de sortie : Filtre d’audience last_active < 7 days. L’abonné est redevenu actif de lui-même et le travail du workflow est terminé.
• Métriques de rétention : Taux de réactivation à 60 jours après l’entrée dans le workflow.

Un mot sur le déclencheur. C'est le seul modèle dans cet article qui utilise un déclencheur basé sur l'audience plutôt qu'un déclencheur basé sur un événement. Les déclencheurs d'audience dans les flux PushEngage traitent par lots l'ensemble des abonnés correspondants au moment du démarrage du flux uniquement. Les abonnés qui deviennent inactifs après le démarrage du flux ne sont pas inclus automatiquement, et la modification du filtre d'audience sur un flux actif n'ajoute pas de nouveaux abonnés. Si vous souhaitez un programme de réengagement continu, dupliquez le flux selon une planification récurrente (mensuelle ou trimestrielle) plutôt que d'attendre qu'un flux d'audience de longue durée continue d'ingérer de nouveaux candidats. C'est une source réelle de tickets de support « pourquoi cet abonné n'a-t-il pas reçu le message de reconquête ? » dans les équipes qui ne comprennent pas le type de déclencheur.

La segmentation, les tests A/B et les critères de sortie vivent à l'intérieur du flux

Le schéma dominant dans les résultats de recherche de la page 1 pour ce mot-clé est de lister la segmentation, les tests A/B et les heures de silence comme « meilleures pratiques » : des puces génériques à la fin de l'article, dissociées de la campagne qui les utilise. C'est le mauvais cadre. Ce ne sont pas des meilleures pratiques qui se situent à côté du flux. Ce sont le flux.

Voici le même ensemble de concepts, présentés comme des meilleures pratiques par rapport à des nœuds de flux :

Concept	Cadrage des meilleures pratiques (incorrect)	Cadrage des nœuds de flux (correct)
Segmentation RFM	« Segmentez votre liste avant d'envoyer »	Un nœud de DÉCISION qui vérifie la récence, la fréquence et la valeur monétaire, puis dirige les abonnés à RFM élevé vers un chemin différent de celui des abonnés à RFM faible. Le post de segmentation PushEngage couvre les définitions des groupes RFM qui alimentent ce nœud.
Tests A/B	« Testez toujours votre copie en A/B »	Un nœud SPLIT_PATH avec une allocation de pourcentage de 50/50, des abonnés répartis par chemin, et un champ winner_edge_id qui promeut le gagnant à 100 % une fois que le test atteint une signification
Heures de silence	« N'envoyez pas à 3h du matin »	Une option au niveau du flux avec start_at, end_at, timezone, et un paramètre fallback qui skip l'envoi ou le reschedule une minute après la fin des heures de silence
Critères de sortie	« Arrêtez d'envoyer aux personnes qui ont acheté »	Une règle au niveau du workflow qui vérifie l'abonné par rapport à un filtre d'audience ou un objectif déclenché avant chaque nœud, et annule le workflow si une correspondance est trouvée.

La différence est importante car les puces de meilleures pratiques sont faciles à approuver et difficiles à appliquer. Les nœuds de workflow sont appliqués par le moteur lui-même. Le DECISION s'exécute à chaque fois. Le SPLIT_PATH répartit chaque abonné. Le fallback des heures de silence s'active sans que personne ne se souvienne de vérifier l'heure. La règle de sortie annule le workflow, que le propriétaire de la campagne y prête attention ou non.

Pour le modèle d'abandon de panier ci-dessus, cela signifie qu'au moment où un abonné achète les articles abandonnés, la règle de sortie se déclenche, le flux est annulé pour cet abonné, et les deuxième et troisième rappels ne sont jamais envoyés. Pas de ticket de support, pas d'e-mail des finances, pas de campagne d'excuses. Le flux s'est arrêté parce que le moteur avait une règle qui lui disait de s'arrêter.

Orchestration multicanal : un flux, quatre canaux

La plupart des plateformes de notification push sont des outils à un canal. Certaines sont à deux canaux. La question à laquelle elles ne peuvent pas bien répondre est celle à laquelle une équipe de rétention du marché intermédiaire a réellement besoin de répondre : étant donné l'état de cet abonné, quel canal doit être activé ? Push web s'il s'est inscrit. E-mail s'il s'est désinscrit du push web. WhatsApp si la valeur du panier est supérieure à 200 $. Chat en direct si l'abonné est actuellement sur le site.

Cet arbre de décision est un flux de travail d'automatisation de notification push multicanal unique, et non quatre campagnes dans quatre outils. Avec les flux de travail PushEngage, un parcours d'abandon de panier peut se composer comme suit :

• DÉBUT : événement cart_abandoned
• ATTENDRE : 1 heure
• Nœud de DÉCISION 1 : l'abonné est-il abonné au push web ?
  • Chemin OUI : ACTION, envoyer un rappel push web
  • Chemin NON : continuer vers la prochaine décision
• ATTENDRE : 30 minutes après le push web (ou immédiatement, si aucun push n'a été envoyé)
• Nœud de DÉCISION 2 : l'abonné a-t-il cliqué sur le push web, ou n'est-il abonné à aucun push web ?
  • Si le push web a été envoyé et cliqué : SORTIR (laisser le flux du panier se terminer)
  • Si le push web a été envoyé et non cliqué, ou aucun push web : continuer
• Nœud de DÉCISION 3 : valeur du panier supérieure à 200 $ ?
  • Chemin OUI : ACTION, envoyer un message WhatsApp via l'action SendPushNotification sur le canal WhatsApp
  • Chemin NON : ACTION, envoyer un e-mail via une requête HTTP à votre ESP
• SORTIR sur l'objectif purchase

Quatre canaux, un flux de travail, un ensemble de critères de sortie, une identité d'abonné. Le même responsable de la rétention qui ne pouvait auparavant orchestrer cela sans trois connexions fournisseurs et un flux Zapier peut maintenant le composer dans un seul flux de travail que le moteur applique.

Faire la même chose dans des outils distincts signifie six synchronisations entre plateformes, deux moteurs de segmentation qui ne sont pas d'accord sur qui compte comme un « abonné VIP », et aucune attribution unique des revenus car chaque outil rapporte ses propres conversions. Le faire au sein d'un moteur de flux de travail signifie une identité d'abonné, un ensemble de logique de décision et un rapport d'entonnoir. Pour en savoir plus sur la façon dont le push et l'e-mail fonctionnent ensemble dans un plan de rétention unique, consultez l'orchestration multicanal push et e-mail.

C'est le différenciateur qui n'a pas d'analogue dans les résultats dominants de la page un. Aucun des quinze premiers résultats pour ce mot-clé ne décrit un flux de travail inter-canaux comme un objet unique. Ils traitent tous le push comme le sujet et l'e-mail comme la comparaison.

Les mathématiques de la rétention : revenus par flux de travail, par canal, par notification

Un flux de travail que vous ne pouvez pas défendre lors de la prochaine revue du compte de résultat sera supprimé. Le travail du responsable de la rétention est de montrer, en dollars, ce que chaque poste a produit. La plupart des articles sur les « notifications push automatisées pour l'e-commerce » s'arrêtent au taux de clics. Ce n'est pas suffisant. La bonne métrique est le revenu récupéré par abonné, par flux de travail, par canal.

Les Workflows PushEngage suivent trois chiffres à chaque nœud :

• Utilisateurs mis en file d'attente : abonnés attendant actuellement à ce nœud (typiquement un WAIT ou une reprogrammation en heures calmes)
• Utilisateurs terminés : abonnés qui ont passé ce nœud
• Utilisateurs sortis : abonnés qui ont quitté le flux de travail à ce nœud, soit parce que les critères de sortie correspondaient, soit parce qu'ils se sont désabonnés

Voici à quoi ressemblent les analyses au niveau des nœuds pour un flux de travail actif d'abandon de panier (chiffres illustratifs, tirés d'une liste réaliste de 200 000 abonnés) :

Nœud	En file d'attente	Terminé	Sorti	Notes
DÉMARRAGE (panier_abandonné)	0	12,400	320	320 abonnés correspondaient aux critères de sortie au début du flux de travail (achetés entre l'événement panier et le scan du flux de travail)
ATTENDRE 1 heure	180	11,900	320	Profondeur de file d'attente normale
ACTION : rappel n°1	0	11,900	0	Notification envoyée
ATTENDRE 24 heures	240	9,800	1,860	Nombre élevé de sorties : 1 860 abonnés ont acheté après le rappel n°1
DÉCISION : panier toujours abandonné	0	9,800	0	Tous les abonnés restants ont toujours le panier ouvert
ACTION : rappel n°2 (10 % de réduction)	0	9,800	0	Notification envoyée avec une réduction
ATTENDRE 48 heures	90	6,300	3,410	3 410 autres achats ont déclenché une sortie
ACTION : rappel final (20 % de réduction)	0	6,300	0	Notification finale
FIN	N/A	6,300	N/A	6 300 abonnés n'ont pas acheté

Dans ce tunnel, 5 270 abonnés (1 860 + 3 410) ont acheté pendant le workflow, soit un taux de récupération de panier de 42,5 %. Les deux attentes (24h et 48h) sont les nœuds de sortie les plus importants du tunnel, ce qui correspond au schéma attendu : les décisions d'achat se prennent pendant les fenêtres d'attente, pas pendant les fenêtres d'action. Si votre workflow présente le schéma inverse, avec des sorties importantes aux nœuds d'action et des sorties faibles aux nœuds d'attente, votre calendrier est erroné et les attentes devraient être raccourcies.

Les calculs de rétention doivent également tenir compte des coûts. Les notifications push ne coûtent rien par envoi une fois que l'abonné a donné son accord. Les coûts d'envoi d'e-mails dépendent de votre ESP, mais pour une liste de 200 000 abonnés avec une configuration typique de Klaviyo ou Bloomreach, un seul envoi d'abandon de panier coûte plusieurs centaines de dollars en utilisation mesurée (les conditions de votre contrat s'appliquent).

Une automatisation de notification push d'abandon de panier axée sur le push qui récupère les paniers à 42 % peut atteindre le même chiffre de revenus récupérés qu'un workflow push et e-mail à 38 %, à un coût matériellement inférieur. Faites le calcul pour votre propre taille de liste et votre contrat ESP. L'idée est que le push, le push d'application et WhatsApp n'entraînent pas le coût par envoi que l'e-mail entraîne, et le rôle du workflow est d'utiliser le canal le moins cher en premier chaque fois que l'état de l'abonné le permet.

Lorsque la ligne d'article est défendable (ce workflow a récupéré X $ de paniers pour un coût tout compris de Y $), la conversation budgétaire est courte.

Intégrez-le dans les Workflows PushEngage

Chaque modèle de cet article correspond directement aux composants des Workflows PushEngage. Voici la correspondance pour les cinq modèles ci-dessus :

Modèle	Types de nœuds utilisés	Types d'actions utilisés	Option de workflow
Série de bienvenue	DÉMARRER, ATTENDRE, DÉCISION, ACTION, TERMINER	SendPushNotification, AddSegment	Type d'exécution : Unique
Abandon de navigation	DÉMARRER, ATTENDRE, DÉCISION, ACTION, SORTIR	SendPushNotification	Type d'exécution : Plusieurs parallèles
Escalade d'abandon de panier	DÉMARRER, ATTENDRE, DÉCISION, ACTION, TERMINER	SendPushNotification	Type d'exécution : Plusieurs parallèles ; sortie à l'objectif achat
Demande d'avis post-achat	DÉMARRER, ATTENDRE, DIVISER_CHEMIN, ACTION, TERMINER	SendPushNotification, HttpRequest	Type d'exécution : Plusieurs séquentielles ; heures calmes 22h – 8h, report de secours
Réactivation	DÉMARRER, ACTION, ATTENDRE, DÉCISION, TERMINER	SendPushNotification, AddSegment	Type d'exécution : Unique ; déclencheur basé sur l'audience

Le moteur Workflows est livré avec plus de 60 modèles préconfigurés couvrant chacun de ces flux. Chaque modèle est un point de départ. Chaque modèle ci-dessus peut être installé en moins de cinq minutes sur Shopify, Shopify Plus, WooCommerce, BigCommerce ou Magento dans le constructeur de workflows de notifications push PushEngage.

La fonctionnalité Workflows couvre également la logique de décision et les étapes de personnalisation qui rendent possible le routage multicanal de la section précédente, et prend en charge les onze types d'actions qui vous permettent de faire plus que simplement envoyer une notification : mettre à jour les attributs des abonnés, déclencher des webhooks vers votre CRM, démarrer des workflows en aval ou arrêter ceux qui sont conflictuels.

Pour une vue plus large de la façon dont ces workflows s'intègrent dans un programme de rétention e-commerce complet, l'article hub des notifications push e-commerce couvre les types de campagnes que ces modèles implémentent.

Le forfait gratuit vous donne 200 abonnés, les quatre canaux (web push, app push, WhatsApp et live chat), et le moteur complet Workflows dès le premier jour. C'est suffisant pour prouver le canal avant de le budgétiser.

Ce que cela change

Si vous retenez une chose de cet article, retenez ceci : l'automatisation des notifications push pour l'e-commerce est une architecture de flux de travail, pas un ensemble de campagnes déclenchées. Le parcours d'abandon de panier qui se termine par un achat, la série de bienvenue qui se ramifie en fonction du comportement lors du premier achat, et l'orchestration inter-canaux qui choisit le canal le moins cher viable pour chaque abonné ont tous la même forme.

Un DÉMARRAGE, quelques ATTENTES, quelques DÉCISIONS, quelques ACTIONS, une SORTIE. Six déclencheurs autonomes ne peuvent pas faire cela. Un moteur de flux de travail le peut. Les mathématiques de rétention se composent à partir de là.

Commencez avec le forfait gratuit pour expédier le premier blueprint en moins d'une heure.