Email marketing PrestaShop : consentement, relance et messages de commande

Ce que nous ferions

Nous partirions de votre boutique actuelle et du prochain message nécessaire. Conservez un expéditeur et une plateforme fonctionnels, sauf si une capacité manquante ou un défaut reproductible justifie leur remplacement. Vérifiez vos versions de PrestaShop et PHP, modules installés, tunnel de commande, thème, preuves de consentement, états de commande, intégrations, langues et marchés. Convenez des personnes qui approuveront les campagnes, traiteront les réponses et examineront les échecs.

Si les confirmations de commande sont peu fiables, réparez d'abord ce circuit d'envoi. Si vous avez une liste autorisée mais pas d'événements d'achat fiables, commencez par un message de bienvenue ou une newsletter vérifiée. Ne choisissez la relance de panier que si l'identité, l'éligibilité, la restauration et l'arrêt après achat sont démontrés. Un catalogue ou une audience plus grands ne justifient pas seuls une plateforme plus complexe.

Effectuez tout changement justifié de connecteur ou d'expéditeur sur une copie de préproduction isolée avec le thème, les modules et les données pertinentes de production. Désactivez les envois clients, tâches marketing externes et exports de préparation avant les tests ; un intercepteur d'emails de boutique ne peut pas capter les envois API d'une plateforme distincte. Utilisez des contacts contrôlés et un compte de test si possible. Répétez les scénarios d'inscription, achat, retrait et nouvelle tentative avant de planifier la bascule, en consignant la configuration précédente et les étapes de retour arrière.

Pour configurer le module choisi et vérifier le parcours convenu, le service PrestaShop Module Installation & Configuration Service couvre un module existant ; licences, modules supplémentaires et développement sont distincts.

Distinguer les emails opérationnels du marketing

L’email vous permet de conserver une audience transférable, sous réserve des autorisations, des conditions des prestataires et des contrôles de délivrabilité. Il dépend toujours des expéditeurs, des fournisseurs de messagerie et de la réputation. Ce n’est pas automatiquement votre canal le moins cher ou le plus rentable.

PrestaShop envoie des messages opérationnels comme les emails de compte et de mot de passe, les confirmations de commande et les notifications de statut. Le module de collecte des inscriptions à la newsletter ne fournit ni éditeur de campagnes, ni moteur de segmentation, ni scénarios marketing à plusieurs étapes décrits ici. Ceux-ci nécessitent une extension adaptée, une plateforme externe ou une intégration personnalisée.

Choisissez un message utile et prouvez ses circuits de données et d'envoi avant d'élargir. Coordonnez newsletters, offres de fidélité, parrainage et assistance pour éviter les messages contradictoires ou excessifs à une même personne. Examinez votre tunnel de commande séparément si des coûts imprévus ou problèmes techniques provoquent des abandons.

Comprendre la collecte des inscriptions et les données enregistrées

Les versions des modules comptent indépendamment de celle de la boutique. Les anciennes installations PrestaShop 1.6 utilisent couramment blocknewsletter et une table de base de données dont le suffixe est newsletter. Les installations ultérieures utilisent ps_emailsubscription, avec une table d’invités dont le suffixe est emailsubscription. Inspectez le module installé et le schéma avant l’export.

Avec le préfixe standard ps_, ps_ plus emailsubscription donne ps_emailsubscription. Ce nom de table est valide ; n’ajoutez pas un autre ps_ simplement parce que le module porte ce nom.

Les abonnés invités et les clients inscrits peuvent être stockés séparément. L’état d’inscription à la newsletter des clients inscrits figure dans leur fiche. La table des invités peut contenir l’email, l’état actif, la date d’inscription, l’IP d’inscription, les informations de provenance et le contexte de boutique. Son référent peut provenir des données de connexion et ne constitue pas un enregistrement fiable de la page du formulaire.

L’export ps_emailsubscription peut inclure les clients inscrits et les abonnés invités, selon ses filtres. Un exporteur ou connecteur personnalisé doit aussi couvrir les sources, boutiques et états d’inscription concernés. Ne supposez pas que l’export natif se limite aux invités ou que chaque source représente la moitié de votre liste.

Cet exemple en lecture seule utilise le préfixe standard et l’identifiant de boutique 1 à titre d’exemple. Adaptez les deux à votre installation et protégez les données personnelles exportées :

SELECT id, email, active, newsletter_date_add,
       ip_registration_newsletter, http_referer
FROM ps_emailsubscription
WHERE id_shop = 1
ORDER BY newsletter_date_add DESC
LIMIT 50;

Pour ps_emailsubscription sur les boutiques modernes, ouvrez Modules > Gestionnaire de modules, puis Configurer : examinez l'email de vérification, la confirmation après inscription, l'éventuel bon de bienvenue et les filtres d'export. Consultez la documentation de la version installée pour son comportement précis. La vérification demande un clic avant activation ; la confirmation est un accusé ultérieur. Dans le parcours d'activation invité de ps_emailsubscription 2.7.1, l'activation définit active=1 sans enregistrer d'horodatage distinct de confirmation. Une ligne inactive n'autorise pas l'envoi.

Le code source officiel du module documente sa table et son export mixte clients/invités. Le module collecte les adresses ; il n’envoie pas les campagnes.

Consigner les autorisations et respecter chaque retrait

Présentez le choix marketing clairement et séparément de la passation de commande. Une case de consentement doit être décochée au départ. Indiquez qui enverra les messages, ce que l’abonné recevra, une fréquence annoncée honnêtement et comment arrêter. Ajoutez un lien vers les informations de confidentialité pertinentes.

Conservez le libellé ou la version du formulaire, la source, la date, la méthode et les justificatifs de confirmation pertinents. Un booléen newsletter, une IP ou une date d’inscription est un élément, pas une preuve complète de consentement valide. Le double opt-in peut renforcer la confirmation du contrôle de l’adresse ; il ne conserve pas automatiquement tous ces éléments et ne suffit pas à établir la conformité.

Ne supposez pas qu’une relance de panier abandonné est transactionnelle simplement parce qu’elle mentionne un panier ou ne contient pas de remise. Vérifiez les règles de prospection électronique applicables ainsi que la base du traitement des données personnelles. Au Royaume-Uni, les recommandations de l’ICO décrivent le consentement et un soft opt-in limité sous conditions, notamment une collecte lors d’une vente ou de négociations pour des produits similaires et une possibilité de refus à la collecte et dans chaque message. Un argument d’intérêt légitime au titre du GDPR ne supprime pas à lui seul ces règles.

Conservez des autorisations distinctes pour l’email, les SMS et les autres canaux, même si une plateforme les stocke dans un profil commun. Un numéro de téléphone fourni pour la livraison n’est pas un consentement aux SMS marketing. Appliquez les exigences de suivi et d’autorisation du navigateur pertinentes avant de collecter des signaux comportementaux ou push.

La désinscription est un événement d’intégration

1. Rendez le parcours de désinscription du message facile à utiliser.
2. Mettez rapidement à jour l’état d’exclusion chez l’expéditeur.
3. Propagez le retrait à chaque audience connectée et fiche de boutique concernée.
4. Conservez une trace durable et minimale d'exclusion pour qu'un CSV ultérieur, une nouvelle tentative ou une reprise d'historique ne puisse pas réinscrire l'adresse.
5. Testez le retrait depuis la boutique et la plateforme d’envoi.

Dans ps_emailsubscription 2.7.1, la désinscription d’un invité en front-office supprime sa ligne ; une action administrative peut plutôt la désactiver. L’état newsletter des clients inscrits est mis à jour. Ne faites pas d’une ligne d’inscription supprimée votre seule trace de retrait.

Séparez les communications essentielles sur les commandes des exclusions marketing. Ne considérez jamais l’import d’une audience, la création d’un compte ou l’installation d’un connecteur comme une nouvelle autorisation. Refusez les listes achetées ou collectées par extraction sans les autorisations valides et la provenance requises.

Proposer des occasions utiles de s’inscrire

Testez des emplacements pertinents dans le pied de page, le formulaire de compte, le tunnel de commande et les pages de contenu. Une popup discrète peut offrir une autre possibilité sans gêner les achats. Chaque emplacement exige la même autorisation claire et un processus de confirmation fonctionnel.

Pour les popups, testez le délai, la profondeur de défilement et la fréquence au lieu de copier une règle universelle de 30 secondes. Prévoyez une fermeture évidente, gardez une version mobile utilisable et évitez d’interrompre la commande. Les recommandations de Google sur les interstitiels expliquent pourquoi masquer le contenu d’une page peut poser problème.

Proposez une raison utile de s’inscrire : conseils d’achat, actualités de disponibilité, nouvelles gammes ou offre de bienvenue dont la marge a été vérifiée. Si vous promettez un bon après confirmation, testez le parcours réel de vérification et de confirmation. Ne supposez pas qu’un code partagé est lié à un client ou à usage unique.

Mesurez les confirmations terminées par emplacement d’inscription, pas seulement les adresses soumises. Examinez les plaintes, les doublons, les échecs des messages de vérification et les achats ultérieurs. Comparez les emplacements avec la même définition d’une inscription terminée.

Tester une inscription avant de promouvoir le formulaire

Supposons qu'un visiteur s'inscrive via le pied de page, crée ensuite un compte avec la même adresse puis modifie son choix de newsletter. Ce parcours teste davantage que le message de réussite d'un formulaire : il traverse les enregistrements invité et client décrits ci-dessus.

1. Utilisez une adresse contrôlée sans inscription antérieure. Consignez le texte du formulaire, la langue et la boutique, envoyez-le et examinez l'enregistrement destinataire. Si la vérification est activée, l'adresse ne doit pas recevoir d'envoi marketing avant confirmation.
2. Terminez la vérification et examinez le profil actif et le message de bienvenue. Si un bon a été promis, vérifiez son arrivée via le parcours prévu d'inscription finalisée et la concordance de ses restrictions avec la promesse.
3. Créez un compte avec cette adresse. Confirmez que le connecteur rapproche l'abonné existant sans doublon ni perte de preuve d'autorisation. Retirez ensuite le choix newsletter et vérifiez la fiche client et la plateforme d'envoi. Répétez la source d'inscription antérieure ou une reprise d'historique prise en charge : aucune ne doit rétablir l'inscription.
4. Utilisez une autre adresse de test pour commander sans cocher le choix marketing. L'achat ne doit pas créer un abonnement marketing. Conservez ce résultat avec celui de l'inscription réussie avant d'élargir les points de collecte.

Vérifier le transport d’envoi et l’authentification

Identifiez le système qui envoie chaque message. Un module appelant la messagerie PrestaShop utilise le transport configuré dans la boutique. Une plateforme de campagnes externe utilise normalement sa propre infrastructure. Modifier les paramètres SMTP de la boutique ne configure pas toutes les plateformes.

Dans Paramètres avancés, E-mail, inspectez le transport sélectionné et envoyez un test. Le circuit sans SMTP de PrestaShop 1.7.8 utilise le transport sendmail de Swift, tandis que la version 9.1 utilise Symfony SendmailTransport. Désigner l’un ou l’autre simplement par PHP mail() est inexact. Un serveur de messagerie local correctement configuré peut authentifier et signer les emails ; le SMTP authentifié seul ne garantit pas l’alignement du domaine.

• SPF : autorisez les véritables expéditeurs d'enveloppe sur le domaine approprié. Publiez une seule politique SPF par nom de domaine et suivez les enregistrements exacts de l'expéditeur ; n'ajoutez pas arbitrairement des includes à tous les domaines From.
• DKIM : publiez les enregistrements de sélecteur du prestataire et vérifiez que les messages reçus portent une signature valide.
• DMARC : vérifiez que le domaine From visible s’aligne sur une identité SPF ou DKIM validée. Examinez les expéditeurs légitimes et les rapports avant de durcir l’application de la politique.

La spécification SPF explique l’évaluation des enregistrements. Utilisez les instructions d’authentification de votre expéditeur, pas un enregistrement DNS copié avec les valeurs d’un autre compte.

Pour les destinataires Gmail personnels, les exigences de Google pour les expéditeurs imposent SPF ou DKIM à tous les expéditeurs, ainsi que des mesures supplémentaires d’authentification, d’alignement DMARC et de désinscription aux expéditeurs de masse autour du seuil de 5 000 messages par jour. Les messages marketing et les envois en masse sur abonnement exigent des en-têtes de désinscription en un clic pris en charge et un lien visible dans le corps. Un lien de pied de page seul ne remplace pas ce mécanisme d’en-tête.

Séparez les flux marketing et transactionnels si cela facilite l’exploitation, mais un sous-domaine ne garantit pas l’isolement de la réputation. Augmentez les nouveaux volumes d’envoi de manière réfléchie, excluez les rejets définitifs et les plaintes, et respectez les limites actuelles de chaque prestataire. Ne vous fiez pas à une durée de montée en charge fixe ni à un indicateur générique de désinscription.

Inspectez les en-têtes reçus et les événements de livraison du prestataire. Un service de test peut révéler des problèmes de configuration, mais son score ne prouve pas l’arrivée en boîte de réception. Un échec d’authentification peut entraîner rejet, limitation ou filtrage ; il n’existe pas de règle universelle de classement en spam par défaut.

Bien utiliser la consultation native des paniers et la relance manuelle

L’abandon de panier signifie qu’un panier n’est pas devenu une commande. L’acheteur peut être parti avant d’avoir terminé le tunnel de commande ou atteint le paiement. Un panier entièrement anonyme ne contient aucune adresse email que vous puissiez contacter.

Commandes, Paniers permet de consulter les paniers dans les back-offices modernes. Le cœur peut envoyer manuellement au client lié à un panier un email contenant un lien de récupération. Ce lien peut restaurer le panier. Le cœur seul ne fournit pas la séquence marketing de plusieurs messages, planifiée et segmentée, décrite ci-dessous.

Cette requête recense les paniers liés à un client, mis à jour dans une fenêtre illustrative de 30 jours, inactifs depuis au moins une heure et sans commande associée. Elle indique la quantité d’articles, pas la valeur monétaire du panier ni l’autorisation d’envoi. Remplacez le préfixe, la boutique et les fenêtres temporelles selon vos besoins.

SELECT c.id_cart, c.date_add, c.date_upd, cu.email,
       SUM(cp.quantity) AS items
FROM ps_cart c
JOIN ps_cart_product cp
  ON cp.id_cart = c.id_cart AND cp.id_shop = c.id_shop
JOIN ps_customer cu ON cu.id_customer = c.id_customer
WHERE c.id_shop = 1
  AND cu.deleted = 0 AND cu.email <> ''
  AND c.date_upd >= DATE_SUB(NOW(), INTERVAL 30 DAY)
  AND c.date_upd < DATE_SUB(NOW(), INTERVAL 1 HOUR)
  AND NOT EXISTS (
    SELECT 1 FROM ps_orders o WHERE o.id_cart = c.id_cart
  )
GROUP BY c.id_cart, c.date_add, c.date_upd, cu.email
ORDER BY c.date_upd DESC;

Utilisez plutôt date_add si vous visez les paniers créés pendant une période. Calculez les totaux monétaires dans le contexte tarifaire approprié du panier, avec devise, taxes, livraison, remises et boutique. Une somme des quantités de produits du panier ne répond pas à cette question.

Un contact manuel peut convenir à une demande de support précise ou à un cas de relance autorisé. Appliquez les mêmes vérifications d’autorisation et d’exclusion qu’au message automatisé correspondant.

Comprendre les liens natifs de récupération de panier et leur sécurité

L’URL native de récupération utilise recover_cart et token_cart. PrestaShop 1.7.8 et 9.1 calculent le jeton ainsi : md5(_COOKIE_KEY_ . 'recover_cart_' . id_cart). Le jeton n’est pas simplement l’identifiant du panier et n’est pas le secure_key du panier.

Le jeton restaure l’authentification du client ainsi que le contexte du panier. Une fiche client est nécessaire ; une fiche de client invité diffère d’un panier sans aucun client. PrestaShop 9.1 rejette aussi un panier déjà utilisé pour une commande. PrestaShop 1.7.8 vérifie le jeton, le panier et le client, mais sa méthode de récupération n’effectue pas de contrôle équivalent des commandes terminées. Testez les liens des commandes terminées sur votre version exacte.

Cet exemple côté serveur suppose un Cart déjà chargé et validé, son client associé et le bon contexte de boutique :

$idCart = (int) $cart->id;
$token = md5(_COOKIE_KEY_ . 'recover_cart_' . $idCart);
$link = Context::getContext()->link->getPageLink(
    'order',
    true,
    (int) $cart->id_lang,
    [
        'step' => 3,
        'recover_cart' => $idCart,
        'token_cart' => $token,
    ],
    false,
    (int) $cart->id_shop
);

Ceci décrit le mécanisme de compatibilité natif, sans recommander MD5 pour de nouveaux jetons d'authentification. Un système de récupération personnalisé nécessite sa propre conception sécurisée des jetons, de l'expiration et des autorisations.

Traitez une URL de récupération comme une donnée sensible, car elle peut restaurer une session client. Ne l’exposez pas dans des pages publiques, des rapports partagés ou un suivi tiers inutile. Testez le lien de l’email dans un nouveau navigateur, dans la langue et la boutique prévues, avec des paniers de clients inscrits et invités.

Revérifiez le prix, la disponibilité, la livraison et les remises au retour de l’acheteur. Ne promettez pas qu’un ancien total de panier est réservé indéfiniment. Testez les paniers supprimés, les commandes terminées et les jetons invalides, puis vérifiez le mécanisme de récupération du connecteur au lieu de supposer que chaque fournisseur utilise le circuit du cœur.

Construire un scénario de relance comme une expérience mesurée

Un scénario de relance nécessite l’activité du panier, l’identité, l’autorisation, les produits actuels, un lien de récupération fonctionnel et un événement d’achat qui arrête les messages. Fiabilisez ces éléments avant d’activer le scénario. Un simple extrait de code de suivi ne suffit pas.

Le calendrier ci-dessous est une hypothèse de test. Tous les délais partent du même événement d’abandon, pas de l’email précédent. Vous pouvez commencer par le premier message seul et tester si des messages supplémentaires apportent un bénéfice incrémental.

Les objets possibles incluent « Votre panier est prêt à être consulté » ou « Pouvons-nous vous aider pour votre commande ? ». N’affirmez pas que le premier message convertit toujours le mieux ou qu’un nombre précis de messages est optimal.

Segmentez à partir des données réelles des clients et des paniers : premier achat ou nouvel achat, marge contributive, type de produit et événements observés dans le tunnel de commande. Une sortie à l’étape de livraison ou de paiement peut suggérer une piste à examiner ; elle ne prouve pas la raison du départ.

Calculez le coût de l’offre à partir de la marge produit, des coûts de paiement et de traitement des commandes, des retours et de la participation aux frais de livraison. Incluez la livraison gratuite dans ce coût. Fondez tout seuil de valeur du panier sur ces coûts et sur la marge que vous pouvez dépenser.

Utilisez les règles panier pour des offres avec dates de validité réelles, restrictions d'éligibilité et limites d'utilisation. Pour une offre nominative à usage unique, créez un code unique, sélectionnez le destinataire sous Limiter à un seul client et réglez Quantité totale et Quantité disponible pour chaque utilisateur sur 1. Vérifiez si le connecteur choisi sait réellement créer et synchroniser les règles panier natives ; une fonction de coupon de plateforme ne le prouve pas.

Avant chaque envoi planifié, revérifiez la finalisation de l’achat, les exclusions, l’autorisation, les limites de fréquence et l’éligibilité du panier. Arrêtez la séquence après un achat répondant aux critères. Ne contactez pas la même personne par des scénarios superposés de panier, de navigation, de SMS et de newsletter sans coordination.

Tester une relance qui doit s'arrêter

Un client existant laisse un manteau et une taille choisie dans le panier, reçoit une relance puis achète depuis une autre session de navigateur. La relance différée doit s'arrêter même s'il ne clique jamais sur l'email. Mesurez ce résultat à partir de l'événement commande et de l'état du destinataire, plutôt que de considérer un clic suivi comme une preuve d'achat.

1. Accordez au contact de test l'autorisation de rappel prévue et vérifiez le produit, la déclinaison, la devise et la boutique actuels dans l'événement. Répétez avec l'autorisation refusée ; une adresse seule ne doit pas rendre le panier éligible.
2. Laissez le panier éligible entrer dans le scénario. Ouvrez son message dans une nouvelle session et vérifiez taille choisie, langue, prix actuels, options de livraison et éligibilité à la remise.
3. Finalisez un achat éligible sans utiliser le lien du message. Confirmez que l'événement d'achat associé retire les rappels en attente pour ce panier ou contact selon la politique convenue.
4. Rejouez un ancien événement panier et l'événement d'achat via le mécanisme de test pris en charge. La répétition ne doit ni produire un second message, ni rouvrir le panier récupéré, ni annuler un retrait ultérieur.
5. Répétez avec une offre expirée ou une déclinaison indisponible. Le client a besoin d'un panier exact et d'une explication exploitable, plutôt que d'une promesse de réservation d'anciens prix ou stocks.

Testez aussi une commande en attente de paiement hors ligne. Décidez explicitement si la commande met fin à la relance et quel rappel de paiement distinct doit éventuellement suivre. Une commande existante non payée n'est pas simplement un autre panier abandonné ; poursuivre aveuglément les deux scénarios peut demander au client de commander en double.

Comparer les intégrations réelles avant les plateformes

Notez les données nécessaires à chaque scénario prévu. La synchronisation des contacts, le chargement du site connecté, le suivi des produits consultés, les événements de panier, les commandes terminées, les remboursements et les mises à jour d’état de livraison sont des capacités distinctes. Le nom d’une intégration ou un champ de clé API n’en prouve aucune.

Comparez le connecteur maintenu par le fournisseur avec tout module MPR distinct. Ils peuvent remplir des fonctions différentes. N’installez pas deux émetteurs de suivi ou de données commerciales pour le même événement sans mécanisme de déduplication fonctionnel.

La documentation du plugin de Brevo décrit la synchronisation des contacts et commandes, le suivi d'activité et les options d'envoi ; sa version documentée 5.0.36 est testée jusqu'à PrestaShop 9.0, vérifiez donc séparément les combinaisons plus récentes.

Le module MPR Brevo (Sendinblue) Integration synchronise les contacts consentants, assure le suivi en boutique et peut acheminer les emails via Brevo. Vérifiez la couverture des événements d'achat, les mises à jour de livraison et les réglages d'acheminement de votre version avant d'ajouter un connecteur commercial distinct.

Utilisez les matrices de compatibilité actuelles pour vos versions exactes de PrestaShop et de PHP. Évitez les affirmations non étayées selon lesquelles un prestataire est toujours le moins cher, le mieux maintenu ou le plus simple à installer.

Choisir une campagne vérifiée ou un connecteur fondé sur le consentement

Quand l'équipe doit vérifier chaque message

Mail Revolution construit des audiences selon des règles de clients, consentement et commandes dans PrestaShop et prépare des messages à approuver par une personne. L'envoi est désactivé au départ. Vous rédigez chaque langue, choisissez horaires et limites quotidiennes, puis les réviseurs approuvent le message personnalisé exact de chaque destinataire. Modifier un message annule son approbation précédente et le consentement est revérifié avant l'envoi.

Choisissez cette solution lorsqu'un employé doit vérifier une relance de devis ou une newsletter sélectionnée avant son départ. Les profils d'expéditeur personnel et newsletter ont des usages distincts : les rapports newsletter suivent ouvertures et clics, les messages personnels aucun des deux. Budgétez le travail de vérification autant que la capacité d'envoi. Une campagne approuvée suit un modèle opérationnel différent d'un scénario autonome à plusieurs étapes de relance de panier ou de réactivation sur une plateforme externe.

Quand séparer les choix de newsletter et de rappel

SendPulse Integration maintient les contacts consentants à jour et enregistre séparément les choix newsletter et rappel de panier. Vous fournissez les accès du compte, choisissez les carnets d'adresses de chaque usage, examinez les options de confirmation, le délai de rappel, la conservation des paniers et les textes de consentement par langue. Créer un compte n'abonne pas le client, et l'envoi est désactivé au départ.

Le client gère ces choix sur une page dédiée liée depuis le compte et le tunnel de commande. Les retraits de la boutique sont mis en file pour SendPulse ; des contrôles planifiés ramènent ses désinscriptions dans le module. Avant lancement, exécutez ces tâches et examinez les travaux en attente et les échecs. Une préférence enregistrée en attente de traitement diffère d'un retrait déjà appliqué par l'expéditeur.

Préparez les campagnes et les éventuelles séquences de rappel dans SendPulse. Les détails du panier alimentent le scénario ; le lien de retour permet au client d'examiner le panier enregistré, de choisir sa fusion ou son remplacement du panier actuel, puis de confirmer la restauration. Testez les deux choix avec d'autres articles déjà dans le panier du navigateur. Ce parcours diffère de l'hypothèse que tout connecteur utilise l'URL native de restauration de session.

Le module et le compte externe ont des conditions distinctes. Vérifiez les droits actuels d'envoi et d'automatisation du compte et le comportement d'arrêt après achat du connecteur réel avant d'activer les rappels. La synchronisation des contacts seule ne garantit pas tous les événements nécessaires aux campagnes de cycle de vie ci-dessous.

Évaluer les formulaires, audiences et données commerciales de Mailchimp

Un formulaire d’inscription intégré peut collecter les noms, d’autres champs d’audience et des tags, en plus des adresses email. Il ne fournit pas à lui seul l’historique d’achat, les données produits ou la relance de panier. Les recommandations de Mailchimp sur les formulaires intégrés décrivent ces champs configurables.

Le connecteur PrestaShop du fournisseur documente le transfert des clients et des commandes ainsi que les fonctions ecommerce. Sa plage PHP publiée va de 5.6 à 8.1. Vérifiez la version du connecteur avant de l’installer sur PHP 8.2 ou ultérieur, même si votre boutique prend en charge cet environnement. Testez la couverture des produits, des paniers, des commandes invitées et de l’arrêt des relances après achat dans le connecteur choisi.

Le module MPR Mailchimp Integration assure la synchronisation des clients consentants avec l'audience, le chargement du site connecté et la gestion des nouvelles tentatives, plutôt qu'une synchronisation complète des commandes, produits et paniers ; consultez son aide pour la configuration.

Une audience est un jeu de données indépendant dans un compte Mailchimp, pas automatiquement une facture d’abonnement distincte. Des contacts facturables présents dans plusieurs audiences peuvent être comptés plusieurs fois. Envisagez une audience unique avec les tags et segments appropriés si cela convient à votre activité, tout en séparant correctement les entités juridiques ou les autorisations différentes.

Créez les segments fondés sur les achats seulement après avoir vérifié les données d’achat : acheteurs récents, clients n’ayant effectué qu’un seul achat, catégories pertinentes ou dépenses historiques définies. Un indicateur newsletter seul ne prouve pas l’autorisation pour l’audience et ne synchronise pas les retraits ultérieurs.

Suivez les instructions d’authentification de domaine propres à votre compte. Ne supposez pas que son exigence SPF correspond à celle de l’expéditeur transactionnel de la boutique.

La documentation des offres de Mailchimp indique pour Free 250 contacts, 500 envois mensuels et 250 envois quotidiens. Confirmez les limites affichées dans votre compte avant d’établir votre budget. Les scénarios d’automatisation sont exclus de Free dans le comparatif des offres, donc un scénario de réactivation à plusieurs étapes nécessite une offre adaptée.

Évaluer les événements Klaviyo et les autorisations par canal

Évaluez Klaviyo si vous avez besoin de segments fondés sur les événements, de données produits et commandes, de scénarios conditionnels ou d’une messagerie multicanale prise en charge. Les indicateurs prédictifs sont des estimations soumises à des exigences de données, pas un revenu assuré. Un seuil de nombre de contacts ou de panier moyen ne prouve pas que l’abonnement sera rentabilisé.

Commencez par la documentation officielle d'intégration PrestaShop. Elle liste actuellement PrestaShop 1.7.0 à 9.1.x, avec des conditions supplémentaires pour la collecte SMS dans le tunnel. Elle inclut les événements sur site et la synchronisation des commandes ; n'ajoutez pas automatiquement un autre script.

Vérifiez identité, suivi autorisé, signaux du tunnel et suppression des relances après commande finalisée avant d'activer les messages d'abandon. Testez les commandes avec compte et invité, les moyens de paiement alternatifs et les pages de commande personnalisées. Examinez le délai réel de synchronisation et les événements transactionnels activés.

Le module MPR distinct Klaviyo Integration possède des hooks navigateur et panier/confirmation ; vérifiez sa couverture et ses limites dans son aide plutôt que de supposer qu'il s'agit du connecteur commercial historique complet de l'éditeur.

Pour une intégration serveur personnalisée, utilisez les API Events et Profiles prises en charge et versionnées par date. Les anciennes API HTTP Track et Identify v1/v2 de Klaviyo ont été retirées le 30 juin 2024, comme l’indique sa FAQ de migration. Les méthodes prises en charge par le SDK navigateur constituent une interface distincte. Gardez les clés API privées côté serveur.

Un profil client partagé conserve des états distincts de consentement et d’exclusion pour l’email et les SMS. Coordonnez les sorties des scénarios entre les canaux et vérifiez les destinations prises en charge, les plages de tranquillité et les frais par message. Klaviyo documente aussi une intégration WhatsApp Business ; vérifiez sa disponibilité et ses autorisations au lieu d’affirmer que la plateforme ne peut pas utiliser WhatsApp.

Évaluer Omnisend et diagnostiquer les activités manquantes

Omnisend propose l’email et les SMS via son intégration PrestaShop. Chaque canal nécessite ses propres autorisations et circuit de données. Omnisend propose aussi le push web pour les plateformes prises en charge ; vérifiez l’éligibilité du canal pour votre intégration commerciale avant de prévoir un scénario push. Une audience commune ne rend pas chaque canal disponible ou autorisé pour chaque contact.

Suivez le guide actuel du fournisseur pour l’intégration PrestaShop pour vérifier la couverture des contacts, produits, commandes et comportements. Il précise que les événements comportementaux nécessitent des contacts identifiés, par exemple des personnes ayant soumis un formulaire ou cliqué sur un lien suivi dans un email. La navigation anonyme ne devient pas automatiquement une activité visible.

1. Vérifiez que l’intégration complète prise en charge est installée, pas seulement une clé API.
2. Confirmez le chargement des scripts requis selon le choix de suivi applicable et la politique de sécurité du contenu.
3. Confirmez que le contact de test est identifié par une méthode prise en charge.
4. Inspectez l’arrivée des événements et les données réelles des produits et paniers.
5. Vérifiez les filtres des scénarios, l’abonnement au canal, les exclusions et les règles de fréquence.
6. Passez une commande et confirmez l’arrêt des messages d’abandon en attente.

Ne supposez pas que des branchements arbitraires entre Expédié et Livré sont pris en charge. Associez uniquement les événements réellement envoyés par le connecteur installé. Testez les remboursements, les annulations et les différents modes de paiement.

Le module MPR distinct Omnisend Integration envoie visites, vues produit, changements de panier et commandes à Omnisend ; il se configure avec un Brand ID et un interrupteur d'activation. Vérifiez les données d'événements et la sortie après achat, et n'ajoutez un autre connecteur que pour les produits ou commandes historiques qu'il ne synchronise pas.

Comparez les limites actuelles de contacts, d’envoi et de canaux avant d’établir votre budget. Les destinations SMS et les segments de message peuvent modifier le coût, et le push d’une plateforme n’est pas par nature exempt de frais d’abonnement. Ne choisissez pas un canal uniquement parce qu’un email est enregistré comme non ouvert.

Évaluer l’automatisation et la couverture commerciale d’ActiveCampaign

Considérez les scénarios que vous construirez réellement : branches conditionnelles, étapes d’attente jusqu’à une condition, objectifs, champs personnalisés, scoring des prospects ou étapes du pipeline commercial. Un processus de devis B2B peut nécessiter des données différentes d’un scénario de réachat au détail.

Définissez les champs de contact, étiquettes, événements produit et commande, données panier et activité facultative sur site. Le suivi sur site observe les contacts connus autorisés ; ce n'est pas une synchronisation API des commandes. Un connecteur, un processus intermédiaire ou une implémentation Deep Data personnalisée doit fournir les données commerciales nécessaires aux automatisations.

Le module MPR ActiveCampaign Integration fournit le suivi sur site et, avec l'adresse du compte et la clé API en plus de l'identifiant de suivi, la synchronisation des contacts, commandes et paniers abandonnés. Consultez son aide pour confirmer ces fonctions et l'arrêt d'une séquence après achat dans votre version installée.

Associez séparément passation de commande, confirmation du paiement, traitement, annulation et remboursement. Une commande par virement ou contre remboursement peut être passée avant le paiement. Ne remplacez pas chaque événement Placed Order par un déclencheur d’état payé et ne présentez pas la création de commande comme une preuve de paiement.

Commencez par un scénario testé, puis ajoutez des segments et les éventuelles règles de scoring ou de pipeline. Préférez les clics confirmés, les achats et l’activité commerciale pertinente à un scoring fondé uniquement sur les ouvertures. N’utilisez les déclencheurs de navigation qu’après avoir fiabilisé l’identité et les autorisations de suivi.

La présentation actuelle des offres d’ActiveCampaign distingue les offres marketing de base et les options, notamment les fonctions CRM enrichies. Vérifiez le contenu réel de l’offre pour les fonctions de pipeline, de vente, de scoring, de SMS et de messagerie transactionnelle. Ne supposez pas qu’un CRM avancé est inclus simplement parce que vous choisissez un niveau email supérieur.

Associer les messages après achat aux circuits d’envoi réels

Examinez les réglages réels des états dans Paramètres de la boutique, Commandes, États. Sur PrestaShop 1.6, consultez Commandes, États. Les valeurs par défaut et personnalisations diffèrent. Les paramètres d'installation de PrestaShop 9.1 activent l'email pour Préparation en cours ; vérifiez-le en planifiant les notifications.

Incluez dans les confirmations un récapitulatif exact, la prochaine étape et un canal de support surveillé. Ne laissez pas entendre que la commande est payée simplement parce qu’une confirmation existe. Les modes de paiement peuvent envoyer des instructions ou notifications supplémentaires.

Les modèles d'emails existent généralement en HTML et texte dans des répertoires mails par langue ; les chemins propres au thème ou au module influent sur leur sélection. Examinez par exemple mails/en/order_conf.html et mails/en/order_conf.txt, puis vérifiez si le thème actif ou le module fournit la copie sélectionnée. La génération des thèmes d'emails et les traductions varient selon la version. Identifiez le modèle et la langue effectifs avant modification et conservez des changements maintenables lors des mises à jour.

Si disponible, utilisez International, Traductions, Traductions des modèles d'emails ; dans PrestaShop 1.6, l'emplacement historique est Localisation, Traductions. Modifiez une ligne distinctive en préproduction et générez le vrai message de commande dans la langue voulue. Si la ligne manque, retracez la sélection et la génération du modèle avant de modifier sans cesse le fichier du cœur. Testez la version texte comme le HTML.

Les variables disponibles dépendent du code d’envoi et des hooks d’extension. Les totaux de livraison des confirmations standard utilisent {total_shipping}, et non une variable universelle {shipping}. Un circuit de suivi peut fournir {followup} ; vérifiez chaque modèle séparément.

Un suivi utile demande si l’article est arrivé et fonctionne comme prévu. Une demande d’avis doit laisser assez de temps pour utiliser le produit et mener à un formulaire fonctionnel propre au produit. Des délais de cinq à sept ou de sept à quatorze jours sont des hypothèses à tester, pas des moments optimaux universels.

Pour les consommables, estimez le cycle de réapprovisionnement à partir des achats réels. Pour les biens durables, proposez des accessoires réellement compatibles, comme une carte mémoire ou un sac pour appareil photo. Coordonnez les autres promotions pour éviter d’inscrire les acheteurs récents à des scénarios contradictoires.

Pour la collecte des avis et les limites des demandes effectivement implémentées, consultez le guide des avis.

Assurer la cohérence des promesses de livraison et du support

N’envoyez un message Livré qu’à partir d’un signal de livraison fiable. Le nom d’un état de commande ou son indicateur delivery ne prouve pas à lui seul que le colis est parvenu au client. Si vous devez estimer la livraison, présentez clairement cette estimation et tenez compte des retards.

Estimated Delivery Date fournit des estimations sur les fiches produits ; utiliser une estimation enregistrée propre à la commande dans un email de confirmation ou d'expédition nécessite une intégration supplémentaire, décrite dans son aide.

Advanced Order Fulfilment fournit étapes internes, tâches, acheminement et notifications. Vérifiez le lien entre votre processus configuré et les états natifs de commande ; consultez son aide pour les réglages pris en charge.

Choisissez le processus réel d’expédition : création d’étiquette, contrôle de l’emballage, saisie du suivi et notification. Consignez les exceptions et les messages clients sur la commande pour qu’un autre membre de l’équipe puisse les suivre. Si une promesse de livraison change, informez le client de façon réaliste et indiquez la solution disponible.

Pour l’emballage, utilisez des documents adaptés à la commande et au destinataire. Le destinataire d’un cadeau peut avoir besoin d’un bon de livraison plutôt que d’une facture affichant les prix. Un mot de remerciement ou une offre autorisée est un choix à tester, pas un effet de fidélisation assuré.

Traitez les livraisons endommagées, erronées ou manquantes via vos procédures de support et de transport. Ne promettez pas qu’un incident bien géré fidélise davantage qu’une commande sans problème. Consignez l’action, son responsable et sa réalisation pour qu’un email utile corresponde à une résolution réelle.

Traiter une livraison retardée ou endommagée

Une commande part en plusieurs colis, mais le client n'en a reçu qu'une partie lorsqu'un message de satisfaction arrive à échéance. Un email générique « profitez de votre commande » est ici trompeur. Reliez les faits d'expédition, la décision de l'assistance et l'éligibilité marketing, avec un employé désigné pour la prochaine action.

Si votre procédure de retour utilise la date de livraison, transmettez les preuves prises en charge à ce processus plutôt que de les remplacer par la date de commande. Distinguez dates estimées et confirmées dans les messages clients et ne redémarrez pas automatiquement une séquence promotionnelle parce qu'un ticket d'assistance est fermé.

Configurer les liens de suivi et éviter les emails d’expédition en double

Deux valeurs créent le lien de suivi : le modèle d’URL du transporteur et le numéro de suivi de la commande ou de l’envoi. Le circuit de suivi du transporteur remplace @ par le numéro. Utilisez l’URL actuellement prise en charge par le transporteur au lieu de copier un exemple non vérifié.

1. Vérifiez l’URL de suivi du transporteur sous Livraison, Transporteurs.
2. Enregistrez le véritable numéro de suivi dans l’enregistrement commande-transporteur ou envoi voulu.
3. Observez si cet enregistrement envoie in_transit.
4. Faites avancer le workflow jusqu’au véritable état d’expédition et observez son email de statut configuré.
5. Ouvrez les deux messages ainsi que le compte client ou le parcours de suivi invité pour vérifier le fonctionnement des liens.

Saisir le numéro avant le statut peut permettre d’inclure le suivi dans le message de statut, mais aussi produire deux messages, car l’email de mise à jour du suivi possède un déclencheur distinct. Testez la version, le module transporteur et le workflow choisis, puis configurez une politique de notification cohérente.

Utilisez une référence de commande claire, une action de suivi évidente, des informations d’envoi pertinentes et un canal de support. Préservez les bonnes variables de modèle et testez l’affichage mobile. Testez séparément le réenregistrement d’un numéro inchangé et son remplacement par un nouveau.

La gestion des colis multiples dépend de la version. PrestaShop 9.1 inclut le fractionnement, l’affectation des articles, le regroupement et le suivi, avec un affichage en boutique conditionné par le drapeau de fonctionnalité d’amélioration des expéditions. Les anciens workflows et les modules transporteurs diffèrent. Vérifiez la version exacte et les fonctions activées au lieu de supposer que le cœur ne permet jamais de fractionner un envoi.

Pour plusieurs colis, indiquez aux clients quels articles appartiennent à chaque envoi et rendez chaque lien de suivi accessible. Étiquette créée, expédié, en transit et livré sont des événements différents.

Si le suivi n’avance plus, enquêtez et informez le client. Pour un colis déclaré livré mais manquant, vérifiez les preuves de livraison du transporteur et enquêtez ; un scan seul ne garantit pas une défense contre une rétrofacturation. Pour un retour à l’expéditeur, confirmez l’adresse avant de réexpédier. Traitez les colis endommagés selon la solution applicable et la procédure de réclamation transporteur.

Les imports transporteur, les outils d’étiquettes ou les imports de suivi en masse pris en charge peuvent réduire la saisie manuelle. Vérifiez leurs déclencheurs d’email ainsi que les numéros enregistrés. Le guide de livraison couvre plus largement la configuration des transporteurs.

Lire le message tel qu'il a été envoyé

Si le compte client contient désormais un lien de suivi correct mais que l'ancien email est vide, comparez l'heure du message à celle de l'enregistrement du suivi. Une correction ultérieure ne réécrit pas un email déjà livré. Un email contenant le numéro de suivi mais ouvrant le mauvais transporteur indique plutôt un problème de modèle d'URL ou d'association du transporteur à l'expédition. Gardez un exemple contrôlé de chaque échec pour vérifier le module d'import ou d'étiquettes.

Renvoyer le bon message sans changer les statuts en boucle

Déterminez d’abord si le client a besoin d’une notification de statut, d’une confirmation de commande ou d’une facture. Vérifiez l’adresse, la langue, le modèle choisi, le résultat du prestataire et tout rejet. Une entrée de journal d’email ne prouve ni la livraison en boîte de réception ni la lecture.

Dans PrestaShop 1.7.8 et 9.1, l’action native de renvoi depuis l’historique des statuts utilise un enregistrement existant et envoie son email de statut configuré sans changer l’état du workflow ni ajouter de ligne d’historique. Les mises à jour modernes de statut peuvent refuser de réaffecter l’état courant.

Ne faites pas défiler les statuts pour renvoyer un email. Les changements d’état peuvent affecter le stock, notamment les transitions de l’indicateur shipped, ainsi que les documents, hooks et autres automatisations. N’effectuez une véritable transition que si le workflow de la commande doit changer.

Le message original order_conf est construit par un circuit d’envoi différent. Une reconstruction dédiée doit assembler les bonnes variables de commande et le bon modèle ; elle ne reproduit pas nécessairement les octets d’origine.

Resend Order Confirmation reconstruit le message avec les données actuelles de commande et client et le modèle actuel, laisse l'état et les totaux inchangés, enregistre une note privée et un journal et envoie sans facture jointe. Vérifiez le destinataire affiché avant confirmation : il utilise l'email actuel du client, la langue de la commande et sa boutique d'origine.

Vérifiez l’identité et la destination prévue avant de corriger une adresse email ou de renvoyer des données personnelles de commande. Après modification d’une commande, assurez-vous que le message reflète les données finales. Vérifiez les factures séparément au lieu de supposer que chaque confirmation inclut le PDF.

Les clients peuvent consulter commande et documents disponibles via les parcours pris en charge de compte ou de suivi invité. Un bouton de renvoi côté client nécessite une extension ou personnalisation adaptée, avec contrôle de propriété, destinations maîtrisées, limites d'abus et traces d'activité.

Testez les renvois en préproduction avec un collecteur d’emails et des commandes de test identifiables. Des renvois répétés ne corrigeront pas un échec d’authentification ou de livraison. Examinez l’expéditeur, puis envoyez une fois le message requis.

Définir l’inactivité, délimiter l’audience et tester les offres

La réactivation vise une période écoulée depuis un achat répondant aux critères, plutôt qu’un panier récemment abandonné. Définissez cette politique d’achat et mesurez la distribution des intervalles entre commandes par client et type de produit. Exportez les commandes éligibles, triez chronologiquement les achats de chaque client et calculez les écarts entre commandes consécutives. Une requête portant uniquement sur la dernière commande ne mesure pas ces intervalles.

Un consommable au cycle approximativement mensuel peut justifier un test plus précoce qu’un appareil durable. La mode peut être saisonnière. Si vous essayez des seuils comme 1,5 ou 2 fois l’intervalle d’achat habituel, traitez-les comme des paramètres de test et comparez les résultats.

Cette audience illustrative sélectionne les clients dont la commande valide la plus récente date de 60 à 365 jours dans la boutique 1. Remplacez le préfixe, la boutique et les fenêtres. valid=1 reflète la gestion des états logable, pas une preuve universelle de paiement ou d’exclusion des remboursements ; inspectez vos états et ajoutez la politique de paiement, d’annulation et de remboursement requise avant utilisation.

SELECT c.id_customer, c.firstname, c.lastname, c.email,
       MAX(o.date_add) AS last_order
FROM ps_orders o
JOIN ps_customer c ON c.id_customer = o.id_customer
WHERE o.id_shop = 1
  AND o.valid = 1
  AND c.newsletter = 1 AND c.deleted = 0
GROUP BY c.id_customer, c.firstname, c.lastname, c.email
HAVING MAX(o.date_add) < DATE_SUB(NOW(), INTERVAL 60 DAY)
   AND MAX(o.date_add) >= DATE_SUB(NOW(), INTERVAL 365 DAY)
ORDER BY last_order DESC;

L’indicateur newsletter est un premier filtre. Appliquez les autorisations, exclusions et autres critères d’exclusion de campagne actuels avant l’envoi. La dernière visite n’est pas le dernier achat ; utilisez les données de commande au lieu de déduire l’inactivité de la grille clients.

Un exemple de séquence à tester

Ces délais partent de l’entrée dans le scénario et sont des hypothèses, pas une raison de supposer que quatre messages valent mieux qu’un. Arrêtez après un achat éligible ou un retrait. Définissez quand réduire ou arrêter le marketing pour les personnes qui ne répondent pas ; ne confondez pas les ouvertures automatisées avec un engagement significatif.

Les incitations possibles incluent remise en pourcentage, prise en charge de livraison, cadeau ou avantage fidélité. Il n'existe pas de remise minimale efficace universelle. Des codes liés au client, des dates réelles de validité et des limites globales et par utilisateur aident à imposer un usage unique. Vérifiez la génération et la synchronisation réelles avant de promettre des codes uniques à grande échelle.

Segmentez selon l’historique produit, la récence, la valeur mesurée et l’activité significative. L’acheteur d’un bien durable peut avoir besoin d’accessoires plutôt que d’un autre article identique. Ne supposez pas que des dépenses historiques élevées rendent une forte remise rentable.

Mesurer une cohorte de campagne figée

Enregistrez les identifiants définitifs des destinataires et les dates de début et de fin de campagne. Comptez ensuite les achats éligibles dans cette fenêtre explicite sans conserver la clause HAVING d’inactivité. Cet exemple utilise des identifiants de cohorte et des dates illustratifs, avec la même réserve sur la politique de commande :

SELECT COUNT(DISTINCT o.id_customer) AS reactivated
FROM ps_orders o
WHERE o.id_shop = 1 AND o.valid = 1
  AND o.date_add >= '2026-10-01 00:00:00'
  AND o.date_add < '2026-11-30 00:00:00'
  AND o.id_customer IN (101, 102, 103);

Divisez par la taille de cohorte définie et comparez si possible à un groupe témoin aléatoire. Suivez achats ultérieurs au plein tarif, remises, prises en charge de livraison et bénéfice contributif. Utilisez votre taux de récupération mesuré pour évaluer la campagne.

Distinguer client inactif et rappel produit

Supposons que vous vendiez des aliments et des paniers durables pour animaux. Un acheteur d'aliments ayant manqué son réachat habituel peut être un bon candidat au rappel de réapprovisionnement ; un acheteur de panier avec le même délai depuis l'achat peut n'avoir aucun besoin de racheter. Si l'acheteur d'aliments a récemment acheté un panier, son dernier achat client est récent malgré l'ancienneté de l'achat alimentaire. Déterminez si la règle vise le client ou un produit précis, puis examinez les lignes de commande correspondantes avant de l'intégrer à un scénario.

Pour une campagne vérifiée, enregistrez l'audience et les exclusions choisies avant l'approbation des messages par l'équipe. Pour un scénario continu, définissez quand une personne peut revenir après un achat ou une tentative antérieure. Sinon une tâche quotidienne d'éligibilité peut réadmettre sans cesse le même destinataire sans réponse et contourner la limite du dernier message.

Mesurer la valeur, le réapprovisionnement et tout le circuit d’envoi

Les dépenses historiques nécessitent une politique de devise et de remboursement

N'additionnez pas des montants en devises de commande différentes comme s'ils partageaient une devise. Une convention de reporting consiste à convertir le montant enregistré de chaque commande selon son taux enregistré vers la devise de référence de la boutique. Si cette base a changé dans le temps, normalisez explicitement avant comparaison. Le chiffre d'affaires historique payé n'est ni une valeur vie client complète ni un bénéfice.

Cet exemple de diagnostic regroupe par client et boutique et signale les taux absents ou non positifs. Il ne soustrait pas les remboursements et ne prouve pas l’autorisation actuelle d’envoi :

SELECT o.id_customer, COUNT(*) AS order_count,
       SUM(CASE WHEN o.conversion_rate > 0
                THEN o.total_paid_real / o.conversion_rate END)
           AS historical_paid_base,
       SUM(CASE WHEN o.conversion_rate IS NULL
                     OR o.conversion_rate <= 0 THEN 1 ELSE 0 END)
           AS invalid_rates
FROM ps_orders o
WHERE o.id_shop = 1 AND o.valid = 1
GROUP BY o.id_customer
ORDER BY historical_paid_base DESC;

N’utilisez pas une valeur avec des taux invalides pour le classement. Définissez les états payé/terminé, annulations, remboursements partiels, taxes, rétrofacturations et devise de reporting avant de créer un segment VIP ou de valeur. Joignez séparément les données d’autorisation et les exclusions actuelles.

Utiliser une fenêtre du dernier achat pour le réapprovisionnement

Une requête sur toutes les commandes de plus de 25 jours constitue un échantillon historique sans limite. Elle n’identifie pas les clients dont le dernier achat pertinent remonte à environ 25 jours. Regroupez par client et produit cible, retenez le dernier achat éligible et utilisez une tranche d’ancienneté délimitée. Faites correspondre les déclinaisons si le réapprovisionnement dépend de la variante.

SELECT o.id_customer, MAX(o.date_add) AS last_product_order
FROM ps_orders o
JOIN ps_order_detail od ON od.id_order = o.id_order
WHERE o.id_shop = 1 AND o.valid = 1
  AND od.product_id = 42
GROUP BY o.id_customer
HAVING MAX(o.date_add) >= DATE_SUB(NOW(), INTERVAL 26 DAY)
   AND MAX(o.date_add) < DATE_SUB(NOW(), INTERVAL 25 DAY);

Il s’agit d’une fenêtre quotidienne illustrative d’éligibilité, soumise à la même politique de commande, de remboursement et d’autorisation. Un scénario continu nécessite aussi la déduplication, la reprise des exécutions manquées et l’exclusion après achat. Exécutez les rapports lourds sur une copie de reporting adaptée ou en heures creuses ; SELECT ne signifie pas sans coût.

Présenter les résultats avec des dénominateurs clairs

• Emails opérationnels : génération, acceptation par le transport, événements de livraison/rejet, accès client et résultats du support.
• Marketing : destinataires éligibles, messages livrés, clics significatifs, désinscriptions, plaintes et commandes éligibles dans une fenêtre indiquée.
• Avis : visites du formulaire et avis déposés, plutôt que seules ouvertures d’emails.
• Bénéfice : achats incrémentaux après les coûts des marchandises, du traitement des commandes, de la plateforme et des avantages.

Apple Mail Privacy Protection peut charger du contenu distant sans qu’une personne lise le message. Les ouvertures ne permettent donc pas à elles seules de qualifier de façon fiable l’engagement individuel ou de diagnostiquer un problème de livraison. Le revenu attribué par la plateforme ne prouve pas non plus un revenu incrémental ; comparez avec un groupe témoin lorsque c’est possible.

Utilisez des tags de campagne cohérents pour l’analytique, sans données personnelles ni identifiants de récupération dans les champs de marquage. Consignez la fenêtre d’attribution, le fuseau horaire et la devise. Ne comparez pas les taux moyens d’ouverture transactionnels et promotionnels comme s’ils répondaient au même objectif.

Contrôles de lancement de bout en bout

1. Inscrivez une adresse de test et confirmez-la via chaque parcours de collecte.
2. Vérifiez le profil de destination, les justificatifs d’autorisation et le contenu exact des événements.
3. Testez l’abandon, le lien de récupération dans une nouvelle session et l’arrêt des relances après achat.
4. Passez des commandes avec différents modes de paiement ; inspectez les messages de confirmation, de statut et de suivi.
5. Désinscrivez-vous dans la boutique et chez le prestataire, puis lancez une nouvelle tentative ou une reprise d’historique et confirmez que l’exclusion subsiste.
6. Vérifiez une annulation, un remboursement, un événement en double, un produit manquant et un échec d’envoi.
7. Activez un scénario, désignez un responsable et surveillez les échecs et les résultats réels pour les clients avant d’aller plus loin.

Repérer l'étape défaillante avant de modifier la campagne

Conservez un dossier de test expurgé avec boutique, identifiants de contact, panier et commande, nom d'événement, heure de survenue, heure de traitement et résultat d'envoi. Recoupez le même cas entre systèmes. Ne mettez pas de clés API privées, accès de récupération ou copie inutile de la base clients dans un ticket d'assistance.

Basculer le processus et transmettre son exploitation

Une migration d'expéditeur ou de connecteur exige un plan de données autant qu'un changement de réglage. Faites correspondre les identités d'audience anciennes et nouvelles, langues, boutiques et champs d'autorisation. Décidez quels historiques sont repris et quels événements peuvent démarrer un nouveau scénario. Importer un ancien achat comme s'il venait d'avoir lieu peut envoyer un suivi sans pertinence ; importer un ancien contact comme nouvel abonné peut redémarrer une séquence de bienvenue.

1. Inventoriez chaque message, déclencheur et système d'envoi actif. Incluez tâches de modules, commandes planifiées, automatisations de plateforme et services ERP ou de préparation pouvant émettre le même message.
2. Préparez les traces d'exclusion avant d'activer les imports de contacts. Consignez la date limite de reprise historique, les correspondances d'identifiants et le traitement des messages déjà en file, puis répétez avec l'envoi désactivé.
3. Vérifiez explicitement l'isolation de la préproduction. Isolez sa base, désactivez planifications et rappels externes de production et remplacez accès ou destinations d'envoi par des équivalents de test contrôlés. Vérifiez les plateformes externes comme les emails générés en boutique.
4. Exécutez les contrôles de lancement ci-dessus et conservez profils obtenus, exemples de messages et preuves d'achat, retrait et nouvelle tentative. Vérifiez le thème réel, la commande invité, les langues, devises et contextes multiboutiques prévus.
5. Convenez du créneau et de l'émetteur à arrêter avant le démarrage de son remplaçant. Rapprochez les changements depuis la répétition, appliquez les derniers retraits et excluez les paniers périmés avant de libérer les tâches.
6. Activez le scénario convenu pour son audience définie. Surveillez échecs de file, événements de livraison, doublons et réponses d'assistance, avec une personne désignée pouvant suspendre les actions marketing concernées.

Pour le retour arrière, consignez comment suspendre planificateur, nouvelles tentatives et scénario externe, y compris les requêtes déjà acceptées par le prestataire. Rétablissez l'ancienne configuration en conservant nouvelles commandes, retraits et traces durables d'envoi. Restaurer une ancienne base boutique par-dessus les données commerciales actuelles peut perdre ces changements. Rapprochez les envois réels avant de libérer les tâches en attente par l'ancienne voie.

Questions à poser au développeur ou à l'agence

• Quelle solution de module installé et de plateforme fournit chaque événement requis, et quelles parties relèvent du suivi navigateur, de la synchronisation des contacts ou des données commerciales ?
• Où sont conservées les preuves d'autorisation, qui applique les retraits et qu'est-ce qui prouve qu'une nouvelle tentative ne peut pas réinscrire quelqu'un ?
• Quelles preuves montrent que les achats invités, paiements en attente, remboursements et tunnel réel fonctionnent comme convenu ?
• Qui gère tâches planifiées et échecs, où voit-on la dernière réussite et comment rejouer une tâche en échec sans doubler l'envoi ?
• Quels modèle, langue et expéditeur ont été testés, et où sont l'export de configuration, les étapes de bascule et le retour arrière ?

Avant la passation, faites démontrer l'analyse d'une tâche en échec et la suspension par l'employé qui exploitera le scénario. Fixez le prochain bilan selon livraison réelle, réclamations, achats et coûts, et répétez les cas de recette pertinents après changement de connecteur, thème ou tunnel de commande.

Questions des commerçants

Faut-il remplacer notre plateforme actuelle ?

Conservez-la si l'intégration installée peut démontrer le prochain scénario requis et si son coût convient à votre équipe. Un événement ou une correspondance d'autorisation manquants peuvent nécessiter une réparation ciblée plutôt qu'une migration de plateforme.

Peut-on garder les emails de commande dans PrestaShop et externaliser le marketing ?

Oui. Attribuez un expéditeur à chaque message et séparez les communications essentielles de commande des exclusions marketing. Désactivez les envois qui se chevauchent pour éviter que les deux systèmes annoncent le même événement.

L'inscription newsletter autorise-t-elle aussi les rappels de panier ?

Vérifiez l'autorisation réellement collectée et les règles du marché concerné. Ne déduisez pas l'autorisation de rappel d'une adresse, d'un compte ou d'une case sans rapport. Si les choix sont distincts, appliquez-les séparément.

Peut-on importer une ancienne liste clients et commencer les envois ?

Seulement après vérification de la provenance, de l'autorisation applicable, des preuves de confirmation et des exclusions actuelles. Un nouveau connecteur ou une nouvelle audience ne renouvelle pas l'autorisation, et l'import doit préserver les retraits.

Un connecteur gratuit rend-il tout le processus gratuit ?

Le compte externe, les frais d'envoi ou de canal, la mise en place et l'exploitation restent distincts. Incluez rédaction, examen des audiences et traitement des tâches en échec pour comparer les solutions.

Que lancer en premier ?

Choisissez le message utile dont vous pouvez déjà prouver les circuits de données et d'envoi. Lancez-le après test des sorties après achat et retrait, puis utilisez le résultat mesuré pour décider si une autre étape mérite sa place.