Shopify : GA4 et Meta CAPI sans app payante
Configurer GA4 et la Conversions API de Meta sur Shopify avec les canaux natifs et Customer Events, puis vérifier que ça fonctionne.
Dans cet article
Presque toutes les boutiques Shopify que j’audite enregistrent moins d’achats dans le pixel Meta que de commandes dans leur back-office. C’est la première chose que je regarde quand on me dit que le ROAS s’est effondré sans raison, et l’écart vient rarement de l’attribution : une partie des événements ne quitte jamais le navigateur. Bloqueurs, consentement refusé, onglets fermés avant le déclenchement de la balise. Shopify propose une réponse native, et elle ne coûte rien de plus.
Cet article, c’est la façon dont je fais tourner GA4 et la Conversions API de Meta en n’utilisant que ce que la plateforme fournit déjà : les canaux de vente natifs et Customer Events. Sans app de tracking à quarante euros par mois. Et surtout, comment je vérifie ensuite que ça marche, ce que la plupart des guides oublient.
En 30 secondes :
- Le canal Facebook et Instagram active la Conversions API sur Enhanced et Maximum, et Shopify documente que l’événement d’achat y transite de serveur à serveur.
- GA4 se connecte en installant le canal Google & YouTube. Merchant Center n’est pas requis.
- Les pixels personnalisés tournent dans un bac à sable Lax : pas d’interface, pas d’accès au DOM, même pas la vraie URL de la fenêtre principale.
- Meta ne déduplique que si
event_idetevent_namecorrespondent, sous 48 heures.- Dans l’UE et au Royaume-Uni, les pixels ne s’exécutent que si le visiteur a accordé les autorisations demandées par leur configuration.
Que t’apportent vraiment les canaux natifs Google et Meta ?
L’installation et l’événement d’achat. Pas la vérification, et aucune garantie que ton tableau de bord publicitaire colle à celui des commandes.
Côté Google, tout passe par le canal de vente : installe le canal Google & YouTube et suis les étapes pour les balises. La même page ajoute deux avertissements qui font gagner des heures : Merchant Center n’est pas requis pour terminer la configuration, et Google Analytics ne peut pas suivre les événements tant que tu n’as pas désactivé le mode privé de ta boutique. J’ai vu déboguer un après-midi entier une boutique encore protégée par mot de passe.
Côté Meta, il existe trois niveaux de partage de données. Sur Enhanced et Maximum, Shopify documente que la Conversions API envoie l’événement d’achat entre les serveurs de Shopify et de Facebook, et que ces données ne peuvent pas être bloquées par les bloqueurs du navigateur. La moitié de la bataille gagnée avec un menu déroulant.
| Élément | Ce que donne le canal natif | Ce qui reste à ta charge |
|---|---|---|
| Propriété GA4 | Connexion depuis le canal Google & YouTube | Quels événements arrivent, avec quels paramètres |
| Achat Meta | Événement serveur sur Enhanced et Maximum | Qu’il ne soit pas dupliqué par celui du navigateur |
| Événements avant commande | Collecte côté navigateur | Ce que mangent bloqueurs et consentement |
| Données de correspondance | Nom, e-mail et téléphone sur Enhanced et Maximum | Que ta politique de confidentialité le reflète |
| Consentement | Bandeau cookies et autorisations par pixel | Quelles autorisations exige chaque pixel |
| Checkout | Couverture via Customer Events | Accepter que les scripts libres n’y vont pas |
La colonne de droite, c’est le vrai travail. La gauche prend quinze minutes.
Pourquoi le checkout ne se comporte pas comme le reste de la boutique ?
Parce que le checkout n’est pas ton terrain et que Shopify ne te laisse pas y injecter du code arbitraire. La voie admise, ce sont les pixels personnalisés, qui selon la documentation collectent des événements clients sur davantage de pages, comme la page de paiement et la page après achat, et qui sont chargés dans un bac à sable Lax conçu pour améliorer la sécurité et le contrôle des données envoyées à des tiers.
Bac à sable signifie des restrictions précises, pas un avertissement vague. Shopify liste les limitations : les sandbox pour pixels ne peuvent pas afficher d’éléments d’interface utilisateur, tels que des boutons, des formulaires, des bannières ou des fenêtres modales. Adieu les pop-ups montés depuis là. Pas de détection automatique des événements du DOM non plus, ni de données pour les cartes de chaleur.
Il y a aussi un piège difficile à trouver : la détection automatique des URL dans le bac à sable Lax inclut une version sandbox et peut ne pas refléter exactement l’URL de la fenêtre principale. Si tu laisses GA4 collecter page_location seul depuis un pixel personnalisé, tes rapports de pages de destination ne ressembleront pas à tes vraies URL. Combien de gens vérifient ça avant de conclure ? Presque personne. Moi, je transmets l’URL explicitement depuis l’événement. Une ligne en plus, un rapport entier sauvé.
Navigateur ou serveur ? Comment fonctionne vraiment la déduplication
Les deux, avec un identifiant partagé. Navigateur seul, tu es à la merci des bloqueurs. Serveur seul, tu perds le signal comportemental. Envoie les deux, Meta écarte le doublon.
La règle est documentée et littérale. Meta indique que l’eventID du pixel doit correspondre à l’event_id de la Conversions API, que l’event doit correspondre à l’event_name, et que les événements ne sont dédupliqués que s’ils sont reçus dans les 48 heures suivant le premier portant cet event_id. La page décrit aussi une méthode avec fbp ou external_id, avec une réserve : elle ne fonctionne que pour des événements envoyés d’abord depuis le navigateur, puis depuis le serveur.
Deux conclusions pratiques. Si ton événement serveur peut arriver avant celui du navigateur, la méthode fbp ne t’aide pas : il te faut un vrai event_id. Et un achat relancé depuis le backend deux jours plus tard ne se déduplique plus contre rien.
L’erreur que je croise le plus souvent n’est pas une déduplication ratée. C’est quelqu’un qui a laissé Enhanced actif et a ajouté en plus son propre pixel qui redéclenche Purchase avec sa logique à lui. Deux chemins indépendants, aucun event_id partagé, et un ROAS qui devient soudain magnifique. Avant d’ajouter le moindre envoi d’achat maison, regarde ce que le canal natif envoie déjà. En général, plus qu’on ne le croit.
Comment gérer le consentement sans casser la mesure ?
En acceptant que le consentement prime et en configurant les autorisations avec soin. Shopify est explicite : les pixels de suivi web ne s’exécutent que lorsque les visiteurs ont fourni les autorisations requises dans leur configuration, et par défaut les nouveaux pixels exigent Marketing et Analyse.
Cela a une conséquence que les clients digèrent mal. Si ton bandeau est bien posé et qu’une partie du trafic européen refuse, ces utilisateurs n’apparaissent pas. Ce n’est pas un bug. C’est l’implémentation qui fonctionne : la chute constatée à l’activation du bandeau, c’est l’écart entre ce que tu mesurais et ce que tu avais le droit de mesurer.
La brique à connaître, c’est la Customer Privacy API de Shopify, qui sert à vérifier les autorisations de traitement ou à construire ton propre bandeau. Elle publie l’événement visitorConsentCollected quand le consentement change, et le bandeau natif l’alimente seul. Si tu utilises une app tierce, vérifie qu’elle l’intègre correctement. Toutes ne le font pas.
Un détail que la documentation souligne et que je vois bafoué en permanence : le consentement ne doit être enregistré qu’à partir d’une interaction du visiteur, jamais automatiquement en son nom. Pré-accepter par défaut pour « ne pas perdre de données », c’est un problème juridique en ligne de code.
Comment je vérifie que le tracking fonctionne vraiment ?
Avec une séquence fixe, toujours dans le même ordre : chaque étape écarte une cause différente. C’est la seule chose qui sépare « je l’ai installé » de « ça marche ».
- Désactive le mode privé de la boutique. Sans ça, Google Analytics ne suit rien et tu débogues un fantôme.
- Crée un pixel de test qui s’abonne à
all_standard_eventset envoie chaque événement dans la console. Shopify publie l’extrait exact dans sa documentation. C’est ton filet de sécurité : il te dit ce que la plateforme émet, avant qu’un prestataire n’y touche. - Parcours la boutique avec Shopify Pixel Helper ouvert. La documentation de test explique qu’un point vert indique que l’abonnement à l’événement et la fonction de rappel ont réussi, tandis qu’un point rouge indique que l’abonnement a réussi mais que la fonction de rappel a échoué. Le rouge, c’est ton code cassé, pas un événement absent.
- Ouvre DebugView dans GA4 pendant que tu navigues. Google explique que DebugView affiche les événements et les propriétés utilisateur qu’Analytics collecte auprès d’un utilisateur en temps réel, avec un flux à la seconde. Contrôle les noms d’événement,
value,currencyetitems, un par un. - Compare le
page_locationqui arrive dans GA4 avec la vraie URL du navigateur. S’ils diffèrent, tu sais pourquoi. - Passe une vraie commande de test et ouvre-la dans Events Manager de Meta. Regarde la méthode de connexion de chaque événement et s’il apparaît comme dédupliqué. Un achat avec une vraie carte répond à des questions qu’aucune simulation ne tranche.
- Boucle la boucle en comptant. Commandes Shopify contre achats GA4 contre achats Meta, même fenêtre, même fuseau. Tu ne tomberas pas à 100 % et ce n’est pas nécessaire : tu cherches un écart stable et explicable.
- Refais le parcours en refusant le consentement. Ce qui apparaît encore après un refus, c’est ce que tu dois revoir avec un juriste.
Cette étape, je l’ai ajoutée après une boutique dont le bandeau était décoratif. Les événements partaient quand même. Personne ne teste le refus.
Quand une app payante en vaut-elle la peine ?
Quand ton problème cesse d’être l’installation et devient la maintenance. Les apps sérieuses vendent trois choses que le montage natif ne donne pas : leur couche serveur avec relances, l’enrichissement des données client, et quelqu’un à qui écrire quand Shopify ou Meta changent quelque chose. Ce dernier point vaut plus qu’il n’y paraît : cette surface bouge souvent.
Je ne les recommande pas par défaut. Avec un catalogue normal, un seul marché et de la publicité Google et Meta, le canal natif plus un pixel vérifié suffisent. Ça dépend du volume : sous un certain chiffre d’affaires, l’app mange la marge qu’elle promet de récupérer. Et une app mal configurée mesure tout aussi mal, facture en prime.
Mon critère est simple. Si personne ne relira la mesure d’ici six mois, paie la maintenance. Sinon, reste en natif et mets cet argent dans l’amélioration de la conversion du checkout.
Questions fréquentes
Ai-je besoin d’une app payante pour avoir Meta CAPI sur Shopify ?
Non. Le canal Facebook et Instagram inclut la Conversions API sur Enhanced et Maximum, et Shopify documente que l’événement d’achat y transite de serveur à serveur sans que les bloqueurs du navigateur l’arrêtent. Une app apporte relances et support, mais ce n’est pas une condition pour avoir CAPI.
Shopify envoie-t-il tous les événements côté serveur, ou seulement l’achat ?
La documentation de Shopify nomme précisément l’événement d’achat quand elle décrit la Conversions API sur Enhanced et Maximum. Le reste du signal est collecté côté navigateur. D’où l’intérêt de vérifier la méthode de connexion événement par événement dans Events Manager, plutôt que de supposer que tout part en serveur.
Pourquoi GA4 enregistre-t-il moins d’achats que Shopify ?
C’est en général plusieurs causes empilées : consentement refusé, bloqueurs, sessions fermées avant le déclenchement de la balise, et différences de fuseau entre les deux plateformes. Un écart stable et explicable est normal. Un écart qui change de taille chaque semaine, lui, signale un problème d’implémentation.
Puis-je utiliser Google Tag Manager dans Shopify ?
Oui, via un pixel personnalisé, et Shopify publie un tutoriel pour ça. Garde en tête qu’il hérite des limites du bac à sable Lax : pas d’interface, pas d’accès au DOM, pas de confiance dans l’URL détectée automatiquement. Beaucoup de balises qui tournaient bien sur un site classique ne se comportent pas pareil là-dedans.
Le consentement va-t-il détruire mes données ?
Il va réduire le volume mesuré, et c’est le résultat attendu. Dans l’UE et au Royaume-Uni, les pixels ne s’exécutent que si le visiteur accorde les autorisations exigées par leur configuration. Ce que tu peux faire : soigner le bandeau, revoir les autorisations de chaque pixel, et raisonner en taux relatifs plutôt qu’en volumes absolus.
Ce que tu ne vérifies pas, tu ne le mesures pas
Monter GA4 et Meta CAPI sur Shopify sans app payante est faisable et rapide. Deux canaux de vente, un menu de partage de données, un pixel personnalisé pour le reste. N’importe qui fait ça en un après-midi, et c’est bien pour ça que tant de guides s’arrêtent là.
Le vrai travail commence après. Ouvrir Pixel Helper et voir un point rouge, regarder DebugView et découvrir que value arrive hors TVA, compter les commandes contre les achats et trouver un écart que personne n’explique. Rien de ça ne remonte tout seul. Tant que tu ne le fais pas, tu n’as pas de mesure : tu as une installation qui a l’air propre, et la différence se paie quand quelqu’un répartit un budget avec ces chiffres.
Si tu veux un deuxième avis, passe ta propriété dans mon audit Google Analytics en 45 étapes, et si le trou est côté Meta, relis les modèles d’attribution Meta Ads avant d’accuser le pixel. Pour le contexte boutique, j’ai un audit SEO Shopify avec Claude, un guide Facebook Ads pour ecommerce et un autre sur Google Ads pour ecommerce. Et si tu décides depuis des mois avec des métriques de vanité, commence par là.
Si tu veux que j’audite ton implémentation et que je te dise quels événements mentent, réserve 30 minutes de consulting et on regarde ensemble.
Vos campagnes publicitaires
pourraient-elles mieux performer ?
30 minutes pour analyser votre situation et vous dire exactement ce que je changerais. Sans pitch, sans proposition commerciale.