AccueilE-commerceOptimiser Google Ads sur la marge : deux étages, un ordre non négociable

Optimiser Google Ads sur la marge : deux étages, un ordre non négociable

En bref

Piloter à la marge, c’est deux étages à ne jamais confondre. L’étage lecture, pour tous : conversions avec données de panier plus l’attribut cost_of_goods_sold au flux donnent un reporting de profit brut natif, par campagne et par produit. Le COGS seul, sans cet appariement, ne produit rien. L’étage consigne, pour les comptes mûrs, fait de la marge la valeur que la machine maximise.

Reprenons la phrase qui ouvre tout ce cocon : Google voit votre chiffre d’affaires, il ne verra jamais votre marge. Toute la stratégie e-commerce en découle, et cette page est l’endroit où la phrase cesse d’être une fatalité.

La machine peut connaître votre marge, à deux niveaux très différents : en lecture (elle vous montre le profit, mais enchérit toujours sur 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.

Étage 1 : voir le profit, le reporting natif que presque personne n’active

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 (source : Google Ads Help, juin 2026).

Pièce deux : l’attribut cost_of_goods_sold dans votre flux Merchant Center, le coût de chaque produit, qui peut être approximatif. Google accepte explicitement une estimation ou une moyenne (source : Merchant Center Help, juin 2026).

Croisées, les deux déverrouillent le reporting de profit brut, revenu moins COGS, par campagne et par produit, sur Performance Max, Shopping et Search liés à Merchant Center (source : Google Ads Help, juin 2026).

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é.

L’erreur que je vois le plus
Le cost_of_goods_sold est renseigné dans le flux Merchant Center, mais les conversions avec données de panier ne sont pas activées. Résultat : zéro rapport de profit brut, zéro visibilité sur la marge par produit. Les deux pièces sont indissociables.

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, recalibrent les cibles tROAS par segment, et valident, chiffres en main, la segmentation par marge construite côté flux. La machine enchérit encore sur le CA, mais vous arbitrez enfin sur le vrai.

É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 totale : le Smart Bidding, qui maximise littéralement la valeur transmise, se met à maximiser votre profit. Il préfère désormais la commande à 80 euros qui rapporte 40 à celle de 120 euros qui rapporte 25, ce qu’aucun réglage de cible ne lui ferait faire sur des valeurs de CA.

C’est le POAS rendu opérationnel ; la doctrine complète et la décision d’y aller vivent dans la branche rentabilité de ce cocon. Ici : la mise en oeuvre.

La bascule : un changement de référentiel, pas un réglage

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 (jamais 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 n’est pas négociable : étage 1 digéré, puis étage 2, jamais l’inverse.

Pour qui chaque étage, et la limite

L’étage 1 est pour tous : deux pièces à poser, aucune rupture, une lecture qui change les arbitrages. Il n’y a pas de bonne raison de s’en passer. 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 limite, sans détour : 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, toujours 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)
À retenir
  • 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 aucun rapport de profit.
  • 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, jamais il ne s’improvise.
  • Tant que vous transmettez le CA, la machine optimise le CA.

Questions fréquentes

Est-ce que le cost_of_goods_sold dans le flux suffit pour optimiser sur la marge ?
Non. Il déverrouille du reporting de profit brut quand il est croisé aux conversions avec données de panier. Seul, sans cet appariement, il ne s’affiche dans aucun rapport et ne pilote aucune enchère.
Peut-on utiliser un COGS approximatif ou une estimation ?
Oui. Google Merchant Center accepte explicitement un coût estimé ou une moyenne par produit (source : Merchant Center Help, juin 2026). Un COGS imparfait vaut mieux que rien : le reporting sera moins précis, mais il sera utile.
Quand bascule-t-on vers l’étage 2 ?
Quand l’étage 1 est digéré, la mesure irréprochable, les marges stables par référence produit et le volume de conversions confortable. Jamais avant un pic saisonnier. La fenêtre se choisit, les cibles se recalculent avant, l’équipe est prévenue.
La marge transmise reflète-t-elle le vrai profit ?
Pas entièrement. C’est une marge sur coûts variables estimée : elle ignore les coûts fixes, les retours, la LTV. La machine optimisera fidèlement ce signal, qui reste un modèle, meilleur que le CA, mais en-deçà du réel complet.
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 machine enchérit encore sur du chiffre d’affaires ?

Vous pilotez encore au CA ? On active le reporting marge et on voit le reste.

Réserver un appelParlons de vos objectifs