Meta compte deux fois vos achats Shopify ? La solution

Pourquoi Meta affiche-t-il plus d’achats que Shopify ?

Généralement parce que deux outils envoient le même achat à un même pixel avec des identifiants d’événement différents : l’application Facebook & Instagram de Shopify plus une autre application de suivi, un pixel personnalisé ou un gestionnaire de balises. Meta ne traite deux copies comme une seule que si le nom de l’événement et l’identifiant d’événement correspondent, donnez donc un seul expéditeur à chaque pixel.

Ce guide traite le cas où Meta affiche plus d’achats que Shopify, y compris des événements Purchase sans commande derrière. S’il en affiche moins, voir le pixel Meta ne suit pas les achats ?

Un fil très lu de la Communauté Shopify datant de 2022 a retracé le problème jusqu’à un Purchase qui se déclenchait à chaque chargement de la page d’état de la commande : à chaque fois qu’un client la rechargeait, une nouvelle vente était enregistrée (fil). Cette cause a disparu des boutiques actuelles, car l’événement d’achat de Shopify pour les pixels, checkout_completed, est « triggered once for each checkout » (Shopify : checkout_completed). Les doublons d’aujourd’hui viennent d’un second expéditeur.

Comment Meta déduplique-t-il les événements pixel et API Conversions ?

Par le nom d’événement et l’identifiant d’événement. Si le pixel et l’API Conversions envoient la même paire au même pixel dans les 48 heures, Meta ne compte l’achat qu’une fois et « generally » garde la copie reçue en premier.

La règle de Meta, vérifiée le 24 septembre 2026 :

• Les clés. L’eventID du pixel doit correspondre à l’event_id de l’API Conversions, l’event du pixel doit correspondre à event_name, et les deux doivent aller vers le même Pixel ID. « Events are only deduplicated if they are received within 48 hours » (Meta : deduplication).
• Au sein d’une même source. Les mêmes clés suppriment aussi les répétitions envoyées deux fois depuis le navigateur, ou deux fois depuis un serveur (Meta : about deduplication).
• La solution de repli. Meta peut aussi faire correspondre sur le nom d’événement plus fbp ou external_id, mais « it only works for deduplicating events sent first from the browser and then through the server », et pas pour des événements venant d’une seule source (Meta : deduplication).

Donc deux outils qui créent chacun leurs propres identifiants d’événement envoient deux achats que Meta ne peut pas faire correspondre. Shopify donne le même avertissement avant d’ajouter un pixel personnalisé : « remove or modify any existing pixels to ensure customer events aren’t counted twice » (Shopify : manage custom pixels).

D’où vient le second achat ?

Le second Purchase vient d’un second outil qui envoie au même pixel Meta. Sur une boutique Shopify actuelle, c’est généralement l’un de ceux-ci.

Trois d’entre elles méritent un examen plus poussé :

• Règles de l’outil de configuration d’événements. L’outil sans code de Meta peut attacher un Purchase à un bouton ou à une adresse de page, et Meta avertit qu’un achat défini sur un bouton Buy now se déclenche « every time a customer clicks Buy now, whether their purchase went through or not » (Meta : event setup tool). En septembre 2026, un commerçant a retracé un Purchase se déclenchant à chaque chargement de la page d’accueil, sans valeur et sans commande derrière, jusqu’à une règle de ce genre : la requête du pixel portait cd[cs_est]=true, qui pointait vers l’outil de configuration d’événements, et une règle Purchase active figurait dans la configuration du dataset alors que l’écran de l’outil lui-même n’en listait aucune (fil).
• Code du thème. Shopify indique qu’une fois l’application Facebook & Instagram connectée, un pixel Meta ajouté plus tôt dans votre thème doit être retiré, car plus d’un pixel « can result in duplicate or incorrect data in your reports » (Shopify : Meta pixel).
• Les événements automatiques ne sont pas un suspect habituel : Meta indique qu’ils « are de-duplicated from any other events that you have manually set up » (Meta : automatic events).

Comment le trouver ?

Passez une vraie commande, comptez les événements Purchase qu’elle produit, et retracez chacun jusqu’à son expéditeur.

1. Dans Meta Events Manager, cliquez sur Data sources, sélectionnez votre dataset et ouvrez Test events. Saisissez l’adresse de votre boutique, cliquez sur Open website et passez une vraie commande. Meta indique que l’outil montre « which events are processed and which are deduplicated » (Meta : test events), mais ici il ne liste que les événements navigateur : les événements serveur n’y apparaissent qu’avec un code d’événement de test, que les vrais envois ne portent pas (Meta : using the API). Deux événements Purchase navigateur avec des identifiants d’événement différents signifient deux expéditeurs navigateur.
2. Pour les expéditeurs serveur, cliquez sur View details sur l’événement Purchase et lisez Event overview et Event deduplication (Meta : server event details). Avec cPixel, En direct montre à quels pixels il a envoyé la commande.
3. Dans les outils de développement de votre navigateur, ouvrez le panneau Network et filtrez sur facebook.com/tr, l’adresse à laquelle envoie le pixel Meta (Meta : pixel base code). Chaque requête avec ev=Purchase nomme son pixel dans id ; dans le cas de la page d’accueil ci-dessus, cd[cs_est]=true signalait la règle. Les envois serveur n’apparaissent jamais ici. La même méthode fonctionne pour toute plateforme : vérifiez chaque pixel de la page.
4. Dans Shopify, allez dans Settings → Customer events et notez chaque pixel d’application et pixel personnalisé qui pourrait envoyer à Meta.
5. Allez dans Online Store → Themes, ouvrez le menu à côté de votre thème actif, cliquez sur Edit code et recherchez fbq et votre Pixel ID. Meta suggère de rechercher fbq pour trouver son code de pixel (Meta : drop in website events).
6. Dans Events Manager, vérifiez l’outil de configuration d’événements pour un Purchase attaché à un bouton ou à une page. Une règle peut exister même quand l’écran de l’outil n’en liste aucune, comme dans le cas de septembre 2026.

Quand une commande produit un Purchase, ou deux avec le même identifiant d’événement dont Meta déduplique l’un, c’est terminé.

Qu’en est-il de TikTok et GA4 ?

Ils fonctionnent de la même façon avec des clés différentes : TikTok fait correspondre l’événement et l’identifiant d’événement dans les 48 heures, et GA4 fait correspondre l’identifiant de transaction. La solution est aussi la même : un seul expéditeur par pixel ou par propriété.

Sources, vérifiées le 24 septembre 2026 : Meta, TikTok, Google, Pinterest, Snap, OpenAI.

Deux détails comptent. TikTok traite une paire pixel et Events API portant le même pixel, événement et event_id comme un seul événement : il garde le premier, écarte les copies reçues dans les 48 heures et tente de fusionner les détails d’une copie reçue dans les 5 minutes (documentation développeur TikTok). Google ne déduplique que les achats qui partagent un identifiant de transaction, donc deux expéditeurs avec des identifiants différents comptent deux fois dans GA4, et Google avertit contre l’erreur inverse : il « will deduplicate all purchase events that have transaction_id=""», ce qui fusionne de vrais achats en un seul. Plus dans pourquoi GA4 et Shopify diffèrent sur les achats.

Deux applications peuvent-elles envoyer au même pixel en toute sécurité ?

Seulement si les deux envoient le même identifiant d’événement pour chaque achat, ce que des applications séparées ne font pas : chacune crée le sien.

cPixel, que nous développons, le dit lui-même dans sa configuration à propos du canal Shopify : « Utiliser les deux compterait vos ventes en double — les identifiants d’événement de l’application officielle ne peuvent pas être rapprochés des nôtres ». La solution de repli fbp et external_id de Meta n’est pas non plus un filet de sécurité : elle ne fonctionne que quand l’événement navigateur arrive d’abord et l’événement serveur ensuite, jamais entre deux expéditeurs serveur.

Gardez l’autre application pour tout sauf le suivi. L’application Facebook & Instagram synchronise aussi vos produits avec Meta Commerce Manager et les vend sur Facebook et Instagram (Meta : connect Shopify), donc la solution consiste à arrêter un outil qui envoie au pixel, pas à retirer l’application. Si un second outil a besoin des données d’achat pour ses propres rapports, donnez-lui un autre dataset. Pour les options côte à côte, voir configurer l’API Conversions sur Shopify.

Comment corriger cela pour de bon ?

Pour que Meta cesse de compter deux fois les achats Shopify, donnez un seul expéditeur à chaque pixel, puis confirmez avec une vraie commande qu’un achat crée un seul Purchase.

1. Choisissez l’expéditeur pour chaque pixel : l’application Facebook & Instagram, une application de suivi ou votre propre serveur.
2. Arrêtez tout autre expéditeur vers ce pixel : déconnectez le pixel personnalisé, retirez la balise Meta Purchase du gestionnaire de balises, supprimez le code du thème et toute règle Purchase dans l’outil de configuration d’événements.
3. Si une autre application doit continuer de fonctionner, désactivez son envoi vers ce pixel ou connectez-la à un dataset différent. Gardez l’application Facebook & Instagram installée pour son catalogue et sa boutique.
4. Répétez le test à une commande : Test events pour les expéditeurs navigateur, les détails de l’événement Purchase pour les expéditeurs serveur, et En direct si cPixel envoie.

cPixel donne à chaque achat un seul identifiant d’événement, construit à partir de votre boutique et du paiement, et partagé par le navigateur, le serveur et chaque compte que vous connectez pour cette plateforme. Le Purchase navigateur de Meta est désactivé tant que l’envoi serveur de cPixel vers ce pixel est actif, et cPixel refuse de connecter un même pixel deux fois. Il ne peut pas dédupliquer les événements d’une autre application, alors il les recherche : une fois par jour, il lit votre boutique à la recherche d’autres balises de suivi et de la liste des pixels enregistrés auprès de Shopify, et signale un conflit sur sa page Destinations sous Une autre application est configurée pour une plateforme à laquelle cPixel envoie aussi, sans nommer l’autre application ni vous demander de la retirer. La façon dont il construit chaque identifiant est dans comment cPixel compte chaque achat une seule fois.

Pour garder l’application Facebook & Instagram comme expéditeur de Meta, répondez Oui — gardez-la, et cPixel cesse d’envoyer Meta côté serveur dans la configuration Meta de cPixel. Cela arrête aussi les envois navigateur de cPixel vers ce pixel, quoi qu’en dise le libellé. Ce choix est expliqué dans cPixel aux côtés de l’application Facebook et Instagram. Plus d’informations sur cPixel, qui envoie les achats Shopify à sept plateformes publicitaires.

Questions fréquentes

Un Purchase au chargement de la page d’accueil est-il un doublon ?

Non, c’est un faux événement : aucune commande ne l’a produit. L’événement d’achat de Shopify pour les pixels se déclenche une fois par paiement, sur la page de remerciement ou la première page de vente incitative (Shopify : checkout_completed), jamais sur une page d’accueil. Cherchez une règle Purchase dans l’outil de configuration d’événements de Meta, un pixel personnalisé ou un script dans votre thème, comme dans le fil de septembre 2026 ci-dessus.

Pourquoi les pages vues sont-elles doublées alors que le revenu semble correct ?

Parce que deux outils envoient des événements de boutique au pixel mais un seul d’entre eux envoie l’achat, par exemple du code de pixel Meta resté dans votre thème aux côtés de l’application Facebook & Instagram. Le nombre d’achats est correct et les pages vues sont doublées, ce qui explique que ce doublon passe inaperçu. Retirez le code du thème, comme le conseille Shopify (Shopify : Meta pixel).

Les doublons nuisent-ils à la diffusion des publicités ?

Ils la faussent. Meta indique que sans déduplication, « you may see artificially high conversion numbers, which can mislead optimisation and budget allocation decisions » (Meta : about deduplication). Corrigez d’abord l’expéditeur, puis jugez les campagnes sur les jours suivant la correction.