DataFirefly Server-Side — Guide complet

Présentation

DataFirefly Server-Side est le connecteur PrestaShop gratuit du service DataFirefly Server-Side Tracking. À chaque commande validée, le module construit un événement d’achat complet et l’envoie de serveur à serveur, signé HMAC-SHA256, vers le dispatcher DataFirefly hébergé dans l’UE (Allemagne). Le service diffuse ensuite l’événement vers vos destinations configurées : Meta Conversions API, GA4 Measurement Protocol, TikTok Events API, Pinterest Conversions API et Google Ads.

Le partage des rôles est simple : le module capte et signe, le service ingère, déduplique et diffuse. Le module est gratuit ; la diffusion nécessite un abonnement au service (Starter dès 39 €/mois).

Prérequis

• PrestaShop 1.7.6 ou supérieur, 8.x ou 9.x
• PHP 7.4 ou supérieur, avec l’extension cURL (présente sur la quasi-totalité des hébergements)
• Un compte DataFirefly Server-Side Tracking actif — abonnez-vous sur server-side.datafirefly.com
• Recommandé : notre module DataFirefly Cookie Manager (bandeau tarteaucitron conforme CNIL avec Google Consent Mode v2) pour la gate de consentement native

Installation

1. Téléchargez le ZIP du module depuis votre compte DataFirefly.
2. Dans le back-office PrestaShop, ouvrez Modules > Gestionnaire de modules > Installer un module et déposez le fichier datafirefly_serverside.zip.
3. Cliquez sur Installer. Le module s’enregistre sur le hook de validation de commande ; aucun override ni modification de thème n’est nécessaire.

À l’installation, le tracking est désactivé et l’exigence de consentement est activée : rien ne part tant que vous n’avez pas configuré et activé le module.

Récupérer vos identifiants

1. Connectez-vous à votre espace client DataFirefly (ou abonnez-vous si ce n’est pas encore fait).
2. Ouvrez la section Connecter votre boutique de votre site.
3. Copiez les trois valeurs affichées : le Tenant ID (au format shop_votreboutique_xxxx), le secret HMAC (clé de signature de 64 caractères) et l’endpoint d’événements.

Configuration

Ouvrez Modules > Gestionnaire de modules > DataFirefly Server-Side > Configurer. Le formulaire comporte cinq réglages :

• Activer le tracking — l’interrupteur principal. Tant qu’il est sur Non, aucun événement n’est envoyé.
• Tenant ID — l’identifiant de votre boutique dans le service, copié depuis votre espace client.
• Secret HMAC — la clé de signature de 64 caractères. Chaque événement est signé avec cette clé avant l’envoi.
• Events endpoint — l’URL d’ingestion du dispatcher. La valeur par défaut convient dans la quasi-totalité des cas ; ne la modifiez que si votre espace client vous en indique une autre.
• Exiger le consentement — activé par défaut. Quand il est actif, l’achat n’est transmis que si le visiteur a accordé un consentement marketing (voir ci-dessous). Désactivez-le uniquement si vous gérez le consentement en amont par un autre dispositif.

Enregistrez, puis passez au test.

Tester la connexion

Cliquez sur Envoyer un événement de test dans le formulaire de configuration. Le module envoie un page_view synthétique, signé, vers le dispatcher — sans toucher aux vraies commandes.

• « Événement de test livré » (HTTP 200) : votre Tenant ID, votre secret et votre endpoint sont corrects. Votre boutique est connectée, même si aucune destination n’est encore configurée côté service.
• « Événement de test échoué » : le code HTTP et le message du dispatcher s’affichent pour le diagnostic (voir Dépannage).

Le consentement (RGPD)

Quand Exiger le consentement est actif, le module lit — directement côté serveur, au moment de la validation de commande — le cookie de consentement au format tarteaucitron déposé par notre module DataFirefly Cookie Manager (Google Consent Mode v2). Le nom du cookie est repris automatiquement de la configuration du Cookie Manager (par défaut tarteaucitron).

L’achat est transmis si le visiteur a consenti à au moins un service publicitaire : Meta Pixel, Google Ads, TikTok Pixel ou LinkedIn Insight. L’approche est privacy-first : cookie absent ou illisible = pas d’envoi.

Si vous gérez le consentement avec un autre dispositif, désactivez Exiger le consentement et appliquez votre propre logique en amont : c’est alors à votre dispositif de garantir qu’aucune commande ne provient d’un visiteur non consentant.

Ce qui est envoyé

À chaque commande validée, le module construit un événement purchase avec :

• Transaction : montant payé, devise ISO, référence de commande, produits (id, nom, quantité, prix TTC unitaire) et nombre total d’articles.
• Données de correspondance : e-mail et identifiant client, téléphone, prénom, nom, ville, code postal et pays ISO de l’adresse de facturation (repli sur l’adresse de livraison).
• Identifiants navigateur capturés au moment de la commande : _fbp et _fbc (Meta), _ttp (TikTok) et le client id GA4 extrait du cookie _ga.

Chaque champ optionnel n’est ajouté que s’il est présent et valide : le dispatcher valide strictement, et un événement bien formé est un événement livré. L’identifiant d’événement est calé sur la commande (order_ID), de façon idempotente — c’est lui qui permet la déduplication client + serveur côté plateformes si vous utilisez aussi des tags navigateur.

Côté transport, chaque requête porte trois en-têtes : le tenant, l’horodatage (vérifié dans une fenêtre anti-rejeu de 300 secondes) et la signature HMAC-SHA256 du corps exact de la requête. Vos credentials Meta, GA4, TikTok, Pinterest et Google Ads restent dans votre espace DataFirefly : ni la boutique ni le navigateur ne les voient.

Suivre vos événements côté service

Dans votre espace client, l’Event Inspector vous montre les événements un par un, avec les données personnelles masquées (conforme RGPD). Vous y vérifiez ce qui est réellement livré à chaque destination. La disponibilité des plateformes est consultable à tout moment sur la page de statut publique.

Dépannage

L’événement de test échoue avec « not_configured »

L’un des trois champs (Tenant ID, secret, endpoint) est vide. Recopiez les trois valeurs depuis votre espace client et enregistrez avant de retester.

L’événement de test échoue en HTTP 401 ou 403

La signature est rejetée : le secret HMAC ne correspond pas au tenant, ou le Tenant ID est erroné. Recopiez les deux valeurs sans espace ni retour à la ligne. Vérifiez aussi que l’horloge de votre serveur est correcte (NTP) : un décalage supérieur à 300 secondes fait échouer la fenêtre anti-rejeu.

L’événement de test échoue avec « curl: … » ou HTTP 0

Votre serveur ne parvient pas à joindre le dispatcher : pare-feu sortant, DNS ou proxy. Autorisez les connexions HTTPS sortantes vers l’endpoint indiqué dans votre espace client.

Le test passe, mais aucune commande n’arrive

• Vérifiez que Activer le tracking est bien sur Oui.
• Si Exiger le consentement est actif, seules les commandes de visiteurs ayant consenti à un service publicitaire sont transmises. Passez une commande de test après avoir accepté les cookies publicitaires dans le bandeau.
• Consultez Paramètres avancés > Logs dans le back-office : chaque échec de livraison y est journalisé avec le code HTTP et l’identifiant de commande (préfixe [DataFirefly SS]).

Les conversions sont comptées deux fois

Impossible côté module : l’identifiant d’événement est idempotent par commande. Si vous utilisez aussi des tags navigateur en dehors du service, assurez-vous qu’ils envoient le même identifiant d’événement (order_ID) pour que les plateformes dédupliquent.

Désinstallation

La désinstallation supprime toute la configuration du module (tenant, secret, endpoint, réglages). Aucune table n’est créée en base : le module ne stocke rien d’autre que sa configuration.