PS PrestaShop Intermédiaire

Relance Panier Abandonné Multi-étapes : guide complet

Installer, configurer et exploiter la relance des paniers abandonnés : séquences d'emails multi-étapes à l'image de votre boutique, bons de réduction escaladés, restauration du panier en un clic, ciblage et statistiques par étape pour PrestaShop 8 et 9.

Mis à jour Version du module 1.3.5

Présentation

Le module Relance Panier Abandonné Multi-étapes (datafireflycartrecovery) détecte les paniers abandonnés et relance vos clients par une séquence d’emails programmés. Chaque étape a son délai, son contenu par langue et un bon de réduction optionnel dont l’incitation peut augmenter d’une étape à l’autre. Un lien signé permet au client de retrouver son panier en un clic, bon déjà appliqué, et le tableau de bord mesure le chiffre d’affaires réellement récupéré, étape par étape.

En moyenne, près de 7 paniers sur 10 sont abandonnés avant le paiement. Une séquence bien réglée (un rappel simple, puis une remise modérée, puis une offre plus forte avec livraison offerte) récupère une part de ce chiffre d’affaires sans effort manuel.

Compatibilité

  • PrestaShop 8.0 à 9.x
  • PHP 8.1 à 8.3
  • Mono-boutique et multi-boutique (campagnes, paniers et statistiques séparés par boutique)
  • Interface : FR, EN, ES, DE, IT, PL
  • Gabarits email : FR, EN, ES, DE, IT, PL, NL. Toute autre langue installée reçoit automatiquement une copie modifiable du gabarit anglais.
  • Compatible avec le module RGPD officiel psgdpr
  • Architecture PSR-4 sans Composer, aucune dépendance externe

Installation

  1. Dans le back-office, ouvrez Modules > Gestionnaire de modules.
  2. Cliquez sur Installer un module et sélectionnez datafireflycartrecovery.zip.
  3. Cliquez sur Configurer pour régler les paramètres généraux et l’apparence des emails.
  4. Configurez la tâche planifiée (section suivante), puis envoyez-vous un email de test depuis une étape.

L’installation crée les tables du module, enregistre ses hooks, ajoute l’onglet Relance panier et une campagne par défaut à trois étapes : +1 h (rappel simple), +24 h (bon de -5 %) et +72 h (bon de -10 % et livraison offerte).

Mise à jour depuis une version précédente

Téléversez le nouveau ZIP : les scripts de mise à jour s’exécutent automatiquement.

  • Vers 1.3.5 : le bon de relance ne se cumule plus avec un autre code promo. Le script enregistre deux nouveaux hooks. Aucune modification de la base de données.
  • Vers 1.3.4 : corrige une page blanche « If no employee is assigned in the context, cart ID must be provided to this method » quand un panier est enregistré hors navigation (webservice, connecteur, webhook de paiement, script), le bouton « Envoyer maintenant » hors fenêtre d’envoi et un décalage des échéances quand le serveur MySQL n’utilise pas le fuseau de la boutique. Aucune modification de la base de données.
  • Vers 1.3.1 : correction de l’erreur 500 de l’URL cron sur PrestaShop 8. Aucune modification de la base de données.
  • Vers 1.3.0 : ajout du ciblage par groupes et catégories et des réglages d’apparence. Les emails passent en en-tête blanc avec le logo de la boutique, le bleu d’origine reste la couleur d’accent. Ajustez si besoin dans Apparence des emails.
  • Vers 1.2.0 : enregistrement des nouveaux hooks (RGPD, en-têtes email, ajout de langue) et création des gabarits email manquants pour les langues installées.

Si votre boutique était en 1.1.0, la mise à jour requalifie les paniers comptés à tort comme récupérés (commandes passées sans aucun email de relance). Le CA récupéré affiché baisse : c’est le chiffre correct. Testez la mise à jour sur une préproduction avant la production.

Tâche planifiée (cron)

Le module fonctionne par passages réguliers, déclenchés par une URL sécurisée par jeton. À chaque passage :

  1. Scan : les paniers inactifs depuis le délai d’abandon sont qualifiés (ciblage, anti-répétition) et leurs étapes planifiées.
  2. Envoi : les emails dus partent en respectant tous les garde-fous.
  3. Nettoyage : les bons du module expirés depuis 7 jours et jamais utilisés sont supprimés.

L’URL exacte, avec son jeton, s’affiche sur le tableau de bord (bouton Configurer, avec copie en un clic) et dans la configuration du module :

https://VOTRE-BOUTIQUE/index.php?fc=module&module=datafireflycartrecovery&controller=cron&token=LE_JETON

Programmez un appel toutes les 10 minutes environ :

*/10 * * * * curl -s "https://VOTRE-BOUTIQUE/index.php?fc=module&module=datafireflycartrecovery&controller=cron&token=LE_JETON" >/dev/null 2>&1

Un verrou garantit qu’un seul passage tourne à la fois : deux appels simultanés n’envoient jamais deux fois le même email.

État du traitement

Le haut du tableau de bord indique l’état du traitement planifié : vert si le dernier passage date de moins de 30 minutes, orange jusqu’à 3 heures, rouge au-delà ou s’il n’a jamais tourné. Le bouton Lancer maintenant exécute un passage immédiatement et affiche son résultat : paniers détectés, emails envoyés, emails reportés hors fenêtre d’envoi, échecs.

Sans accès aux tâches cron

Activez Exécution sans cron serveur dans la configuration du module. Le traitement est alors déclenché par les visites de la boutique, au plus toutes les 10 minutes, après l’envoi de la page au visiteur : la navigation n’est pas ralentie.

Cette option dépend du trafic : une boutique sans visite la nuit n’enverra rien avant la première visite du matin. Un vrai cron reste plus fiable. Ne diffusez pas le jeton de l’URL cron.

Réglages généraux

  • Délai d’abandon (60 min par défaut) : inactivité au-delà de laquelle un panier est considéré comme abandonné.
  • Emails par exécution (50 par défaut) : nombre d’emails traités à chaque passage.
  • Emails max par panier (3 par défaut) : plafond toutes étapes confondues, 0 pour aucun plafond.
  • Durée de vie max (30 jours par défaut) : au-delà, un panier non converti passe en statut Perdu.
  • Auto-connexion via le lien (activée par défaut) : reconnecte le client enregistré qui clique sur le lien de restauration, pendant 7 jours après l’envoi de l’email.
  • Email et nom d’expéditeur : vides, ceux de la boutique sont utilisés.
  • Exécution sans cron serveur : voir la section précédente.

Apparence des emails

Dans la configuration du module, le bloc Apparence des emails aligne les relances sur votre identité visuelle :

  • Logo de la boutique : utilise le logo des emails défini dans Apparence > Thème et logo, sinon le logo principal. Ses dimensions sont calculées pour un affichage correct dans Outlook. Sans logo, le nom de la boutique s’affiche.
  • Couleur d’accent : bouton, liens, filet sous l’en-tête et bloc du code promo.
  • Fond de l’en-tête : blanc conseillé si votre logo est foncé.

Le texte posé sur ces couleurs passe automatiquement en blanc ou en foncé selon le contraste : un bouton jaune reçoit un texte foncé, un bouton bleu nuit un texte blanc. Le résultat est visible dans l’aperçu de chaque étape.

Campagnes et ciblage

Une campagne regroupe une séquence d’étapes et ses règles. L’écran d’une campagne affiche ses réglages et, en dessous, la liste de ses étapes.

  • Montant minimum du panier : 0 pour aucun minimum.
  • Fenêtre d’envoi : plage horaire hors de laquelle les emails dus sont reportés (la fenêtre peut traverser minuit).
  • Anti-répétition (en jours) : un destinataire qui a reçu une relance pour un autre panier pendant cette période n’est pas relancé.
  • Cibler les invités : inclut ou non les clients invités.
  • Exclure les comptes B2B : exclut les clients dont la société, le SIRET ou le numéro de TVA sont renseignés.
  • Groupes clients exclus : aucun email pour les clients appartenant à l’un de ces groupes (revendeurs, personnel).
  • Catégories exclues : un panier contenant au moins un produit de ces catégories n’est pas relancé (cartes cadeaux, produits à marge faible, produits sur ordonnance). Un champ de recherche filtre l’arborescence.

Étapes de la séquence

  • Position : ordre de l’étape.
  • Délai après abandon (en minutes) : 60 = 1 h, 1440 = 24 h, 4320 = 72 h.
  • Objet, texte du bouton et corps par langue : le corps se rédige dans un éditeur visuel. Laissé vide, le texte du bouton prend un libellé par défaut traduit.
  • Étape active : suspend une étape sans la supprimer.

Variables

Utilisables dans l’objet, le texte du bouton et le corps. Un clic sur une variable la copie.

  • {firstname}, {lastname} : prénom et nom du client.
  • {shop_name} : nom de la boutique.
  • {cart_total} : total du panier dans sa devise.
  • {voucher_code}, {voucher_value}, {voucher_expiry} : code, valeur (par exemple 10 % ou 5,00 €) et date d’expiration du bon. Vides si l’étape ne génère pas de bon.

Le corps est inséré dans un gabarit responsive qui ajoute l’en-tête, le récapitulatif du panier (photos, déclinaisons, total), le bloc du code promo, le bouton et le pied de page avec le lien de désinscription. Une version texte propre est générée pour les messageries qui n’affichent pas le HTML.

Aperçu et email de test

Une fois l’étape enregistrée :

  • Le bouton Aperçu de chaque onglet de langue (ou l’icône œil dans la liste des étapes) ouvre le rendu final, avec une bascule bureau / mobile.
  • Le bloc Envoyer un email de test envoie l’étape à l’adresse et dans la langue de votre choix. L’objet est préfixé par [TEST].

L’aperçu et le test utilisent la version enregistrée de l’étape et le panier réel le plus récent de la boutique, avec le code fictif DFCR-TEST42. Aucun bon n’est créé, aucune statistique n’est modifiée, et le lien du bouton mène à la page panier sans restaurer le panier d’un client.

Bons de réduction

Chaque étape peut générer un bon au moment de l’envoi :

  • Type : pourcentage ou montant fixe (TTC ou HT).
  • Valeur et montant minimum d’application.
  • Validité en jours.
  • Livraison offerte, seule ou combinée à la remise.
  • Le bon est à usage unique et limité dans le temps. Il est nominatif pour les clients enregistrés. Pour les invités, il n’est pas lié au compte, car PrestaShop recrée un compte invité à chaque commande : le code reste secret et utilisable une seule fois.
  • Pas de cumul avec un autre code promo : si le client saisit un autre code alors qu’un bon de relance est dans le panier, ou l’inverse, l’ajout est refusé avec le message « Ce code promo ne peut pas être cumulé avec un autre code promo. » et le code déjà présent est conservé. Les règles panier automatiques sans code (livraison offerte dès X €, par exemple) restent cumulables.
  • Escalade sans cumul : quand une nouvelle étape génère un bon, le bon précédent encore inutilisé du même panier est désactivé.
  • Nettoyage : les bons expirés depuis 7 jours et jamais utilisés sont supprimés automatiquement.

Bonne pratique : aucune remise à la première étape, puis une escalade progressive (-5 %, puis -10 % et livraison offerte). Le tableau de bord indique le CA attribué à chaque étape : vous voyez si la remise la plus forte rapporte plus qu’elle ne coûte.

Restauration du panier en un clic

Chaque email contient un lien signé (HMAC). Au clic :

  • le panier est reconstitué et le client arrive sur sa page panier ;
  • le bon de l’email cliqué est appliqué automatiquement (un éventuel bon de relance précédent est retiré), sauf si le panier contient déjà un autre code promo : celui du client est alors conservé ;
  • le client enregistré est reconnecté si l’option est active et que l’email date de moins de 7 jours ; l’adresse choisie dans le panier est conservée ;
  • le clic est comptabilisé.

Toute modification des paramètres du lien l’invalide. Un panier déjà commandé renvoie vers l’accueil. Si un autre client est connecté dans le navigateur, sa session et son panier ne sont pas modifiés et le panier de l’email n’est pas restauré.

Déroulement d’une séquence

  • Reprise : si le client revient modifier son panier, les relances en attente sont suspendues. S’il repart, la séquence reprend à l’étape suivante, sans renvoyer une étape déjà reçue.
  • Paniers anciens : un panier inactif depuis plus de 7 jours n’est jamais relancé. Après un arrêt prolongé du cron, le premier passage n’écrit donc pas à des clients partis depuis des semaines. Si le client revient sur son panier, il redevient éligible.
  • Produits indisponibles : si plus aucun produit du panier n’est commandable (rupture sans commande autorisée, produit désactivé), l’étape est ignorée. Les étapes suivantes restent planifiées en cas de réassort.
  • Échec d’envoi : en cas d’erreur SMTP, l’email est retenté 15 puis 30 minutes plus tard. Après 3 échecs, il passe en échec avec le message d’erreur, et le bon créé est supprimé.
  • Commande : à la validation d’une commande, les relances restantes sont annulées.

Suivi et attribution

  • Ouvertures : pixel invisible dans chaque email.
  • Clics : clic sur le bouton ou le lien de restauration.
  • Récupération : un panier est compté Récupéré uniquement si au moins un email de relance a été envoyé avant la commande. Une commande passée avant tout email prend le statut Commandé sans relance et n’entre pas dans le CA récupéré.
  • Attribution par étape : chaque panier récupéré est attribué au dernier email envoyé avant l’achat.

Tableau de bord

  • Période : 7, 30 ou 90 jours.
  • Indicateurs : paniers détectés et valeur abandonnée, paniers récupérés et taux de récupération, emails envoyés, taux d’ouverture et de clic, emails en attente d’envoi, CA récupéré.
  • Graphique des détections et récupérations jour par jour.
  • Performance par étape de la campagne active : envoyés, ouverts, cliqués, taux de clic, paniers récupérés et CA attribué.

Paniers suivis

L’onglet Paniers liste les paniers suivis avec filtre par statut, recherche (email, nom ou numéro de panier), pagination et export CSV des résultats filtrés. Chaque ligne donne le client, le montant, le statut, le nombre d’emails envoyés et planifiés, un lien vers le panier et, le cas échéant, vers la commande dans le back-office. L’icône d’exclusion arrête toute relance pour un panier.

Statut Signification
Actif Panier en cours, pas encore abandonné
Relance en cours Séquence planifiée ou en cours d’envoi
Récupéré Commande passée après au moins un email de relance
Commandé sans relance Commande passée avant tout email, non attribuée
Perdu Séquence terminée ou durée de suivi dépassée
Exclu Filtré par la campagne (montant, invité, B2B, groupe, catégorie, anti-répétition) ou exclu manuellement
Désinscrit Le client ne souhaite plus recevoir de relances

Journal des envois

L’onglet Journal des envois détaille chaque email : date prévue et date d’envoi, destinataire, étape, statut (planifié, envoyé, ignoré, annulé, en échec), ouverture, clic, code promo et motif (client revenu sur son panier, plafond atteint, produits indisponibles, erreur SMTP…). Pour un email planifié, vous pouvez l’envoyer maintenant ou l’annuler. « Envoyer maintenant » envoie l’email immédiatement, même hors de la fenêtre d’envoi, et affiche le résultat ou la raison du non-envoi.

RGPD et délivrabilité

  • Chaque email contient un lien de désinscription. L’adresse rejoint une liste de suppression persistante et les envois en attente sont annulés.
  • Les en-têtes List-Unsubscribe et List-Unsubscribe-Post permettent la désinscription en un clic depuis Gmail, Yahoo et les autres messageries qui l’exigent pour les emails marketing.
  • Seuls les paniers liés à une adresse email (client ou invité ayant validé l’étape informations personnelles) sont suivis : aucune adresse n’est capturée avant validation par le client.
  • Avec le module officiel psgdpr, le module apparaît dans la liste des modules traitant des données : l’export et la suppression des données d’un client couvrent ses paniers suivis et ses emails de relance.
  • La suppression d’un compte client efface ses paniers suivis, sa file d’envoi et ses événements. Son éventuelle opposition reste dans la liste de suppression.
  • La désinstallation supprime les tables, la configuration et l’onglet d’administration.

FAQ et dépannage

Aucune relance ne part

Regardez l’état du traitement en haut du tableau de bord. S’il est rouge, la tâche cron n’appelle pas l’URL (ou pas avec le bon jeton) : utilisez Lancer maintenant pour vérifier, puis corrigez la tâche ou activez l’exécution sans cron serveur. Vérifiez ensuite que la campagne et au moins une étape sont actives, que l’heure est dans la fenêtre d’envoi, et consultez le Journal des envois : le motif de chaque email ignoré ou en échec y figure.

Le client ne peut pas ajouter son code promo

C’est voulu : le bon de relance ne se cumule avec aucun autre code promo. Le client doit d’abord retirer le code présent dans son panier, puis saisir l’autre. Les règles automatiques sans code ne sont pas concernées.

Page blanche « If no employee is assigned in the context, cart ID must be provided to this method »

Ce message du cœur PrestaShop pouvait apparaître avec les versions 1.0.0 à 1.3.1 quand un panier était enregistré hors navigation (webservice, connecteur, webhook de paiement, script). Mettez à jour en 1.3.4 ou supérieure.

L’URL cron renvoie une erreur 500

Sur PrestaShop 8, les versions 1.0.0 à 1.3.0 provoquaient une erreur 500 sur l’URL cron. Mettez à jour en 1.3.1 ou supérieure et vérifiez la version affichée dans le gestionnaire de modules. Si l’erreur persiste, activez le mode debug de PrestaShop ou consultez les logs PHP du serveur pour lire le message exact.

Un panier n’apparaît pas dans la liste

Un panier n’est suivi que lorsqu’il est associé à une adresse email : client connecté, ou invité ayant validé l’étape informations personnelles. Il devient abandonné après le délai d’abandon (60 minutes par défaut) et au passage suivant du cron.

Mon logo n’apparaît pas ou est illisible

Vérifiez que l’option Logo de la boutique est active et qu’un logo est défini dans Apparence > Thème et logo. Si votre logo est foncé, choisissez un fond d’en-tête clair. Certaines messageries bloquent les images par défaut : le nom de la boutique s’affiche alors à la place.

L’email de test n’arrive pas

Vérifiez que l’étape a un objet dans la langue choisie et que l’envoi d’emails de la boutique fonctionne (Paramètres avancés > Email, bouton d’envoi de test PrestaShop). Consultez aussi vos courriers indésirables.

Un client peut-il recevoir trop d’emails ?

Non : le plafond d’emails par panier, l’anti-répétition par destinataire et la fenêtre d’envoi encadrent la fréquence. Une commande ou une désinscription annule les relances restantes.

Le module est-il compatible multi-boutique ?

Oui. Campagnes, paniers suivis, réglages d’apparence et statistiques sont séparés par boutique.

Est-ce compatible PrestaShop 9 ?

Oui. Le module est compatible avec PrestaShop 8 et 9 et suit les changements d’API de PS9 (formatage des prix via l’API Locale, contrôleurs, envoi des emails).

Cette page vous a-t-elle été utile ?

Toujours bloqué ? Contactez le support