DataFirefly Push — Guide complet

Présentation et prérequis

DataFirefly Push transforme votre boutique WooCommerce en plateforme de notifications Web Push native. Sans SDK, sans tracking de tiers : toute la cryptographie (VAPID et chiffrement RFC 8291) tourne sur votre serveur en PHP pur via OpenSSL. Le plugin couvre un opt-in intelligent multi-styles, dix triggers automatiques, des campagnes manuelles avec builder visuel et segmentation, un dashboard d’analytics complet, une page Mon compte dédiée pour vos clients, et une conformité RGPD native.

• WordPress 6.2 et supérieur.
• WooCommerce 7.0 et supérieur, testé jusqu’à 9.6, compatible HPOS et Cart/Checkout Blocks.
• PHP 8.1 et supérieur.
• Multilingue (FR/EN/ES/DE/IT), compatible Polylang et WPML.
• Compatible LiteSpeed Cache, WP Rocket et autres plugins de cache : le Service Worker est servi en standalone PHP.

Installation

1. Téléchargez l’archive df-push.zip depuis votre compte client.
2. Dans l’admin WordPress, allez dans Extensions > Ajouter > Téléverser une extension et déposez l’archive.
3. Cliquez sur Activer.
4. Le menu DF Push apparaît dans la barre latérale d’administration avec sept sous-menus : Dashboard, Campagnes, Abonnés, Triggers, Opt-in, Réglages, Webhooks & API.

À l’activation, le plugin crée huit tables dédiées préfixées dfpush_, génère vos clés VAPID, planifie le cron quotidien df_push_daily_lifecycle et enregistre l’endpoint Mon compte. Aucune intervention manuelle n’est requise.

Première configuration : clés VAPID et opt-in

Une fois activé, le plugin est immédiatement fonctionnel avec ses réglages par défaut : la cloche flottante apparaît en bas à droite après cinq secondes, le pre-prompt est activé, les triggers automatiques sont prêts. Vérifiez simplement deux choses dans DF Push > Réglages avant de communiquer sur le service :

• Clé publique VAPID : le bloc affiche votre clé publique générée automatiquement (l’application server key utilisée par le navigateur). Vous pouvez la régénérer mais cela invalidera tous les abonnements existants.
• Manifest PWA et icône par défaut : ajoutez votre icône (192×192 minimum) si site_icon n’est pas défini sur le site.

Onglet Opt-in — prompt, styles et déclencheurs

Cet onglet pilote la demande d’abonnement. Cinq styles disponibles, chacun positionnable et thématisable :

• Cloche flottante (par défaut) : pastille discrète en bas à droite ou en bas à gauche.
• Bannière en haut ou en bas de la page.
• Modal centré avec overlay.
• Slide-in latéral.
• Sticky bar fixée en haut.

Le pre-prompt soft ask (recommandé) affiche votre message personnalisé avant la demande native du navigateur. Ce mécanisme préserve votre quota d’opt-in : sur Chrome, refuser le pre-prompt n’épuise pas le quota de demandes natives (×3 contre 1 sans pre-prompt).

Cinq déclencheurs configurables, combinables :

• Délai (en secondes) après chargement de la page.
• Scroll en pourcentage de la page (0 = désactivé).
• Exit-intent au mouvement de sortie de la souris (desktop uniquement).
• X pages vues dans la session.
• Ajout au panier (capture l’événement WooCommerce added_to_cart).

Activez l’A/B test du prompt avec un titre et un message variante B, et un split configurable. La répartition est persistée en localStorage pour assurer une cohérence inter-sessions par visiteur.

Onglet Triggers — les automatismes

Dix triggers automatiques, tous activables individuellement depuis l’onglet Triggers. Chacun s’appuie sur Action Scheduler pour les envois différés, avec un fallback synchrone si Action Scheduler n’est pas disponible.

Panier abandonné

Trois relances configurables, par défaut à 1 heure, 24 heures et 72 heures après l’abandon. La détection capture l’événement added_to_cart pour les utilisateurs abonnés au Push et planifie trois actions df_push_abandoned_cart à intervalles décroissants. Les relances sont annulées automatiquement si la commande est passée entre-temps.

Retour en stock (back-in-stock)

Sur la page produit, vos visiteurs abonnés peuvent rejoindre une liste d’attente par produit. Quand WooCommerce déclenche woocommerce_product_set_stock_status avec un retour à instock, le plugin envoie une notification à la liste d’attente du produit, puis la vide.

Baisse de prix

Le plugin maintient une méta _df_push_last_price par produit. À chaque mise à jour de produit, il compare l’ancien et le nouveau prix. Si la baisse dépasse le seuil minimum en pourcentage configuré, une notification est envoyée au topic Promos.

Confirmation, expédition, avis

• Confirmation de commande : envoi immédiat sur woocommerce_thankyou à l’abonné si l’identifiant utilisateur correspond.
• Expédition : détecte le numéro de suivi sur la commande en lisant successivement les méta _tracking_number, _wc_shipment_tracking_items (WooCommerce Shipment Tracking) et _aftership_tracking_number (AfterShip). Si un numéro est trouvé, la notification l’inclut dans son message.
• Demande d’avis : programmée X jours après le passage de la commande au statut completed (délai configurable).

Anniversaire, réengagement, nouveau produit

• Anniversaire : le cron quotidien df_push_daily_lifecycle lit le champ billing_birthday de WooCommerce et envoie une notification aux abonnés dont c’est l’anniversaire.
• Réengagement : envoi aux abonnés inactifs depuis 30, 60 et 90 jours (fenêtres configurables en CSV : 30,60,90).
• Nouveau produit : à la publication d’un produit, une notification est envoyée au topic Nouveautés.

Onglet Campagnes — builder visuel, segmentation, A/B test

Construisez une campagne manuelle dans DF Push > Campagnes > Nouvelle campagne. Le builder propose un aperçu live de la notification telle qu’elle apparaîtra sur l’appareil de l’abonné.

• Contenu : titre, message, URL de destination, image hero, jusqu’à deux boutons d’action avec libellé et URL propres.
• Notification persistante (option requireInteraction) : la notification reste affichée jusqu’à interaction.
• Segmentation par langue, pays, device, topic, et par comportement RFM : commandes minimum, panier moyen minimum, jours d’inactivité, catégorie achetée. Les segments comportementaux sont calculés via wc_get_orders au lancement.
• A/B test : activez une variante B (titre et message), le split est configurable en pourcentage. La répartition est aléatoire par abonné, déterministe par identifiant pour la cohérence des analytics.
• Planification : choisissez la date et l’heure, ou lancez immédiatement.
• Mode test : envoyez la campagne aux administrateurs uniquement, depuis le builder, avant le lancement de production.

Le moteur d’envoi fragmente automatiquement le segment, respecte les quiet hours par fuseau horaire de l’abonné, applique le frequency capping configuré, et purge à la volée les endpoints qui retournent 404 ou 410 (désabonnement côté navigateur).

Dashboard et analytics

Le tableau de bord DF Push > Dashboard agrège vos KPIs sur 30 jours. Chart.js est bundlé localement (aucune dépendance CDN externe).

• KPIs : abonnés actifs, taux d’opt-in, envois, taux de clic (CTR), conversions, revenu attribué.
• Série temporelle 30 jours : envois versus clics, ligne par jour.
• Heatmap 7 × 24 : meilleurs créneaux d’envoi en fonction des clics, croisée jour de la semaine et heure de la journée.
• Funnel par campagne : envoyé > livré > cliqué > converti.
• Revenu attribué : une fenêtre d’attribution configurable (par défaut 72 heures) lie chaque clic au premier achat passé dans la fenêtre par cet abonné.
• Export CSV de tous les événements pour audit RGPD ou intégration BI.

Page client : Mon compte → Notifications

Une page dédiée Mon compte → Notifications est ajoutée automatiquement au tableau de bord WooCommerce. Le client y dispose de quatre blocs :

• Cet appareil : statut courant (activé, désactivé, bloqué par le navigateur, non supporté), avec bouton Activer ou Désactiver sur cet appareil.
• Tous vos appareils : liste des devices abonnés (type, navigateur, langue, dernière activité), avec désabonnement individuel ou désabonnement total en un clic.
• Mes préférences : cases à cocher pour les topics natifs (Nouveautés, Promotions, Retour en stock). Sauvegarde via REST avec confirmation.
• Historique des notifications : les 30 dernières notifications reçues, avec titre, corps, icône, lien et date.

L’URL est /mon-compte/df-push-notifications/ en français. Le rewrite endpoint est enregistré au mask EP_ROOT | EP_PAGES, avec un auto-réparateur sur init:999 qui détecte une règle manquante (cas d’un permalink flush concurrent) et reflush automatiquement.

RGPD et registre de consentement

La conformité RGPD est traitée nativement, pas en ajout cosmétique. Chaque opt-in et chaque désabonnement est inscrit dans la table dfpush_consent_log avec :

• Identifiant de l’abonné.
• Action : subscribe ou unsubscribe.
• IP hashée en SHA-256 (l’IP en clair n’est jamais persistée).
• User-agent.
• Horodatage UTC.

Les WordPress Privacy Exporters et Erasers natifs sont branchés : un client peut demander l’export ou l’effacement de ses données personnelles depuis Outils → Exporter les données personnelles ou Outils → Effacer les données personnelles. Le plugin inclut alors ses abonnements, ses topics, son inbox et son registre de consentement dans la réponse — ou les supprime selon la demande.

Onglet Réglages — anti-spam et attribution

Cet onglet centralise les paramètres de respect des abonnés et la fenêtre d’attribution :

• Heures calmes (quiet hours) : intervalle pendant lequel aucune notification n’est envoyée. Sensible au fuseau horaire de l’abonné (lu sur sa device au moment de l’opt-in via Intl.DateTimeFormat().resolvedOptions().timeZone). Par défaut 22h-8h locales.
• Frequency cap : nombre maximum de notifications par jour par abonné. 0 = illimité.
• Smart send time : optimise l’heure d’envoi par abonné en se basant sur ses créneaux de clic historiques.
• Fenêtre d’attribution : durée en heures entre un clic et une commande pour que la commande soit attribuée à la notification. Par défaut 72 heures.
• Inbox in-site : active ou désactive la cloche flottante avec l’historique des notifications côté front.
• Manifest PWA : active la génération du manifest pour rendre le site installable sur mobile.

Onglet Webhooks et API REST

L’onglet Webhooks & API couvre deux mécanismes d’intégration.

Webhooks sortants

Configurez un ou plusieurs endpoints HTTP par événement. Trois formats sont disponibles :

• Slack : payload { text } compatible avec les Incoming Webhooks Slack.
• Discord : payload { content } compatible avec les Webhooks Discord.
• Generic : payload JSON complet avec event, timestamp, data — compatible Zapier, n8n, Make.

Les événements disponibles : subscriber.created, campaign.launched, notification.clicked, order.attributed. Les requêtes sont non-bloquantes (wp_remote_post avec blocking=false) pour ne jamais ralentir l’envoi principal.

API REST

Sous le namespace df-push/v1, le plugin expose une route publique d’envoi tokenisée : POST /wp-json/df-push/v1/send avec l’en-tête X-DF-Push-Token. Le token est régénérable en un clic depuis l’admin.

curl -X POST https://votre-site.com/wp-json/df-push/v1/send 
  -H "Content-Type: application/json" 
  -H "X-DF-Push-Token: VOTRE_TOKEN" 
  -d '{
    "title": "Promo flash",
    "body": "20 % sur tout le catalogue jusqu'à minuit",
    "url": "https://votre-site.com/promotions",
    "segment": { "lang": "fr", "topic": "promos" }
  }'

Inbox in-site, PWA et multilingue

Trois fonctions complémentaires couvrent les cas où l’utilisateur n’a pas autorisé le Push.

• Inbox in-site : une cloche flottante (configurable côté front) ouvre une liste des dernières notifications reçues par l’utilisateur, lues ou non, même s’il n’a jamais autorisé le Push. Particulièrement utile pour iOS Safari avant 16.4 et les utilisateurs PWA.
• Manifest PWA : généré dynamiquement à /df-push-manifest.json à partir de site_icon ou d’une icône personnalisée. Filtre df_push_manifest disponible pour ajuster theme color, display, scope, start_url.
• Multilingue : compatible Polylang et WPML. Les notifications sont envoyées dans la langue de l’abonné (détectée à l’opt-in), avec fallback sur la langue par défaut du site. Les fichiers .po et .mo en FR, EN, ES, DE, IT sont inclus.

Service Worker et architecture technique

Le Service Worker est servi par un fichier PHP standalone à l’URL /wp-content/plugins/df-push/sw.php. Cette approche court-circuite complètement le routing WordPress : aucune chance d’interférence avec un plugin de cache, un canonical redirect ou un autre handler template_redirect.

L’en-tête Service-Worker-Allowed: / est envoyé en réponse pour permettre l’enregistrement avec le scope racine (scope: '/'), bien que le script vive sous /wp-content/.

Côté base de données, huit tables préfixées dfpush_ :

• dfpush_subscribers : abonnés et leur endpoint Push.
• dfpush_topic_subs : assignations topic ↔ abonné.
• dfpush_campaigns : campagnes manuelles avec payload, segment et planification.
• dfpush_notifications : journal des notifications individuelles envoyées.
• dfpush_events : événements bruts (opt-in, sent, delivered, clicked, converted) pour l’analytics.
• dfpush_inbox : copie persistante des notifications pour l’inbox in-site.
• dfpush_stock_waitlist : listes d’attente de retour en stock.
• dfpush_consent_log : registre RGPD.

L’uninstall (suppression complète depuis Extensions) drop ces huit tables et purge toutes les options. La désactivation simple, elle, conserve les données pour une réactivation ultérieure.

Hooks développeur

Le plugin expose des actions et filtres aux points clés pour étendre son comportement sans modifier le cœur.

• df_push_booted (action) : déclenchée après le boot du plugin, utile pour enregistrer des extensions personnalisées.
• df_push_payload_build (filtre) : modifier le payload JSON envoyé au push service avant chiffrement.
• df_push_should_send (filtre) : court-circuiter l’envoi sur conditions personnalisées (renvoyer false pour skip).
• df_push_segment_query (filtre) : enrichir les critères de segmentation comportementale.
• df_push_webhook_payload (filtre) : ajuster les payloads des webhooks sortants.
• df_push_manifest (filtre) : modifier le manifest PWA généré.
• Actions Scheduler enregistrées : df_push_send_one, df_push_fan_out, df_push_abandoned_cart, df_push_review_request, df_push_dispatch_campaign.

FAQ et dépannage

Le prompt d’opt-in ne s’affiche pas

Trois causes possibles : la permission navigateur est déjà refusée (vérifiez dans les réglages du navigateur), la permission est déjà accordée (le prompt n’a plus lieu d’être), ou un déclencheur n’a pas été atteint (délai non écoulé, scroll insuffisant). Dans la console JavaScript, exécutez window.DFPush.isSubscribed() pour vérifier l’état courant.

L’admin Abonnés est vide alors qu’un opt-in a réussi

Vérifiez dans la console réseau que la requête POST /wp-json/df-push/v1/subscribe renvoie bien un code 200. À partir de la version 1.0.1, le plugin re-synchronise automatiquement toute PushSubscription existante avec le serveur sur chaque chargement de page, et logue toute erreur d’insertion DB dans error_log.

Le Service Worker renvoie une erreur d’enregistrement

Si l’erreur navigateur est « The script resource is behind a redirect » ou « Unexpected token ‘<‘ », testez directement l’URL https://votre-site.com/wp-content/plugins/df-push/sw.php. Vous devez voir le code JavaScript du Service Worker avec un Content-Type: application/javascript et le header Service-Worker-Allowed: /. Si vous voyez un HTML 403, vérifiez les règles htaccess qui pourraient bloquer l’exécution directe de fichiers PHP sous wp-content/plugins/.

Les notifications ne sont pas reçues sur iOS

Safari sur iOS ne supporte les notifications Push que depuis la version 16.4 et uniquement pour les sites installés en PWA via le bouton Ajouter à l’écran d’accueil. Le manifest PWA généré par le plugin facilite cette installation. Si vous ne ciblez pas spécifiquement iOS, ce n’est pas un problème : les autres navigateurs reçoivent les notifications normalement.

Comment migrer depuis OneSignal ou Pusher

Les abonnés existants chez ces services tiers ne sont pas portables : la cryptographie Push lie chaque abonnement à un couple unique (clé VAPID du serveur, endpoint navigateur). Vos visiteurs devront se réabonner après votre passage à DataFirefly Push. Vous pouvez préparer la transition en désactivant l’ancien SDK quelques jours avant et en communiquant via une bannière de pré-annonce sur la nouvelle expérience.

Que se passe-t-il à la désinstallation ?

La désactivation simple conserve toutes les tables et options : vous pouvez réactiver le plugin et reprendre où vous en étiez. La suppression complète depuis Extensions exécute uninstall.php qui drop les huit tables dfpush_, purge toutes les options du plugin (y compris les clés VAPID et le token API), et déprogramme les crons. Les permaliens sont automatiquement flushés à la prochaine requête.