Il y a dix ans, connecter une boutique à Google était souvent un chantier : du code, des balises, un prestataire. Aujourd’hui c’est une application, quelques clics, et une coche verte, premier étage d’un tracking e-commerce Google Ads qui ne s’arrête pas là.
Le progrès est réel, mais il a créé un nouveau problème : beaucoup de comptes croient leur mesure « faite » parce qu’une intégration est installée, sans vérifier ce qu’elle envoie, avec quelle définition et en cohabitation avec quelles anciennes balises.
Une balise absente se voit vite. Un doublon de conversion peut rester discret pendant des semaines, tout en faussant les enchères.
Shopify, WooCommerce ou PrestaShop : quelle intégration native choisir et que fait-elle ?
Shopify d’abord, le cas le plus outillé : c’est un CMS e-commerce hébergé, sans serveur à gérer de votre côté, où l’application Google & YouTube relie boutique, Merchant Center et Google Ads, et où le pixel Shopify peut remonter une partie des événements e-commerce. C’est l’installation la plus rapide côté technique, et un terrain fréquent de doublons lorsqu’elle cohabite avec un GTM historique. Le prix se paie en abonnement mensuel, applications de tracking comprises le plus souvent en supplément.
WooCommerce ensuite : ce plugin s’installe sur un site WordPress, ce qui suppose votre propre hébergement, votre serveur et votre maintenance technique, un coût et un contrôle que Shopify vous évite. L’extension officielle couvre les fonctions de base (flux, conversions), avec l’écosystème de plugins qui peut enrichir, et empiler. Chaque module pose volontiers son propre dataLayer, et chaque ajout de fonctionnalités alourdit d’autant la surface à auditer.
PrestaShop enfin : solution open source également auto-hébergée, proche de WooCommerce sur le principe (serveur, thèmes et modules à votre charge), avec des modules officiels et tiers de qualité variable, vérification d’autant plus indispensable avant utilisation en production. Magento suit la même logique d’auto-hébergement pour les catalogues plus lourds, mais sort du cadre de cette page.
Connecter une boutique Shopify à Google Ads ne crée pas un tuyau unique. L’application Google & YouTube peut à la fois synchroniser les produits Shopify vers Google Merchant Center et installer la mesure Google. Contrôlez ces deux fonctions séparément : un catalogue correctement reçu dans Merchant Center ne prouve pas qu’une action d’achat remonte correctement dans Google Ads.
Côté catalogue, Merchant Center reçoit les données des produits : identifiant, titre, prix, disponibilité et image. Cette liste alimente l’éligibilité aux fiches gratuites et aux annonces Shopping. Vérifiez les refus dans Merchant Center avant d’ouvrir une campagne Shopping ; une liaison Google Ads active ne rend pas diffusables des produits refusés.
Côté mesure, Google Ads reçoit les actions de conversion et, selon la configuration, certaines données client autorisées. Une balise d’achat doit conserver un identifiant de transaction unique et une valeur conforme à votre pilotage. Une campagne peut donc disposer de produits Shopping approuvés tout en apprenant sur une conversion fausse : le catalogue et la mesure ont chacun leur contrôle.
Sur WooCommerce et PrestaShop, le partage reste le même : connecter le catalogue à Google Merchant Center, puis configurer la mesure pour Google Ads sans dupliquer les balises existantes. La propriété des comptes compte autant que la technique : la boutique doit conserver ses accès administrateur à Merchant Center et à Google Ads, même lorsqu’un prestataire réalise l’installation. Donner un accès ne transfère pas la propriété ; documentez qui détient la propriété de chaque compte avant tout changement d’agence.
Le dénominateur commun des trois plateformes : le natif installe vite et configure par défaut, et ces réglages ne reflètent pas forcément votre méthode de mesure. Le choix entre solution hébergée (Shopify) et solutions auto-hébergées (WooCommerce, PrestaShop) déplace le coût ailleurs, moins de technique au quotidien contre un abonnement, ou plus de contrôle et de performance potentielle contre de la maintenance serveur, mais ne change rien à la règle de tracking qui suit.
Deux sources pour un même signal
La règle qui évite la plupart des dégâts tient en une phrase : un signal, une source. Si l’application envoie le purchase, l’ancienne balise GTM du purchase doit être coupée ou réaffectée, pas « rester au cas où ».
La cohabitation est le grand classique des boutiques qui ont vécu : un thème qui pousse son dataLayer, un pixel posé par l’agence de 2022, l’application installée en 2024, et des commandes comptées deux fois, donc une valeur apprise double, donc des enchères faussées.
D’où l’ordre des opérations : auditez l’existant avant d’installer le neuf, inventaire de tout ce qui envoie quelque chose (balises, applications, extensions, code de thème), puis décision explicite de qui possède chaque signal, puis installation et nettoyage. Empiler d’abord et trier plus tard produit des comptes difficiles à lire.
- Inventaire. Constituez une liste unique : comptes Merchant Center et Google Ads reliés, produits importés, actions de conversion actives, balises GTM, pixels de thème et autres outils de mesure. Cette liste montre ce qui existe avant de configurer quoi que ce soit.
- Décision d’attribution. Pour chaque action (purchase, add_to_cart, begin_checkout), désignez une seule source. Regroupez les actions dans une liste de contrôle et notez la propriété du signal : l’intégration ou le GTM, pas les deux.
- Installation du neuf. Nettoyez d’abord, puis configurez la synchronisation des produits vers Merchant Center et la mesure dans Google Ads. Si vous importez manuellement une partie du catalogue, séparez-la clairement de la source automatique.
- Vérification. Passez une commande client réelle, puis contrôlez la campagne Shopping, les annonces éligibles et chaque action de conversion avant d’ouvrir le budget.
- Documentation. Conservez la liste datée des comptes, des actions et des balises : qui envoie quoi, vers quel outil, avec quels paramètres.
Comment vérifier son tracking après avoir installé l’intégration ?
L’intégration installée, voici ce qu’elle ne vérifie pas toujours pour vous, et qui se contrôle avant de toucher à une campagne avec une commande réelle. Configurer une liaison n’est que la première étape : les résultats dépendent de ce qui est effectivement envoyé.
Répartissez le contrôle entre trois outils : Merchant Center pour l’état des produits et des annonces Shopping, Google Ads pour les actions de conversion, Google Analytics 4 ou Tag Assistant pour le détail des événements. Ces outils doivent raconter les mêmes résultats : un achat client, une seule action comptée et une valeur cohérente. À chaque étape, notez les paramètres contrôlés et les résultats du test.
Un : la conversion remonte, une seule fois, au moment du paiement validé. Cherchez son transaction_id, il doit être unique.
Deux : la valeur, son montant correspond-il à votre définition (TTC ou HT, port inclus ou non) ? Les intégrations transmettent souvent le TTC par défaut ; si vous pilotez en HT, c’est un réglage explicite à faire.
Trois : les identifiants produit des événements, alignés sur ceux du flux Merchant Center, variantes comprises. Le désalignement d’ID dégrade le remarketing dynamique, la constitution des audiences et les analyses par produit. Pour Shopping, vérifiez aussi qu’un même identifiant relie le produit vu par le client, la ligne du catalogue et l’achat mesuré.
Si une ligne de produit est refusée, corrigez la donnée dans la boutique plutôt que de modifier manuellement la copie reçue par Merchant Center. Si vous devez importer manuellement un flux complémentaire, isolez cette source et documentez ses paramètres : deux sources qui corrigent la même ligne recréent le problème de propriété. Côté mesure, la règle est identique : configurer une balise principale, puis désactiver toute balise qui envoie la même conversion.
Quatre : le funnel GA4, les événements intermédiaires sont-ils là, avec leur items array, ou seulement le purchase ?
Cinq : le consentement, refusez les cookies sur votre propre site et observez ce qui part encore (et ce qui ne part plus). Une couche de consentement mal branchée peut réduire fortement la mesure, parfois seulement visible lors d’un rapprochement.
Après l’installation : la propriété du signal
Dernier étage, organisationnel : documenter qui envoie quoi, trois lignes dans un document que l’équipe connaît : « purchase : application Shopify ; événements funnel : pixel natif ; aucune balise GTM active sur l’e-commerce ».
Ce document évite de repartir de zéro au premier incident, à la première migration, au premier prestataire qui arrive. Sans lui, chaque nouveau venu réinvente l’inventaire, ou réinstalle une source déjà présente.
Le rapprochement mensuel back-office, posé dans la page socle de la branche, reste votre alarme continue : une app ou un thème peut changer de comportement à une mise à jour. Un tracking e-commerce s’installe, puis se surveille comme un système vivant, au même titre que la sécurité de vos accès ou la création de vos campagnes.
- L’app native installe vite et configure par défaut : valeur, doublons et ID variantes doivent être contrôlés explicitement.
- Auditer l’existant avant d’installer : inventorier tous les émetteurs de signaux, désigner une seule source par événement, puis nettoyer.
- La checklist post-install en cinq points (unicité transaction_id, valeur/définition, ID vs flux, funnel + items, test consentement) prend une heure et évite des semaines d’erreur silencieuse.
- Documenter qui envoie quoi : trois lignes écrites simplifient chaque migration ou changement de prestataire.
Vos conversions améliorées sont-elles actives, ou juste cochées ?
Sur Shopify l’app peut gérer les conversions améliorées côté achat selon la configuration ; sur Woo et Presta, c’est rarement automatique. Dans tous les cas, « activé » ne suffit pas tant que vous ne l’avez pas vérifié dans les diagnostics.
Les conversions améliorées renvoient des données client first-party hashées, l’email a minima, éventuellement téléphone, nom, code postal, pour mieux réconcilier le clic et l’achat quand le cookie tiers ne suffit plus. Depuis l’érosion des cookies tiers, ce n’est plus un simple bonus : c’est une brique importante de la mesure.
Le conseil courant s’arrête à « activez les conversions améliorées ». L’erreur consiste à croire qu’elles fonctionnent parce qu’une coche est verte. Une app peut afficher la fonction comme disponible alors qu’aucun champ first-party ne part réellement, ou que le consentement les bloque en amont.
Deux vérifications, pas une coche :
- Le diagnostic, pas le réglage. Dans Google Ads, Objectifs > Conversions > l’action concernée > onglet Diagnostics : c’est là que vous voyez si des données améliorées arrivent, pas dans l’écran qui dit « activé ».
- Les champs partent ET le consentement les autorise. Les conversions améliorées ne peuvent hasher que ce que la page laisse passer. Si votre consentement refuse les données utilisateur (
ad_user_data), l’email a beau exister, il ne part pas. C’est le même mécanisme que celui décrit plus haut : le consentement conditionne ce qui peut être envoyé, conversions améliorées comprises.
Sur Woo et Presta surtout, vérifiez explicitement : l’app n’étant pas toujours câblée par défaut comme sur Shopify, l’absence de configuration peut signifier qu’aucune donnée améliorée ne remonte, même si rien ne le signale clairement.
Vos scripts de page de remerciement ont-ils survécu à la migration checkout de Shopify ?
Si votre purchase Shopify remonte encore par un script collé dans le checkout ou sur la page de remerciement, vérifiez-le en priorité : les migrations checkout peuvent rendre ces scripts hérités inopérants ou incomplets. Le bon angle n’est pas « est-ce que le script existe ? », mais « d’où part réellement la conversion d’achat aujourd’hui ? ».
C’est le type d’incident silencieux visé par cette page. Un compte qui suivait le purchase via un vieux script thank-you peut voir ses conversions chuter sans notification claire, puis découvrir l’anomalie dans un rapprochement back-office.
La connexion propre passe plutôt par une source managée compatible avec le checkout actuel, comme le pixel managé et les Customer Events de l’app Google & YouTube quand ils sont disponibles et correctement configurés. Si vous découvrez encore un script de purchase dans vos anciennes personnalisations, ne le réparez pas à l’aveugle : migrez le signal vers une source propre et passez la checklist post-install.
Mon intégration est installée mais aucune conversion ne remonte : où chercher ?
Quand une intégration est bien là mais que le compteur reste à zéro, commencez par l’association, le consentement et les balises coupées par une migration. Reprenez les causes une par une, dans cet ordre.
Le reste de la page traite le sur-comptage, le doublon qui gonfle. Le sous-comptage est la question miroir, et la cause n’est pas toujours celle qu’on imagine. L’arbre court, une cause par vérification :
- Association de compte rompue ou non confirmée. Le lien entre la boutique et Google Ads a sauté à une mise à jour, ou n’a pas été validé côté Google Ads. Sans lui, l’app envoie dans le vide.
- Consentement mal raccordé. Si la couche de consentement est mal branchée ou en mode strict sans modélisation, certaines conversions peuvent ne plus être observées ou dépendre de la modélisation.
- Migration plateforme qui a coupé l’ancienne balise. C’est le cas Shopify ci-dessus : le script qui remontait le purchase peut ne plus fonctionner depuis la migration checkout, sans source de remplacement.
- Mauvais ID ou label de conversion. L’app pointe vers une action de conversion qui n’est pas celle que vous regardez, ou un label erroné : les hits partent, mais pas dans la bonne case.
- Délai de remontée normal, pas une panne. Avant de tout démonter, vérifiez que vous ne lisez pas un délai d’attribution standard comme une absence. Quelques heures de retard ne sont pas une panne.
La vérification reste la même que pour les doublons : passez une commande test réelle et suivez le transaction_id (voir la checklist plus haut). Si le hit n’apparaît nulle part, c’est l’émission ou l’association ; s’il apparaît mais ne crée pas de conversion, c’est l’ID ou le label. Pour les fuites en amont, funnel GA4, étapes qui se perdent avant l’achat, c’est un autre sujet, traité dans le suivi e-commerce avancé GA4.
Pour qui c’est critique, et la limite
Boutiques qui ont vécu, migrations, refontes, changements d’agence : une dette de tracking est fréquente, et l’audit de l’existant est votre premier chantier. Pour une entreprise qui pilote un projet e-commerce structurant, pas juste un blog avec un module de vente ajouté après coup, cette rigueur de gestion du signal devient nécessaire.
Le point de vigilance : la connexion propre transmet fidèlement ce que la boutique sait, elle ne sait ni votre marge, ni la qualité réelle de vos commandes. Les étages supérieurs de la branche commencent où l’app s’arrête.
Après l’installation, la question utile est simple : qui a passé une commande test et vérifié l’unicité, la valeur, les identifiants, le funnel et le consentement, et où est écrit qui possède chaque signal ?
Si la réponse est « personne » et « nulle part », déroulez la checklist avant de toucher aux campagnes, pour votre tracking e-commerce, pour vos campagnes Shopping et de leur retour sur dépense.
L’intégration crée la connexion ; elle ne garantit pas la qualité des données envoyées.
