Connectez une boutique Shopify ou WooCommerce et le déclencheur panier abandonné d'un parcours se déclenche à partir d'un vrai événement de paiement commencé mais non terminé dans cette boutique. Sans source de données à maintenir, sans export manuel — juste un email de récupération qui part de lui-même au moment où un acheteur bloque.
L'autre article sur les paniers abandonnés de ce site suppose que vous alimentez déjà une source de données depuis là où vivent vos données de panier et que vous envoyez les emails de récupération manuellement ou selon une programmation récurrente. Celui-ci consiste à sauter tout cela : une boutique Shopify ou WooCommerce connectée synchronise directement ses propres clients et ses propres événements d'abandon de panier, et un parcours y réagit en temps réel.
Ce que connecter une boutique fait réellement
Depuis Paramètres → Intégrations, connecter Shopify vous guide à travers son écran OAuth ; WooCommerce se connecte avec une clé API REST générée sur votre propre site WordPress. Dans les deux cas, MailInApp enregistre des webhooks sur la boutique afin que les événements clients, paniers et commandes arrivent en direct plutôt que par sondage périodique. Une synchronisation initiale intègre les clients existants dans une liste de contacts liée à cette intégration ; tout ce qui se passe ensuite reste à jour uniquement via les webhooks.
Le déclencheur panier abandonné
Un parcours pointé vers le déclencheur panier abandonné d'une intégration connectée inscrit un contact quand cette boutique signale un paiement commencé mais non terminé, après un délai que vous choisissez. Shopify le signale nativement comme un vrai événement de paiement commencé. WooCommerce ne prend pas du tout en charge ce déclencheur pour l'instant — il n'existe aucun signal équivalent que MailInApp lit actuellement d'une boutique WooCommerce connectée, quels que soient les plugins d'abandon de panier que le site utilise, donc une intégration WooCommerce seule ne produira pas d'inscriptions par panier abandonné. Cela vaut la peine de le vérifier avant de construire tout un parcours autour de ça.
Ne rappelez pas quelqu'un qui a déjà payé
Un email de récupération envoyé à quelqu'un qui a déjà terminé son achat est pire qu'aucun email. Une étape objectif avant l'envoi vérifie si un achat est arrivé pour ce contact depuis l'abandon du panier, et sort du parcours immédiatement si c'est le cas. Le rappel ne se déclenche simplement jamais pour un panier qui n'est plus abandonné au moment où il partirait.
L'email de récupération lui-même
Rien dans l'email ne diffère de n'importe quel autre paiement MailInApp. Un bloc Produit montre un vrai bouton Acheter maintenant qui encaisse via votre propre compte Stripe connecté, et un Compte à rebours sur une réduction de récupération limitée dans le temps reste exact à l'ouverture plutôt que d'afficher une ligne obsolète « expire bientôt ». L'intégration écrit aussi la propre URL du panier abandonné sur la ligne du contact comme un champ de fusion, donc un Bouton peut renvoyer directement vers le panier lui-même comme alternative au paiement dans l'email. Ou basculez le propre champ Paiement du bloc Produit vers Lien vers le paiement d'une boutique externe pour qu'Acheter maintenant les renvoie directement vers ce panier, sans avoir besoin d'un bloc Bouton séparé.
Intention panier contre intention paiement — la répartition par étape
Une distinction clé introduite par la Répartition selon l'intention de MailInApp : abandon de panier et abandon de paiement sont désormais suivis séparément, chacun comme un déclencheur de parcours distinct avec son propre champ stage.
- Panier abandonné (
stage: "cart") — un article a été ajouté au panier d'une boutique externe connectée, mais l'acheteur est parti avant de commencer le paiement. Le bon message de récupération est généralement le renforcement des bénéfices : pourquoi ce produit, une preuve sociale, ou une relance légère. - Paiement abandonné (
stage: "checkout") — l'acheteur a atteint le processus de paiement Stripe du propre bloc Produit de MailInApp ou la propre page de paiement de la boutique (qu'il y soit arrivé via un simple lien ou via un bloc Produit configuré sur Lien vers le paiement d'une boutique externe) mais n'a pas terminé le paiement. Le bon message est la levée de friction : réponses aux questions fréquentes, signaux de confiance, un lien de support ou une réduction limitée dans le temps.
Les deux déclencheurs peuvent tourner comme des parcours séparés sur le même compte. Le champ stage figure aussi dans les charges utiles des webhooks et dans l'attribution des réponses, donc votre propre analytique peut distinguer les blocages de panier des abandons de paiement. Consultez Parcours pour la référence complète des déclencheurs.
Le revenu continue d'alimenter vos rapports existants
Là où une commande Shopify ou WooCommerce porte une attribution identifiable de campagne ou de variante, elle s'intègre dans les mêmes chiffres de revenu de réponses et de test A/B que produit déjà une commande de paiement natif dans l'email. Les ventes récupérées ne sont pas une surface de rapport séparée à consulter.
Un cas lié, mais distinct : récupérer un acheteur précédent
Panier abandonné concerne un paiement qui n'a jamais été terminé. Si vous voulez au contraire cibler des clients qui ont acheté — un produit spécifique, dans une plage de dates spécifique — et leur offrir une réduction pour qu'ils reviennent, consultez récupérez les acheteurs précédents avec des segments d'historique d'achat et des codes de réduction. Utilisez la même boutique connectée, mais un segment différent et un vrai code de réduction natif à la boutique plutôt qu'un déclencheur de parcours.
Comment démarrer
Connectez votre boutique depuis Paramètres → Intégrations, puis pointez le déclencheur d'un nouveau parcours vers l'événement panier abandonné de cette intégration avec le délai de votre choix. Ajoutez une étape objectif avant l'envoi pour sauter quiconque a déjà payé. Consultez Shopify, WooCommerce et Parcours pour la référence complète.