C’est une déclinaison ecom de ce que GA4 pour Google Ads fait à l’échelle du compte Google entier, sur les données réelles de votre boutique : comprendre et segmenter ce que la balise Ads ne voit pas.
Votre tag de conversion Google Ads sait une chose, et il la sait bien : combien d’achats, pour quelle valeur. Il ignore tout le reste : combien ont vu le produit sans l’ajouter, combien l’ont ajouté sans entamer le checkout, combien ont entamé sans payer, et sur quelles gammes chaque fuite se concentre.
Ce reste, c’est précisément le métier du suivi e-commerce avancé de GA4 : instrumenter le parcours complet, étape par étape, produit par produit. Deux outils, deux métiers. Toute la confusion du marché vient de les croire concurrents.
Le partage des rôles, une fois pour toutes
Posons la doctrine avant la technique. Le tag Ads natif est le canal de commandement : c’est lui qui transmet la consigne aux enchères, vite et directement. Le purchase à valeur dynamique de la branche vit là.
GA4 est le canal de connaissance : il raconte le comportement, toutes sources confondues, et fabrique les audiences. On peut techniquement importer les événements GA4 comme conversions Ads, c’est un plan B honorable pour qui n’a pas la main technique sur la configuration du tag natif.
Mais le signal natif reste le choix le plus direct pour le bidding quand il peut mesurer l’achat proprement, pendant que GA4 fait ce que lui seul fait : diagnostiquer. Le compte mûr configure les deux à leur place, pas l’un à la place de l’autre.
Ce que le suivi e-commerce GA4 instrumente
Deux éléments définissent l'instrumentation : la séquence d'événements standardisés, qui transitent par le dataLayer avant d’atteindre GA4, et le tableau de produits qui l'accompagne à chaque étape.
Quels événements forment un funnel e-commerce complet ?
Le cœur du dispositif tient en une séquence d’événements normalisés par Google : view_item (le produit vu), add_to_cart (l’intention), begin_checkout (l’engagement), purchase (la vente), entourés de leurs compagnons view_item_list, select_item, refund, et pour qui veut affiner le tunnel de paiement lui-même, add_shipping_info et add_payment_info.
Leur standardisation est leur superpouvoir : GA4 les reconnaît nativement, alimente ses rapports de monétisation sans configuration supplémentaire, et surtout les enchaîne en funnel. Chaque paire d’étapes devient un taux de passage.
Et soudain les questions floues deviennent des chiffres : « mon site convertit mal » se décompose en « la fiche transforme à X %, le panier fuit à Y %, le checkout perd Z % », exactement la cartographie qu’exigent vos chantiers de pages, désormais mesurée au lieu d’être devinée.
- view_item_list
- Impression d’un produit dans une liste ou une page catégorie.
- select_item
- Clic sur un produit depuis une liste.
- view_item
- Affichage de la fiche produit.
- add_to_cart
- Ajout au panier.
- begin_checkout
- Entrée dans le tunnel de paiement.
- add_shipping_info
- Choix du mode de livraison, dans le tunnel de paiement.
- add_payment_info
- Saisie du moyen de paiement, dernière étape avant l’achat.
- purchase
- Transaction validée, avec revenue et transaction_id.
- refund
- Remboursement partiel ou total, à transmettre pour corriger le revenu mesuré.
Pourquoi l’items array est-elle indispensable dans chaque événement ?
Voici la partie difficile, celle qui sépare le « suivi avancé » réel du cosmétique : chaque événement du funnel doit porter son tableau de produits, l’items array : identifiants, noms, prix, quantités, variantes.
Sans elle, vous savez QUE ça fuit. Avec elle, vous savez SUR QUOI : le taux d’ajout panier par gamme, les produits qui se regardent sans s’acheter, les catégories où le checkout casse.
Deux exigences de qualité font la différence. D’abord, les identifiants alignés sur ceux du flux Merchant Center : le même produit doit porter le même ID partout, c’est ce qui rend les analyses croisables et le remarketing dynamique cohérent. Ensuite, la devise transmise dès qu’une valeur l’est : le paramètre currency accompagne value pour que GA4 agrège correctement le revenu. La documentation Google liste plusieurs paramètres possibles par item ; en pratique, seule une poignée d’entre eux rend l’intégration exploitable, les autres relèvent du confort.
La moitié des implémentations « avancées » envoient les événements sans items, ou avec des ID maison : le funnel global fonctionne, mais la lecture par produit, celle qui permet d’agir, disparaît.
Ce qu’on en fait : trois usages qui paient
L’instrumentation n’est pas une fin. Voici les trois usages concrets.
Usage un : le diagnostic. Les taux de passage par gamme et par source. Le trafic payant fuit-il au même endroit que l’organique ? Une fuite spécifique au payant pointe un problème d’adéquation annonce-page, pas un problème de site. C’est une information que votre tag Ads ne produit pas à lui seul.
Usage deux : les audiences. Les abandonnistes de panier, les visiteurs d’une gamme précise, les acheteurs récents d’une catégorie, construits sur les événements ecom et poussés vers vos campagnes d’annonces. Plus fins que les listes basées sur les pages vues, car elles portent le contexte produit et un vrai historique client, c’est le carburant du remarketing dynamique sur paniers abandonnés.
Usage trois : l’arbitrage CRO. Avant et après chaque chantier de page, le taux de passage de l’étape concernée devient votre repère principal. Fini les refontes jugées au ressenti ou à la hausse globale du revenu : vous lisez l’impact précis sur l’étape que vous avez travaillée.
- Tag Ads natif : pilote les enchères, signal rapide. GA4 : diagnostique le funnel, fabrique les audiences. Deux métiers, pas un doublon.
- Quatre événements clés : view_item, add_to_cart, begin_checkout, purchase. Standardisés par Google, exploités nativement dans les rapports Monétisation.
- L’items array est la partie difficile : sans elle, vous localisez une fuite sans savoir sur quels produits. Les identifiants doivent être alignés sur le flux Merchant Center.
- currency est obligatoire avec chaque valeur monétaire. transaction_id évite les doublons sur purchase.
- Les attributions GA4 et Ads divergent par construction. On ne rapproche pas leurs chiffres au centime ; on lit chacun pour son métier.
Lire et vérifier votre funnel GA4
Une fois le funnel instrumenté, deux opérations sont nécessaires : trouver où lire les taux de passage et valider que les données remontent correctement.
Où lit-on réellement le taux de passage dans GA4 ?
Pas dans les rapports Monétisation. Ceux-ci affichent des totaux, articles vus, ajoutés, achetés, mais pas le passage d’une étape à la suivante, ni les informations de gamme ou de source qui aident à agir. Le diagnostic par étape se lit surtout dans Explorer, via l’exploration en entonnoir : c’est l’endroit le plus utile pour rendre la lecture actionnable.
C’est la confusion qui fait croire que Google Analytics « ne donne pas les taux » : on les cherche au mauvais endroit. Les rapports standard sont un tableau de bord de volumes ; l’entonnoir est l’instrument qui sert à optimiser. Vous y reconstruisez la séquence view_item → add_to_cart → begin_checkout → purchase et GA4 calcule chaque marche.
Un réglage décide de tout : l’entonnoir ouvert ou fermé. En ouvert, l’utilisateur peut entrer à n’importe quelle étape, un visiteur arrivé directement sur une fiche produit compte. En fermé, seule la séquence stricte est retenue. Le piège classique : lire un entonnoir ouvert comme s’il était fermé, et conclure à une fuite là où il n’y a qu’une entrée latérale. Pour comparer des taux de passage propres, l’entonnoir fermé tranche.
Et c’est là que le diagnostic devient concret : segmentez cette exploration par source (payant vs organique) et par gamme. C’est exactement la lecture qui transforme « l’usage un » en décision, une fuite au même endroit pour les deux sources est un problème de site, une fuite propre au payant pointe l’adéquation annonce-page.
Comment vérifier que vos événements remontent correctement avant de croire le funnel ?
Avant de tirer la moindre conclusion d’un taux de passage, validez dans DebugView (Admin > DebugView) que chaque événement remonte avec son items array peuplée, sa devise et sa value. Un funnel qui affiche un taux n’est pas un funnel qui mesure juste.
La nuance est tout l’écart entre un consultant et un dashboard. Un taux de passage de 12 % n’a aucun sens si add_to_cart part sans items, ou avec une valeur nulle, ou si begin_checkout se déclenche deux fois : vous lisez un artefact, pas un comportement. La moitié des audits commencent ici, pas dans l’analyse, dans la vérification que les briques sont saines.
DebugView vous montre, événement par événement, ligne par ligne, ce que GA4 reçoit réellement. C’est le pont direct vers l’erreur la plus fréquente déjà signalée plus haut : l’items array vide ou absente. On la voit ici en temps réel, sur l’événement, avant qu’elle ne dégrade plusieurs semaines de rapports. La configuration plateforme par plateforme, Shopify, Woo, Presta, doublons d’événements, relève de l’application par CMS, éventuellement via Google Tag Manager pour qui préfère ne pas toucher au code ; DebugView, lui, est le contrôle qualité commun à toutes.
Les limites à connaître avant de décider
Deux contraintes structurelles encadrent la lecture du funnel : le consentement et la divergence d'attribution.
Pourquoi vos transactions GA4 sont-elles incomplètes ?
Parce que le funnel GA4 dépend du consentement et de la configuration de mesure. Sans consentement, Google Analytics ne mesure pas directement : il peut modéliser, c’est-à-dire estimer une partie des conversions perdues à partir des données des utilisateurs consentants. Vos taux de passage portent donc sur une base de mesure qui peut rester partielle.
La conséquence pour le diagnostic est nette, et elle renforce la doctrine : les chiffres GA4 peuvent être incomplets et reposer en partie sur de l’estimation. C’est une raison de plus de ne pas rapprocher Ads et GA4 au centime, non seulement leurs attributions diffèrent, mais leurs assiettes de mesure diffèrent aussi. Deux outils qui ne comptent ni les mêmes événements ni les mêmes utilisateurs ne racontent pas exactement la même histoire, et il ne faut pas le leur demander.
Ce qui ne change pas la valeur de l’instrument : pour comparer des taux de passage entre gammes et entre sources, c’est la cohérence relative qui compte, pas l’exhaustivité absolue. Une fuite qui ressort sur le payant ressort sur la même assiette modélisée que l’organique, la comparaison reste valide. Le détail de la conformité, CMP et Consent Mode, relève de la chaîne de mesure e-commerce complète ; ici, on retient l’impact : les trous de données sont une propriété du chiffre, pas un bug à corriger dans le rapport.
Pour qui c’est indispensable, et la limite
Dès que vos chantiers d’optimisation dépassent « monter le budget » (CRO, arbitrages de gammes, remarketing sérieux), ce funnel est votre instrument de bord. Sans lui, vous opérez à l’aveugle en croyant voir.
Le point de vigilance : GA4 décrit, il ne décide pas. Ses taux de passage localisent les fuites sans en donner la cause. La cause se trouve sur la page, pas dans le rapport.
Et son attribution diffère structurellement de celle d’Ads : les deux outils peuvent raconter des histoires différentes, et c’est normal.
Votre funnel est-il instrumenté au point de vous dire où vous perdez, sur quelles gammes, pour quelles sources ? Ou savez-vous seulement combien vous gagnez ?
Si vos événements n’ont pas d’items array ou si personne ne lit vos taux de passage, c’est là qu’on commence : instrumenter le funnel proprement, pour poser le socle de tracking de votre boutique, pour vos campagnes Google Ads e-commerce. Le tag Ads pilote, GA4 diagnostique. Deux métiers, pas un doublon.
