Options Avancées
Ajustez finement la façon dont le pixel se charge, gérez les modules de paiement non standards, excluez des clients ou commandes spécifiques du suivi, et configurez des sélecteurs personnalisés pour les thèmes qui s'écartent de la mise en page standard de PrestaShop.
Disponible depuis v2.0
Vue d'ensemble
Le panneau Options Avancées couvre des cas particuliers et des exigences de compatibilité qui n'affectent pas la plupart des boutiques. Si votre pixel suit correctement et que vos événements Purchase sont exacts, vous pouvez laisser tout ici à ses valeurs par défaut.
Vous aurez besoin de ce panneau lorsque :
- Votre thème n'inclut pas le hook footer standard de PrestaShop, donc le pixel ne se déclenche jamais
- Les commandes d'un module de paiement spécifique ne sont pas suivies car il utilise un flux non standard
- Des commandes du personnel, des commandes de revendeurs ou des achats de test internes apparaissent dans vos statistiques de campagne Meta
- Votre CDN ou le cache serveur diffuse une version obsolète du script du pixel
- Votre thème utilise un bouton personnalisé pour Ajouter au Panier, ou un module de checkout non standard
Le panneau est divisé en plusieurs sections : Optimisation du Chargement du Pixel, Options de Conversion, Événement de Remboursement/Annulation, Filtrage des Clients, Options d'Affichage, Options d'Inscription, Options PageView, Détection Initiate Checkout, Prévention du Cache et Sélecteurs Personnalisés. Chaque section est décrite ci-dessous.
Configuration
Optimisation du Chargement du Pixel
Ces paramètres contrôlent où et quand le script du pixel est injecté dans les pages de votre boutique.
| Champ | Défaut | Description |
|---|---|---|
| Forcer les Pixels dans l'En-tête | Désactivé | Charge le pixel dans le <head> au lieu du footer. Activez uniquement lorsque votre thème n'inclut pas le hook footer de PrestaShop. L'approche par le footer est préférée car elle évite de bloquer le rendu de la page. |
| Chargement différé | Désactivé | Retarde l'initialisation du pixel jusqu'à ce que la page ait fini de se charger. Peut réduire le temps de chargement perçu sur les connexions lentes, mais toute action du client effectuée avant la fin du délai ne sera pas suivie. |
| Secondes de différé | 0 | Secondes à attendre après le chargement complet de la page avant que le pixel s'initialise. Valeur recommandée : 2 à 3 secondes lorsque le chargement différé est activé. Nombres entiers uniquement. |
| Différer seulement la première fois | Activé | Applique le chargement différé uniquement sur la première page d'une session. Sur les pages suivantes, le script du pixel est déjà dans le cache du navigateur et se charge instantanément, donc le différé n'est pas nécessaire. Laissez ceci activé chaque fois que le chargement différé est actif. |
Forcer les Pixels dans l'En-tête et Chargement différé répondent à des problèmes différents. Si vous activez les deux, le pixel se déclenche immédiatement depuis l'en-tête — le différé n'a aucun effet. Choisissez une approche selon votre situation.
Options de Conversion
Ces paramètres contrôlent comment les événements Purchase sont déclenchés et validés.
| Champ | Défaut | Description |
|---|---|---|
| Exclure les commandes du Back Office | Activé | Les commandes créées depuis le Back Office (par le personnel) ne déclenchent pas d'événement Purchase. Laissez ceci activé sauf si vous souhaitez spécifiquement suivre les commandes du personnel. |
| Utiliser Ajax pour confirmer que la conversion est envoyée | Activé | Le navigateur valide la disponibilité du pixel via AJAX avant de déclencher l'événement Purchase. Cela évite de manquer des événements pour les modes de paiement qui redirigent le client hors de la page de confirmation standard. Recommandé — laissez activé. |
| Utiliser des Cookies pour prévenir les doublons de conversion | Désactivé | Empêche l'événement Purchase de se déclencher une seconde fois pour la même commande si la page de confirmation est rechargée ou servie depuis le cache. Activez ceci si vous constatez des conversions en double causées par un module de cache ou Cloudflare. |
| Forcer le mode Basique de l'événement Purchase pour | Aucun | Cases à cocher par module de paiement. Le mode Basique force l'événement Purchase à se déclencher lorsque le client visite la page de confirmation de commande, en contournant le flux de détection standard. Requis pour les modules de paiement qui utilisent des flux de confirmation de commande non standards. Activez uniquement pour les méthodes de paiement spécifiques qui en ont besoin. Remarque : le mode basique ne prévient pas les doublons à lui seul — activez aussi le mode cookie si des doublons se produisent. |
| Recharger après la commande ? | Désactivé | Force un rechargement de page unique après le chargement de la page de confirmation de commande. Pour un petit nombre de modules de paiement qui affichent la confirmation avant que la commande soit entièrement validée dans PrestaShop. Généralement pas nécessaire. |
| Exclure la livraison du total de la commande | Désactivé | Rapporte le total de la commande sans les frais de livraison dans le champ valeur de l'événement Purchase. La livraison est enregistrée comme un champ personnalisé dans l'événement. |
| Envoyer le montant de la commande avec les taxes ? | Activé | Lorsqu'activé, la valeur Purchase inclut les taxes. Désactivez pour rapporter des montants hors taxes. |
| Suivre uniquement les commandes Paiement Validé | Désactivé | Fonctionnalit é bêta. Lorsqu'activée, seules les commandes atteignant un statut de paiement validé déclenchent immédiatement un événement Purchase. Les commandes au paiement non validé sont conservées jusqu'au nombre de jours défini ci-dessous. Si elles sont validées dans ce délai, l'événement Purchase est envoyé rétroactivement via l'API Conversions. Nécessite que le CAPI soit configuré. |
| Limite de validation des commandes non validées | 7 jours | Nombre de jours pendant lesquels une commande en attente est conservée avant d'être abandonnée. S'applique uniquement lorsque "Suivre uniquement les commandes Paiement Validé" est activé. |
| Statuts de commande à exclure | Aucun | Les événements Purchase sont supprimés lorsqu'une commande atteint l'un des statuts sélectionnés. Utilisez ceci pour exclure les statuts de commande signalés comme frauduleux, de test ou administratifs. |
Mode Débogage de l'événement Purchase (décrit ci-dessous sous Filtrage des Clients) contourne toute la logique de déduplication. Ne le laissez jamais actif sur une boutique en production.
Événement de Remboursement / Annulation
L'événement Refund est le signal de remboursement canonique CAPI uniquement. La configuration et les notes se trouvent à la source unique de vérité dans Événement Refund.
Filtrage des Clients
Ces paramètres vous permettent de supprimer les événements Purchase pour des clients ou groupes spécifiques.
| Champ | Défaut | Description |
|---|---|---|
| Groupes de clients à exclure | Aucun | Les événements Purchase sont supprimés pour les clients appartenant aux groupes sélectionnés (par exemple, Employés, Revendeurs, Interne). Ceci est un paramètre par boutique. |
| ID Client à exclure | — | Liste d'IDs clients PrestaShop séparés par des virgules. Les événements Purchase sont supprimés pour ces clients spécifiques. Ceci est un paramètre global — il s'applique à toutes les boutiques dans une configuration multi-boutique. |
| Mode Débogage de l'événement Purchase | Désactivé | Contourne toute la logique de déduplication et permet à la même commande de déclencher l'événement Purchase plusieurs fois. À utiliser uniquement pour les tests dans un environnement de développement. Provoque des statistiques gonflées dans Meta si laissé activé. |
Options d'Affichage
| Champ | Valeurs | Défaut | Description |
|---|---|---|---|
| Utilisation de l'External ID | Uniquement pour les utilisateurs enregistrés / Tous les utilisateurs | Uniquement pour les utilisateurs enregistrés | Contrôle quand l'identifiant de correspondance inter-appareils (external_id) est généré. La valeur par défaut est recommandée : générer un external_id pour les visiteurs invités puis un différent après leur inscription crée deux IDs pour la même personne, ce qui peut causer des problèmes d'attribution dans Meta. |
Options d'Inscription
| Champ | Défaut | Description |
|---|---|---|
| Utiliser Ajax pour confirmer les Inscriptions Client | Activé | Valide les événements CompleteRegistration via AJAX. Recommandé — laissez activé. |
Options PageView
| Champ | Défaut | Description |
|---|---|---|
| Restreindre PageView aux contrôleurs connus | Désactivé | Lorsqu'activé, les événements PageView ne se déclenchent que sur les pages PrestaShop standards : produit, catégorie, panier, checkout, CMS et pages de contact. Lorsque désactivé, PageView se déclenche sur chaque page y compris les erreurs 404 et les pages de modules personnalisés. |
Détection Initiate Checkout
| Champ | Valeurs | Défaut | Description |
|---|---|---|---|
| Mode Initiate Checkout | Page initiale / Clic sur le bouton | Page initiale | Page initiale déclenche l'événement InitiateCheckout lorsque le client arrive pour la première fois sur le checkout. Clic sur le bouton se déclenche lorsque le client clique explicitement sur "Passer commande". Utilisez le mode bouton si vous constatez des événements InitiateCheckout en double dans le Gestionnaire d'Événements Meta. |
Prévention du Cache
| Champ | Valeurs | Défaut | Description |
|---|---|---|---|
| Prévention du Cache des Fichiers Statiques | Désactivé / Toujours / Quotidien / Hebdomadaire / Mensuel / Trimestriel | Désactivé | Ajoute un paramètre dynamique anti-cache aux URLs des fichiers statiques de Pixel Plus. Activez uniquement lorsqu'un CDN ou un cache serveur (LiteSpeed, Nginx, Cloudflare) diffuse une version obsolète du script du pixel après une mise à jour du module. Choisissez une fréquence adaptée à la fréquence de mise à jour du module. |
| Prévention du Cache Améliorée | Désactivé / Activé | Désactivé | Ajoute des paramètres supplémentaires aux appels AJAX pour empêcher les réponses en cache d'interférer avec le suivi. Activez uniquement si vous rencontrez des événements manquants ou un comportement du pixel incohérent causé spécifiquement par la mise en cache au niveau serveur. |
Sélecteurs Personnalisés
Ces champs sont destinés aux boutiques dont les thèmes ou modules ne correspondent pas à la mise en page standard de PrestaShop.
| Champ | Description |
|---|---|
| Sélecteur personnalisé Ajouter au Panier | Sélecteur jQuery ou CSS pour un bouton Ajouter au Panier personnalisé. À utiliser lorsque votre thème remplace le bouton par défaut et que les événements AddToCart ne se déclenchent pas. |
| Sélecteur de démarrage de personnalisation | Sélecteur CSS pour un bouton de personnalisation produit — un bouton que le client doit cliquer avant de personnaliser un produit. Laissez vide si votre boutique n'utilise pas la personnalisation de produit. |
| Nom du module (Page de Checkout Personnalisée) | Nom technique d'un module de checkout personnalisé si votre boutique n'utilise pas le checkout standard de PrestaShop. Utilisé pour déclencher les événements InitiateCheckout depuis les pages du module personnalisé. |
| Contrôleur de recherche | Nom du contrôleur d'un module de recherche personnalisé. Visible dans l'URL après le paramètre controller= lorsqu'une recherche est effectuée. Laissez vide pour utiliser le SearchController par défaut de PrestaShop. |
| Paramètre de requête de recherche | Nom du paramètre URL pour la chaîne de requête de recherche. Valeurs courantes : s, q, term. Laissez vide pour utiliser la valeur par défaut. |
Fonctionnement
Stratégie de Chargement du Pixel
Par défaut, le script du pixel se charge dans le footer. C'est l'approche la plus sûre : les scripts en footer ne bloquent pas le rendu de la page, donc votre boutique semble se charger plus rapidement. Si votre thème n'inclut pas les hooks displayFooter ou displayBeforeBodyClosingTag, le pixel ne se déclenche jamais — activez Forcer les Pixels dans l'En-tête pour l'injecter depuis la balise <head> à la place.
Le chargement différé est une troisième option : le pixel attend que la page entière ait fini de s'afficher avant de s'initialiser. Cela peut améliorer les scores PageSpeed car le pixel n'est plus dans le chemin de rendu critique. La contrepartie est que les actions du visiteur effectuées immédiatement après le chargement de la page — avant que le délai configuré ne soit écoulé — ne seront pas capturées. Le raffinement "Différer seulement la première fois" résout la majeure partie de ce problème : une fois que le script du pixel est dans le cache du navigateur depuis une page précédente de la même session, il se charge quasi instantanément et le différé devient inutile.
Livraison de l'Événement Purchase
La plupart des modules de paiement suivent un flux standard : le client termine le paiement, le module de paiement redirige vers la page de confirmation de commande de PrestaShop, et le module déclenche l'événement Purchase depuis là. Lorsqu'un module de paiement utilise sa propre page de confirmation ou redirige le client en dehors du flux standard de PrestaShop, la détection standard échoue. Forcer le mode Basique de l'événement Purchase indique au module de se rabattre sur le déclenchement à l'URL de la page de confirmation, quelle que soit la façon dont la commande a été créée.
Utiliser Ajax pour confirmer que la conversion est envoyée ajoute une couche de validation : avant de déclencher l'événement Purchase depuis le navigateur, le module vérifie via AJAX que la commande a été correctement enregistrée. Cela évite que l'événement se déclenche à tort lorsqu'une redirection de paiement interrompt le chargement normal de la page.
Filtrage des Clients
L'exclusion de groupe de clients (FCTP_ORDER_CUSTOMER_GROUP_EXC) est évaluée au moment où l'événement Purchase serait normalement envoyé. Si le client passant la commande appartient à un groupe exclu, l'événement est silencieusement ignoré. La commande est traitée normalement dans PrestaShop — seul le suivi Meta est supprimé.
L'exclusion d'ID client (FCTP_ORDER_CUSTOMER_ID_EXCLUDE) fonctionne de la même manière pour des individus spécifiques plutôt que des groupes. Étant un paramètre global, elle s'applique à toutes les boutiques dans une configuration multi-boutique — utile pour exclure un compte utilisé pour des tests réguliers inter-boutiques.
Exemples d'Utilisation
Exemple : Thème sans hook footer
Votre boutique utilise un thème personnalisé construit sans les hooks footer standards de PrestaShop. Le pixel ne se déclenche jamais car le point d'injection du footer n'existe pas. Activez Forcer les Pixels dans l'En-tête — le pixel est alors injecté dans le <head> de chaque page, que tous les thèmes incluent.
Exemple : Commandes du personnel et de revendeurs gonflant les statistiques de conversion Vous remarquez que votre nombre d'événements Purchase Meta est supérieur à vos ventes clients réelles car les commandes du personnel et des revendeurs sont incluses. Ajoutez vos groupes de clients "Employés" et "Revendeurs" à Groupes de clients à exclure. À partir de ce moment, les commandes de ces groupes ne génèrent plus d'événement Purchase, tandis que les commandes elles-mêmes continuent d'être traitées normalement dans PrestaShop.
Exemple : Événements Purchase en double dus à un cache de page Votre boutique utilise un plugin de cache de page complète et vous constatez des événements Purchase en double pour la même commande dans Meta. Activez Utiliser des Cookies pour prévenir les doublons de conversion — le module définit un cookie de courte durée lorsque l'événement Purchase se déclenche, et si la page de confirmation se recharge (depuis le cache) le cookie empêche l'envoi d'un second événement.
Exemple : CDN diffusant un script de pixel obsolète Après une mise à jour de Pixel Plus, certains visiteurs déclenchent encore des événements avec l'ancienne logique de suivi car votre CDN a mis en cache l'ancienne version du script. Définissez Prévention du Cache des Fichiers Statiques sur Hebdomadaire — cela ajoute un paramètre basé sur la date à l'URL du script qui change chaque semaine, forçant le CDN à récupérer et diffuser le fichier mis à jour.
Exemple : InitiateCheckout se déclenchant deux fois Vous voyez deux événements InitiateCheckout par session de checkout dans le Gestionnaire d'Événements Meta. Cela se produit lorsque le client arrive à la fois sur la page de checkout et clique sur un bouton "Continuer", les deux déclenchant l'événement. Passez le Mode Initiate Checkout de Page initiale à Clic sur le bouton pour que l'événement ne se déclenche que sur le clic explicite.
Remarques Importantes
- Forcer les Pixels dans l'En-tête et Chargement différé peuvent être activés en même temps, mais le résultat est que le placement dans l'en-tête l'emporte : le script se charge immédiatement depuis le
<head>. Il n'y a aucun bénéfice combiné — choisissez l'option adaptée à votre situation. - Mode Débogage de l'événement Purchase ne doit jamais rester actif sur une boutique en production. Il contourne toutes les vérifications de déduplication et provoque un nombre gonflé d'événements Purchase dans Meta, ce qui corrompt les données d'optimisation des campagnes.
- ID Client à exclure est un paramètre global — il s'applique à toutes les boutiques dans une configuration multi-boutique. L'exclusion de groupe de clients est par boutique.
- Suivre uniquement les commandes Paiement Validé est une fonctionnalité bêta et nécessite que l'API Conversions soit active. Les commandes conservées dans la file d'attente sont traitées rétroactivement par le CAPI — le pixel navigateur n'envoie pas d'événements différés.
- Prévention du Cache des Fichiers Statiques augmente les taux de cache miss du CDN pour les fichiers statiques de Pixel Plus. Activez-la uniquement lorsque vous avez confirmé qu'une mise en cache de fichiers obsolète cause activement un problème de suivi.
- Le paramètre Utilisation de l'External ID affecte l'attribution inter-appareils dans Meta. Le passer de "Uniquement pour les utilisateurs enregistrés" à "Tous les utilisateurs" générera des valeurs
external_idpour les visiteurs invités. Si un invité s'inscrit ensuite, il aura deux valeursexternal_iddifférentes, ce qui peut réduire la précision de l'attribution.
Dépannage
| Problème | Solution |
|---|---|
| Le pixel ne se déclenche pas du tout sur la boutique | Votre thème n'inclut probablement pas de hook footer. Activez Forcer les Pixels dans l'En-tête. |
| Événements AddToCart manquants sur un thème personnalisé | Ajoutez le sélecteur jQuery/CSS du bouton Ajouter au Panier de votre thème dans Sélecteur personnalisé Ajouter au Panier. |
| InitiateCheckout se déclenche deux fois par checkout | Passez le Mode Initiate Checkout de Page initiale à Clic sur le bouton. |
| Des commandes du personnel ou de test interne apparaissent dans les statistiques Meta | Assurez-vous que Exclure les commandes du Back Office est activé. Ajoutez aussi les IDs clients internes ou un groupe de clients du personnel aux champs d'exclusion. |
| Événements PageView provenant de pages d'erreur 404 polluant les données Meta | Activez Restreindre PageView aux contrôleurs connus. |
| Événements Purchase en double dans Meta | Activez Utiliser des Cookies pour prévenir les doublons de conversion. Vérifiez aussi que le module de paiement pour lequel les doublons se produisent n'est pas réglé en mode Basique sans protection cookie. |
| Événements Purchase non suivis pour un mode de paiement spécifique | Activez Forcer le mode Basique de l'événement Purchase pour ce module de paiement. Si des doublons apparaissent ensuite, activez aussi Utiliser des Cookies pour prévenir les doublons de conversion. |
| Script de pixel obsolète diffusé après une mise à jour du module | Activez Prévention du Cache des Fichiers Statiques et choisissez une fréquence adaptée (Quotidien ou Hebdomadaire). |
| Événements manquants qui semblent liés à la mise en cache AJAX | Activez Prévention du Cache Améliorée pour ajouter des paramètres anti-cache aux appels AJAX. |
Foire Aux Questions
Dois-je activer le chargement différé sur ma boutique ?
Uniquement si vous avez confirmé que le script du pixel est dans le chemin de rendu critique et affecte votre score PageSpeed. Pour la plupart des boutiques, le chargement par défaut dans le footer est suffisant et garantit qu'aucun événement n'est manqué. Si vous l'activez, activez aussi 'Différer seulement la première fois' pour minimiser le risque de manquer des événements chez les visiteurs récurrents.
Dois-je rapporter la valeur Purchase avec ou sans livraison ?
La plupart des annonceurs incluent la livraison pour rapporter le montant total du revenu. Si vous comparez la valeur Purchase rapportée par Meta à vos propres rapports de revenus, l'important est la cohérence avec la méthode utilisée par votre comptabilité. Choisissez le paramètre qui correspond à la façon dont vous mesurez le revenu ailleurs.
Quelle est la différence entre 'Uniquement pour les utilisateurs enregistrés' et 'Tous les utilisateurs' pour External ID ?
external_id est un identifiant de correspondance inter-appareils que Meta utilise pour relier les actions d'un visiteur entre sessions et appareils. Avec 'Uniquement pour les utilisateurs enregistrés', un ID stable n'est généré qu'une fois que le visiteur a un compte. Avec 'Tous les utilisateurs', un ID temporaire est aussi créé pour les visiteurs invités. Le risque avec 'Tous les utilisateurs' est qu'un invité qui s'inscrit ensuite recevra un second ID différent — Meta peut les traiter comme deux personnes distinctes, réduisant la précision de l'attribution.
Mon module de paiement personnalisé n'est pas suivi. Que dois-je essayer en premier ?
Activez d'abord Forcer le mode Basique de l'événement Purchase pour ce module de paiement. Cela force l'événement Purchase à se déclencher lorsque le client arrive sur la page de confirmation de commande, quelle que soit la façon dont le paiement a été traité. Si des événements en double apparaissent après l'activation du mode basique, activez aussi Utiliser des Cookies pour prévenir les doublons de conversion.
Puis-je exclure seulement un ou deux clients spécifiques sans créer un groupe de clients entier ?
Oui. Entrez leurs IDs clients PrestaShop sous forme de liste séparée par des virgules dans ID Client à exclure. Notez que ceci est un paramètre global — il s'applique à toutes vos boutiques dans une configuration multi-boutique, pas seulement à la boutique actuelle.
Que se passe-t-il pour les commandes conservées dans la file d'attente si le paiement n'est jamais validé ?
Le module conserve les commandes non validées pendant le nombre de jours défini dans Limite de validation des commandes non validées (7 jours par défaut). Si la commande n'est pas validée dans ce délai, l'événement Purchase est abandonné et jamais envoyé à Meta. Cela évite que des commandes obsolètes ou échouées génèrent de faux signaux de conversion.
Fonctionnalités Associées
- Événement Purchase (Avancé) — Suivi des commandes validées uniquement, paiements différés, prévention des doublons et exclusions de statuts de commande.
- Événements Suivis — Activer, désactiver et personnaliser les valeurs pour tous les événements suivis.
- RGPD et Consentement Cookies — Le blocage du consentement interagit avec la façon et le moment où le pixel se charge.
- API de Conversions (CAPI) — Requis pour que l'événement Refund et les événements Purchase différés fonctionnent.