DataFirefly Waitlist — Documentation

Présentation

DataFirefly Waitlist ajoute une alerte de retour en stock à votre boutique PrestaShop 8 ou 9. Dès qu’un produit — ou une combinaison précise — passe sous le seuil de stock configuré, un bouton « M’avertir du retour en stock » apparaît automatiquement sur la fiche produit. Le visiteur laisse son email, et reçoit une alerte dès le réapprovisionnement. Chaque commande passée ensuite par un inscrit notifié est attribuée comme conversion dans le dashboard.

Installation

1. Dans le back-office, allez dans Modules → Gestionnaire de modules → Installer un module.
2. Uploadez le fichier dfwaitlist-x.x.x.zip.
3. Cliquez sur Installer. Le module crée la table df_dfwaitlist_subscriber, enregistre ses hooks et ajoute son onglet d’administration.
4. Ouvrez la configuration pour renseigner l’email commerçant et récupérer l’URL du cron.

Configuration

Rendez-vous dans Modules → DataFirefly Waitlist → Configurer. Les réglages disponibles :

• Double opt-in — quand il est actif, l’inscription envoie d’abord un email de confirmation. Tant que le visiteur n’a pas cliqué, l’inscription reste non confirmée et ne déclenchera aucune alerte. Désactivable si vous préférez l’inscription instantanée.
• Seuil de stock — quantité en dessous de laquelle un produit est considéré comme indisponible et fait apparaître le bouton.
• Seuil d’alerte commerçant — nombre d’inscrits sur un même produit à partir duquel vous recevez un email de notification. 10 par défaut.
• Email commerçant — destinataire de l’alerte ci-dessus.
• Durée de vie des inscriptions — les inscriptions jamais notifiées sont purgées automatiquement au-delà de N jours. 90 par défaut.
• Texte du bouton — personnalisable par langue.
• Mention RGPD — texte affiché sous le formulaire, personnalisable par langue.
• URL du cron — sécurisée par token, régénérable d’un clic depuis le back-office.

Fonctionnement côté client

Apparition du bouton

Le bouton est injecté via le hook displayProductActions et sa visibilité est décidée côté client. Le module interroge l’endpoint /modules/dfwaitlist/stockcheck pour connaître l’état de stock réel de la combinaison affichée — ce qui le rend indépendant du comportement de re-rendu AJAX du thème. Résultat : le bouton disparaît si la variante sélectionnée est disponible, et réapparaît sinon, sans rechargement de page.

Combinaisons (déclinaisons)

L’inscription se fait par couple (produit, combinaison). Le formulaire affiche explicitement la variante concernée, par exemple « Variante : Rouge / Taille L ». Quand le visiteur change de déclinaison avant de valider, la cible bascule automatiquement. L’email d’alerte mentionne la combinaison exacte et pointe vers la fiche avec la variante pré-sélectionnée : aucune confusion possible entre une taille et une autre.

Confirmation (double opt-in)

Avec le double opt-in actif, l’inscrit reçoit un email contenant un lien de confirmation tokené. L’inscription n’est prise en compte qu’après le clic. Ce mécanisme garantit la qualité de la liste (pas d’emails fantaisistes) et fournit une preuve de consentement explicite.

Alerte de retour en stock

Au réapprovisionnement, l’inscrit reçoit un email HTML responsive avec le nom du produit, la combinaison concernée et un lien direct vers la fiche. Chaque email contient un lien de désinscription en un clic.

Détection des retours en stock

Deux canaux complémentaires, à laisser actifs tous les deux :

1. Hook actionUpdateQuantity — temps réel. Dès qu’un employé modifie un stock dans le back-office, ou qu’une commande annulée libère du stock, les emails partent immédiatement.
2. Cron de filet — sécurisé par token. Il rattrape les mouvements de stock qui ne passent pas par les hooks : imports API, synchronisation ERP, scripts CLI, mises à jour via le Webservice PrestaShop.

Mise en place du cron

Copiez l’URL affichée dans la configuration du module (elle contient le token de sécurité) et branchez-la sur un appel horaire :

0 * * * * curl -s "https://votre-boutique.com/module/dfwaitlist/cron?token=VOTRE_TOKEN" > /dev/null 2>&1

Tracking de conversion

Sur le hook actionValidateOrder, le module compare chaque ligne de la commande aux inscriptions en statut « notifié ». La correspondance se fait sur le triplet (email, id_product, id_product_attribute). En cas de match, l’inscription est marquée comme convertie et l’id_order est enregistré.

Le tracking étant basé sur l’email et non sur le compte client, il fonctionne aussi bien pour les commandes invité que pour les clients connectés.

Dashboard admin

• 6 KPI — inscrits, en attente de confirmation, notifiés, achats, taux de conversion, désinscrits.
• Liste des produits avec demandes — triable et paginée. C’est votre liste de priorités de réassort : un produit avec 47 inscrits, ce sont 47 ventes quasi acquises si vous réapprovisionnez vite.
• Vue détaillée par produit — chaque inscrit avec son statut individuel.
• Export CSV — export complet de la boutique active : email, produit, combinaison, statuts (confirmé, notifié, acheté, désinscrit), dates, IP, id de commande en cas de conversion. Le fichier inclut un BOM UTF-8 pour s’ouvrir directement dans Excel sans casse d’encodage.

Alerte commerçant

Quand un produit en rupture atteint le seuil d’inscrits configuré, un email automatique vous prévient avec le nombre d’attentes et un lien vers le dashboard. L’email n’est envoyé qu’une fois par produit, pour éviter le bruit. C’est le signal qui transforme votre liste d’attente en outil de pilotage du réassort : vous priorisez sur de la demande mesurée, pas sur de l’intuition.

Emails

Trois modèles, chacun fourni en FR/EN/ES/DE au format HTML responsive + texte brut :

• Confirmation — envoyé uniquement si le double opt-in est actif, avec le lien d’activation.
• Alerte retour en stock — produit, combinaison, lien direct vers la fiche, lien de désinscription.
• Alerte commerçant — nombre d’inscrits en attente et lien vers le dashboard.

Les modèles sont modifiables dans modules/dfwaitlist/mails/<iso>/.

RGPD et qualité de liste

• Double opt-in activable, avec preuve de consentement (l’IP est enregistrée à l’inscription).
• Désinscription en un clic dans chaque email d’alerte, via un token unique distinct du token de confirmation. L’inscription est marquée désinscrite sans être supprimée, pour conserver la traçabilité, et aucun email futur ne part.
• Purge automatique des inscriptions jamais notifiées au-delà de la durée configurée (90 jours par défaut) — minimisation des données.
• Honeypot anti-bot intégré au formulaire, et limite d’un seul email par produit pour éviter les inscriptions en rafale.
• Aucun appel externe : les données restent dans la base PrestaShop, scopées par boutique. Rien n’est envoyé à DataFirefly ni à un service tiers.

Multi-boutique et multilingue

La table d’inscriptions porte les colonnes id_shop et id_lang. Chaque sous-boutique d’un réseau multi-shop dispose donc de sa propre liste d’attente, de ses propres alertes commerçant et de ses propres KPI. Les emails partent dans la langue de l’inscrit au moment de l’inscription.

Dépannage

Le bouton n’apparaît pas

• Vérifiez que le produit est bien sous le seuil de stock configuré — au-dessus, le bouton est masqué volontairement.
• Sur un produit à déclinaisons, vérifiez la variante sélectionnée : le bouton ne s’affiche que si cette variante est indisponible.
• Le thème doit implémenter le hook displayProductActions. C’est le cas de Classic et Hummingbird ; sur un thème custom exotique, vérifiez sa présence dans le template produit.
• Videz le cache PrestaShop (Paramètres avancés → Performances).

Les alertes ne partent pas au réappro

• Vérifiez que l’inscription est confirmée : avec le double opt-in, une inscription non confirmée ne reçoit jamais d’alerte.
• Si le stock a été modifié hors back-office (API, ERP, CLI), le hook temps réel ne se déclenche pas — c’est le cron qui prend le relais. Vérifiez qu’il tourne bien et que le token de l’URL est à jour.
• Testez l’envoi d’email PrestaShop en général (Paramètres avancés → E-mail → Test).

Des conversions ne sont pas comptabilisées

La correspondance exige l’email et le produit et la combinaison. Si le client commande avec une autre adresse email que celle de son inscription, ou achète une déclinaison différente de celle qu’il attendait, la conversion n’est pas attribuée — c’est volontaire, pour éviter les faux positifs qui fausseraient vos KPI.

Désinstallation

La désinstallation supprime la table df_dfwaitlist_subscriber et toutes les clés de configuration préfixées DFWAITLIST_. Aucune trace ne subsiste en base. Une confirmation est demandée, puisque les inscriptions et les statistiques de conversion seront définitivement perdues — exportez le CSV avant si vous souhaitez conserver l’historique.