AccueilE-commerceConnecter boutique Shopify, WooCommerce ou PrestaShop à Google Ads proprement

Connecter boutique Shopify, WooCommerce ou PrestaShop à Google Ads proprement

En bref

Les intégrations natives n’ont pas supprimé les problèmes de tracking, elles les ont rendus silencieux : fini les tags manquants qui criaient, place aux doublons discrets (app + GTM historique), aux valeurs subies (TTC par défaut), aux ID de variantes désalignés du flux, au consentement qui ampute sans bruit. Auditez l’existant avant d’installer quoi que ce soit.

Il y a dix ans, connecter une boutique à Google était un chantier : du code, des tags, un prestataire. Aujourd’hui c’est une app, trois clics, et une coche verte.

Le progrès est réel, et il a fabriqué un nouveau problème, plus sournois que l’ancien : des milliers de comptes croient leur mesure « faite » parce qu’une intégration est installée, alors que personne n’a jamais vérifié ce qu’elle envoie, en double avec quoi, ni selon quelle définition.

Le tag manquant d’hier criait son absence dans les rapports. Le doublon silencieux d’aujourd’hui sourit, et fausse tout.

Par plateforme : ce que le natif fait (et ne fait pas)

Shopify d’abord, le cas le plus outillé : l’app officielle Google & YouTube relie boutique, Merchant Center et Google Ads, et le pixel Shopify auto-tracke une partie des événements e-commerce (source : Analytics Help, à jour juin 2026). C’est l’installation la plus rapide du marché, et le terrain de doublons le plus fertile, précisément parce qu’elle cohabite presque toujours avec un GTM historique.

WooCommerce ensuite : l’extension officielle couvre l’essentiel (flux, conversions), avec l’écosystème de plugins qui peut enrichir, et empiler. Chaque plugin pose volontiers son propre dataLayer.

PrestaShop enfin : modules officiels et tiers, qualité variable, vérification d’autant plus indispensable.

Le dénominateur commun des trois : le natif installe vite et configure par défaut, et les défauts ne sont pas vos choix.

L’erreur que je vois le plus
Installer l’app officielle sans désactiver l’ancien tag GTM qui envoie déjà le purchase. Résultat : chaque commande comptée deux fois, des enchères qui apprennent sur une valeur doublée, et personne ne s’en aperçoit pendant des mois parce que « ça semble marcher ».

Le péché capital : deux sources pour un même signal

La règle qui évite 80 % des dégâts tient en une phrase : un signal, une source. Si l’app envoie le purchase, l’ancien tag GTM du purchase doit mourir, 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’app 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 que personne ne respecte : auditez l’existant AVANT d’installer le neuf, inventaire de tout ce qui envoie quelque chose (tags, apps, plugins, code de thème), puis décision explicite de qui possède chaque signal, puis seulement installation et nettoyage. Empiler d’abord, trier jamais : c’est la genèse de tous les comptes illisibles.

  1. Inventaire. Listez tout ce qui envoie des événements : tags GTM actifs, pixels de thème, apps installées, code custom. Trois lignes suffisent.
  2. Décision d’attribution. Pour chaque signal (purchase, add_to_cart, begin_checkout), désignez une seule source. L’app OU le GTM, jamais les deux.
  3. Installation du neuf. L’app est installée en dernier, après le nettoyage, pas avant.
  4. Checklist de vérification. Une commande test réelle, cinq points vérifiés (voir section suivante).
  5. Documentation. Trois lignes écrites, partagées, datées : qui envoie quoi.

La checklist post-install : une commande test, cinq vérifications

L’app installée, voici ce qu’elle ne vérifiera jamais pour vous, et qui se vérifie en une heure avec une commande réelle.

Un : la conversion remonte, une seule fois. 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, pas une fatalité, mais c’est VOTRE réglage à faire.

Trois : les identifiants produit des événements, alignés sur ceux du flux Merchant Center, variantes comprises. Le désalignement d’ID est le tueur silencieux du remarketing dynamique et des analyses par produit.

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). La couche de consentement mal branchée ampute la mesure sans un bruit, et vous découvrez l’amputation des mois plus tard dans un rapprochement.

transaction_id
Identifiant unique de commande envoyé dans l’événement de conversion. Si deux hits arrivent avec le même transaction_id, Google Ads déduplique ; sans lui ou avec un id non unique, chaque visite post-achat peut déclencher une conversion supplémentaire.

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 : app Shopify ; événements funnel : pixel natif ; aucun tag GTM actif sur l’ecom ».

Ce document vaut de l’or au premier incident, à la première migration, au premier prestataire qui arrive. Sans lui, chaque nouveau venu réinvente l’inventaire, ou pire, réinstalle.

Le rapprochement mensuel back-office, posé dans la page socle de la branche, reste votre alarme continue : l’app peut changer de comportement à une mise à jour, et elle ne vous préviendra pas.

À retenir
  • L’app native installe vite et configure par défaut : les défauts (TTC, doublons, ID variantes) ne sont pas vos choix, ils sont à corriger 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 mois d’erreur silencieuse.
  • Documenter qui envoie quoi : trois lignes écrites valent de l’or à chaque migration ou changement de prestataire.

Pour qui c’est critique, et la limite

Boutiques qui ont vécu, migrations, refontes, changements d’agence : votre dette de tracking est quasi certaine, et l’audit de l’existant est votre premier chantier.

La limite, sans détour : 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.

Vous aviez installé l’app. La vraie question : depuis, 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 », dites-le moi : on déroule la checklist en une heure, dans le cadre de votre tracking e-commerce, au service de votre acquisition.

L’intégration installe le tuyau, pas la vérité de ce qui y circule.

Questions fréquentes

Peut-on garder GTM et l’app officielle Shopify en parallèle ?
Oui, à condition qu’ils ne trackent pas les mêmes événements. L’app pour le purchase et les conversions Google Ads, GTM pour les événements de funnel complémentaires : mais chaque signal doit avoir une seule source, documentée.
L’app officielle suffit-elle pour piloter des enchères Smart Bidding ?
Elle transmet les conversions : c’est le minimum. Pour piloter par marge ou qualifier les commandes, il vous faut un étage supplémentaire ; l’app seule ne connaît ni votre marge ni la valeur client réelle.
Comment savoir si j’ai des doublons de conversion ?
Passez une commande test réelle, notez le transaction_id, et cherchez combien de hits purchase arrivent dans Google Tag Assistant ou GA4 DebugView pour cet identifiant. Plus d’un hit = doublon à traiter.
PrestaShop : module officiel ou tiers ?
Le module officiel PrestaShop (disponible en marketplace) couvre les cas courants. Les modules tiers peuvent ajouter des fonctionnalités mais empilent souvent un dataLayer supplémentaire : vérifiez systématiquement la cohabitation avant d’activer.
VD
Vincent Duquesne
Consultant Google Ads / SEA freelance depuis 2011 · +100 comptes · +20 M€ gérés
Google Partner Premier 2026
Publié le 15 juin 2026 · Mis à jour le 15 juin 2026

Votre intégration native envoie quoi, exactement ?

Doublons, TTC subi, ID désalignés : on passe la checklist ensemble et on voit ce que votre compte mesure vraiment.

Réserver un appelParlons de vos objectifs