Reprenons la phrase qui ouvre tout ce cocon : Google voit votre chiffre d’affaires, il ne voit pas votre marge par défaut. Toute la stratégie e-commerce en découle, et c’est tout l’enjeu de votre tracking e-commerce Google Ads : cette page montre comment lever cette limite.
La machine peut connaître votre marge, à deux niveaux très différents : en lecture (elle vous montre le profit, mais continue d’enchérir sur le CA tant que la valeur transmise reste le CA) et en consigne (elle maximise le profit lui-même). Le premier étage est natif, accessible, et déjà transformateur. Le second est un changement de régime.
Les confondre, croire qu’un attribut de flux suffit à « optimiser la marge », est l’erreur la plus répandue du sujet, elle traverse aussi bien les campagnes isolées que les stratégies d’enchères les plus rodées.
Étage 1 : voir le profit brut sans toucher aux enchères
Deux pièces indissociables à poser, aucune rupture, une lecture qui redistribue les arbitrages.
Comment voir le profit brut par campagne dans Google Ads ?
Google a outillé la lecture du profit, et l’installation tient en deux pièces documentées. Pièce un : les conversions avec données de panier, une extension du suivi qui transmet, pour chaque transaction, le détail des produits vendus.
Pièce deux : l’attribut cost_of_goods_sold dans votre flux Merchant Center, le coût de chaque produit, qui peut être approximatif quand la donnée exacte n’est pas disponible.
Croisées, les deux peuvent déverrouiller le reporting de profit brut, revenu moins COGS, par campagne et par produit, notamment sur les campagnes liées à Merchant Center.
Et le point que tout le monde rate : le COGS seul ne produit rien. Sans l’appariement aux conversions avec panier, il dort dans le flux et n’apparaît dans aucun rapport. C’est un système à deux pièces ; en poser une, c’est n’avoir rien posé.
Ce que l’étage 1 change déjà (sans toucher aux enchères)
Ne sous-estimez pas la lecture : voir enfin le profit par campagne, c’est découvrir que votre meilleure campagne au ROAS est parfois votre troisième au profit, que telle gamme star vend beaucoup et rapporte peu, que tel segment discret finance le reste. Ces découvertes redistribuent les budgets à la main entre campagnes, recalibrent les cibles tROAS par segment, et valident, chiffres en main, la segmentation par marge construite côté flux. C’est déjà un pilotage à part entière : la machine enchérit encore sur le CA, mais vous arbitrez enfin sur une lecture plus proche du profit.
Étage 2 : faire enchérir la machine sur la marge
Changer la valeur transmise, c'est changer de référentiel, préparation et ordre sain.
Étage 2 : piloter au profit, la marge comme valeur de conversion
Le saut de régime, maintenant : remplacer la valeur transmise. Au lieu d’envoyer le montant de la commande, votre système, un calcul serveur ou la donnée de coût de votre plateforme, envoie la marge de la commande comme valeur de conversion.
La conséquence est majeure : le Smart Bidding optimise la valeur que vous lui transmettez, et peut donc favoriser le profit plutôt que le chiffre d’affaires. Il préfère alors la commande à 80 euros qui rapporte 40 à celle de 120 euros qui rapporte 25, ce qu’un simple réglage de cible ferait mal sur des valeurs de CA.
C’est le POAS rendu opérationnel, la stratégie d’enchères qui maximise le profit plutôt que le ROAS ; la doctrine complète et la décision d’y aller vivent dans la branche rentabilité de ce cocon. Ici : la application.
Faut-il réécrire la valeur de conversion, ou laisser Google enchérir sur le profit nativement ?
Réponse pratique : si votre cas tient dans le périmètre natif disponible dans votre compte, privilégiez-le. Réécrire la valeur de conversion est un hack puissant mais coûteux à maintenir ; ce n’est pas une fin en soi, c’est le recours quand le natif ne couvre pas votre besoin.
Il faut distinguer trois choses qu’on amalgame trop vite. Le reporting de profit brut natif (étage 1) sert d’abord à lire le profit : la machine vous montre une lecture plus utile que le chiffre d’affaires seul. La capacité à faire enchérir Google directement sur le profit brut dépend du périmètre réellement disponible dans votre compte, de vos flux et de vos types de campagnes. La réécriture manuelle de la valeur (étage 2 ci-dessous) reste, elle, sous votre contrôle et peut s’appliquer même hors Shopping si votre mesure est fiable.
La consigne pratique en découle. Avant de monter un calcul serveur qui injecte la marge dans la valeur de conversion, vérifiez l’état réel de l’option native dans votre interface Merchant Center et Google Ads : si elle couvre votre type de campagne, vous obtenez l’enchère au profit sans porter une couche de réécriture à vie. Le manuel garde deux territoires propres : les campagnes hors du périmètre natif, et les cas où votre définition de marge diffère de revenu moins COGS du flux (coûts variables que Merchant Center ne connaît pas). Dans les deux régimes, la cible reste votre levier : sur des valeurs de marge, vous repensez vos cibles tROAS par segment autour d’un point mort à 1.
Comment transmettre concrètement la marge comme valeur de conversion ?
Réponse courte : vous décidez de trois choses, où la marge se calcule, à quel grain, et si elle bouge dans le temps. La mécanique du tag d’achat elle-même (les exigences de la valeur, la déduplication) n’est pas le sujet ici, elle est posée dans le socle de la valeur exacte ; ce qui suit, c’est l’arbitrage propre à la marge.
Où calculer. Côté serveur ou via la donnée de coût de votre plateforme e-commerce : fiable, c’est la voie recommandée, parce que la marge réelle vit dans votre back-office, pas dans le navigateur. Le calcul côté client, via GTM et le dataLayer, est fragile pour la marge : le coût d’achat a rarement sa place dans le code public d’une page, et l’exposer y est une fuite autant qu’une source d’erreur.
À quel grain. La marge par produit est la plus précise mais exige le coût de chaque référence dans la donnée source ; c’est la cible. La marge par catégorie, ou un taux moyen appliqué au panier, est approximative mais déployable plus vite, et reste souvent plus utile qu’une optimisation au CA seul. Commencez au grain que vos données permettent, affinez ensuite, quelle marge envoyer relève de votre définition de la rentabilité réelle, pas d’un réglage technique.
Statique ou dynamique. Un taux figé tient tant que vos prix tiennent ; dès qu’il y a promotions, prix variables ou remises de volume, la marge doit se recalculer à chaque commande, sinon vous transmettez une marge théorique à la machine pendant que la marge réelle a déjà changé. Et si vous préférez agir sur le flux plutôt que sur la valeur transmise, segmenter le flux par tranches de marge est la voie complémentaire : deux façons d’apprendre la marge à la machine, à choisir selon votre stack.
Comment préparer la bascule vers l’optimisation par la marge ?
Ce qui rend l’étage 2 exigeant n’est pas la technique, c’est la rupture. Le jour de la bascule, tout votre historique « valeur = CA » devient incomparable : le « ROAS » change d’unité (sur des valeurs de marge, son point mort est 1, chaque euro de pub doit ramener un euro de marge), les cibles se recalculent toutes, et l’algorithme réapprend sur le nouveau signal.
La bascule se prépare donc comme une migration : fenêtre choisie (évitez juste avant un pic), cibles recalculées d’avance, équipe prévenue que les tableaux de bord vont changer de langue. Et le socle de la valeur exacte doit être irréprochable en amont : basculer une mesure douteuse vers la marge, c’est raffiner du faux.
L’ordre est simple : étage 1 digéré, puis étage 2.
Pour qui chaque étage, et la limite
L’étage 1 est utile à la plupart des comptes e-commerce : deux pièces à poser, aucune rupture, une lecture qui change les arbitrages sur vos campagnes. L’étage 2 est pour les comptes mûrs : mesure rapprochée, marges connues par référence et maintenues, volume de conversions confortable, équipe capable d’absorber le changement de référentiel.
La réserve à garder en tête : la marge transmise reste une marge sur coûts variables estimée, elle ignore vos coûts fixes, vos retours futurs, votre LTV. La machine optimisera fidèlement ce qu’on lui donne, et ce qu’on lui donne reste un modèle. Meilleur que le CA, encore en-deçà du réel.
| Critère | Étage 1 : lecture | Étage 2 : consigne |
|---|---|---|
| Ce que ça change | Rapports profit brut par campagne/produit | La machine enchérit sur la marge, pas le CA |
| Prérequis | CwCD + cost_of_goods_sold au flux | Étage 1 digéré + mesure irréprochable + marges connues |
| Rupture ? | Aucune | Oui : historique incomparable, cibles recalculées |
| Pour qui | Tous les comptes ecom | Comptes mûrs uniquement |
| Point mort ROAS | Inchangé (sur CA) | 1 (chaque euro de pub = 1 euro de marge) |
- Les conversions avec données de panier et le cost_of_goods_sold au flux sont deux pièces indissociables : l’une sans l’autre ne produit pas de rapport de profit exploitable.
- L’étage 1 (lecture) est pour tous : voir le profit par campagne et par produit, sans toucher aux enchères.
- L’étage 2 (consigne) change le référentiel entier : point mort à 1, historique incomparable, cibles recalculées. Il se prépare comme une migration.
- Tant que vous transmettez le CA, la machine optimise le CA.
