Merchant Center Query Language : lire les rapports produits sans se perdre

Merchant Center Query Language, ou MCQL, peut faire peur au premier contact. On voit du SELECT, du FROM, du WHERE, des vues comme product_performance_view, et on se dit vite que le sujet appartient uniquement aux développeurs.

Ce serait dommage. Pour un SEO e-commerce, un responsable acquisition ou un éditeur de boutique, MCQL sert surtout à poser des questions propres : quels produits ont des impressions mais peu de clics ? Quels articles sont limités ou refusés ? Quelles marques fonctionnent le mieux ? Est-ce que les performances viennent plutôt du gratuit, des annonces, d’un pays, d’une catégorie ou d’un lot de produits précis ?

Le bon usage n’est pas de transformer Merchant Center en usine à dashboards. C’est de sortir quelques rapports lisibles, réguliers, reliés aux vraies décisions : corriger un flux, prioriser des fiches produit, vérifier les données structurées, repérer les écarts de prix, ou comprendre pourquoi une partie du catalogue ne travaille pas assez.

MCQL, c’est quoi exactement ?

Google définit Merchant Center Query Language comme un langage de requête, proche de SQL, utilisé avec la Merchant Reports API. L’idée est simple : vous envoyez une requête à reports.search, et Merchant API renvoie les lignes correspondant à la vue demandée.

La requête ressemble à une mini-question structurée. SELECT indique les champs à récupérer. FROM indique la vue interrogée. WHERE filtre par date, pays, statut, méthode marketing ou autre dimension disponible. ORDER BY trie les résultats. LIMIT évite de récupérer un volume inutile.

SELECT offer_id, impressions, clicks, click_through_rate
FROM product_performance_view
WHERE date BETWEEN '2026-10-01' AND '2026-10-31'
ORDER BY impressions DESC
LIMIT 50

Ce n’est pas du SQL complet. On ne fait pas de jointures libres, on ne mélange pas n’importe quelles tables, et Google précise que l’on ne peut interroger qu’une seule vue par requête. En échange, la syntaxe force une bonne discipline : partir d’une question, choisir la bonne vue, sélectionner les bons champs, filtrer, puis lire les résultats.

Avant de lancer des requêtes

Avant de penser syntaxe, il faut vérifier le contexte. L’API Merchant Reports demande un compte Merchant Center contenant des données produit. Pour certains rapports de performance, Google indique aussi qu’il faut disposer du rôle Performances et insights. Sans les bons accès, la meilleure requête du monde ne renverra rien d’exploitable.

Il faut aussi accepter une limite importante : les rapports ne remplacent pas la donnée source. MCQL vous aide à lire ce que Merchant Center voit ou mesure. Il ne corrige pas automatiquement un prix faux, une image inaccessible, un flux obsolète ou une page produit incohérente. Pour ça, il faut revenir au flux, à l’API d’alimentation, au CMS, au PIM ou au template produit.

Si votre sujet est encore de choisir entre flux fichier, Content API historique et Merchant API, relisez d’abord le guide sur Merchant API / Content API / flux Merchant Center. MCQL arrive après : quand les produits existent déjà dans Merchant Center et que l’on veut comprendre ce qui se passe.

Les vues vraiment utiles

Le piège consiste à vouloir tout interroger. Pour un usage SEO/e-commerce, mieux vaut commencer avec quelques vues qui répondent à des questions simples.

product_view sert à lire l’état des produits : identifiants, titres, feed labels, statut agrégé, problèmes, contexte de diffusion. C’est utile pour comprendre pourquoi une partie du catalogue est limitée, refusée ou mal servie.

product_performance_view sert à lire les performances : impressions, clics, CTR, conversions ou autres métriques selon les champs disponibles et les accès. C’est souvent la vue la plus utile pour repérer les produits visibles mais peu cliqués, ou les produits qui attirent des clics sans convertir.

price_insights_product_view peut aider sur la lecture prix, notamment quand Google fournit des suggestions ou impacts prédits. Ce n’est pas une consigne automatique de baisse tarifaire. C’est un signal à croiser avec marge, stock, saison, concurrence et positionnement.

Les vues de marché, comme les best-sellers ou la visibilité concurrentielle, sont plus sensibles. Elles peuvent être très utiles pour comprendre une catégorie, mais Google rappelle qu’elles peuvent dépendre d’exigences d’éligibilité et de conditions d’utilisation. À utiliser avec plus de prudence, surtout si vous exportez ou partagez ces données.

5 requêtes simples pour commencer

Les exemples ci-dessous ne remplacent pas les champs exacts de votre compte, mais ils donnent une manière saine de réfléchir. Une bonne requête MCQL ne commence pas par “quels champs puis-je sortir ?”. Elle commence par “quelle décision dois-je prendre ?”.

1. Lister les produits refusés ou non éligibles

SELECT
  id,
  offer_id,
  feed_label,
  title,
  aggregated_reporting_context_status,
  item_issues
FROM product_view
WHERE aggregated_reporting_context_status = 'NOT_ELIGIBLE_OR_DISAPPROVED'

Cette requête sert à sortir du brouillard. Au lieu de regarder “des problèmes Merchant Center” globalement, vous obtenez une liste de produits concernés. Ensuite, le vrai travail consiste à regrouper les erreurs : problème d’attribut obligatoire, image, prix, disponibilité, identifiant, catégorie ou politique.

2. Trouver les produits très visibles mais peu cliqués

SELECT
  offer_id,
  impressions,
  clicks,
  click_through_rate
FROM product_performance_view
WHERE date DURING LAST_30_DAYS
ORDER BY impressions DESC
LIMIT 100

Cette vue aide à repérer les produits que Google expose déjà. Si les impressions sont fortes et les clics faibles, le problème peut venir du prix, de l’image principale, du titre, de l’offre, de la concurrence ou de l’intention. C’est un bon point de départ pour améliorer les fiches produit les plus visibles.

3. Séparer gratuit et annonces

SELECT
  marketing_method,
  offer_id,
  impressions,
  clicks
FROM product_performance_view
WHERE date BETWEEN '2026-10-01' AND '2026-10-31'
ORDER BY clicks DESC
LIMIT 100

La segmentation par marketing_method permet de distinguer ce qui vient des surfaces gratuites et ce qui vient de l’écosystème ads, quand la donnée est disponible. C’est précieux pour éviter de croire qu’une fiche travaille en SEO alors qu’elle est surtout portée par les annonces, ou l’inverse.

4. Lire les signaux prix sans obéir aveuglément

SELECT
  id,
  title,
  brand,
  price,
  suggested_price,
  predicted_impressions_change_fraction,
  predicted_clicks_change_fraction
FROM price_insights_product_view

Les signaux prix sont utiles, mais ils peuvent devenir dangereux si on les lit sans marge ni stratégie. Une baisse peut améliorer un clic et détruire une rentabilité. À l’inverse, un prix trop haut peut rendre une fiche invisible face aux concurrents. MCQL donne un signal, pas une décision automatique.

5. Regarder une catégorie de marché

SELECT
  report_date,
  report_country_code,
  report_category_id,
  rank,
  relative_demand,
  title,
  brand,
  inventory_status
FROM best_sellers_product_cluster_view
WHERE report_date = '2026-10-26'
  AND report_granularity = 'WEEKLY'
  AND report_country_code = 'FR'
ORDER BY rank
LIMIT 50

Les rapports de marché peuvent aider à comprendre une catégorie, repérer des produits populaires ou voir si vous portez déjà certains articles. Mais il faut garder la tête froide : disponibilité des données, éligibilité du compte, pays, catégorie et conditions d’utilisation comptent autant que la syntaxe.

Ce que ça change pour le SEO e-commerce

MCQL ne remplace pas Search Console, un crawl de site ou un outil analytics. Il ajoute une couche très utile : la lecture produit telle que Merchant Center la voit. C’est un angle que beaucoup d’audits SEO négligent encore.

Premier usage : repérer les écarts entre flux et page. Si Merchant Center voit un prix, un stock, une URL, une image ou un statut qui ne correspond pas à la page publique, vous avez un problème de confiance. Ce sujet rejoint directement les données structurées e-commerce : Google doit lire un produit cohérent entre page, JSON-LD, flux et Merchant Center.

Deuxième usage : prioriser les fiches à améliorer. Toutes les fiches produit ne méritent pas la même attention. Une fiche avec beaucoup d’impressions et peu de clics vaut souvent une reprise plus rapide qu’une fiche invisible sans stock ni intérêt commercial. MCQL aide à sortir cette priorité depuis les données produit.

Troisième usage : nettoyer les variantes. Les familles de produits, tailles, couleurs, item group IDs, images et URLs peuvent vite devenir confuses. Si vous travaillez sur ce sujet, le guide sur ProductGroup, variantes e-commerce et données structurées complète bien l’approche.

Quatrième usage : préparer des contenus utiles. Les best-sellers, catégories, marques visibles et produits qui montent peuvent nourrir des guides d’achat, comparatifs, pages catégories et articles saisonniers. Là encore, il ne faut pas créer des pages faibles à partir d’un rang de marché. Il faut confirmer l’intention, la marge, la disponibilité et la capacité à apporter une vraie aide au lecteur.

Tableau de décision

Les erreurs qui rendent les rapports inutilisables

La première erreur est de sélectionner trop de champs. Chaque segment ajouté peut multiplier les lignes. Google rappelle d’ailleurs que les lignes augmentent avec les combinaisons de segments. Si vous ajoutez date, pays, méthode marketing, marque, catégorie et produit en même temps, vous pouvez obtenir un tableau énorme, lent et difficile à lire.

La deuxième erreur est de comparer des périodes incohérentes. Un produit saisonnier, une promo, une rupture stock ou une campagne active peut changer complètement le sens d’un rapport. Il vaut mieux comparer deux périodes propres que regarder un mois isolé sans contexte.

La troisième erreur est de lire un rapport comme une vérité business complète. Merchant Center peut dire qu’un produit reçoit des impressions. Cela ne dit pas si la marge est bonne, si le stock est sain, si la page convertit, si le contenu aide le client ou si le produit mérite une mise en avant éditoriale.

La quatrième erreur est de mélanger les sujets. Les problèmes d’éligibilité se lisent surtout avec product_view. Les clics et impressions se lisent avec les vues de performance. Les signaux prix ont leur propre contexte. Les rapports de marché ont leurs conditions. Tout mettre dans le même tableau crée plus de bruit que de clarté.

Routine mensuelle propre

Une routine utile peut tenir en quatre exports ou quatre requêtes. Pas besoin d’un cockpit de 25 onglets.

Cette routine se connecte naturellement à l’article sur l’IA générative en e-commerce. L’IA peut aider à résumer les rapports ou proposer des pistes, mais elle doit partir de données fiables. Un mauvais flux enrichi par une IA reste un mauvais flux.

Une vidéo officielle utile pour visualiser MCQL

Google Ads a publié une vidéo courte sur la création de dashboards retail avec MCQL. Elle est en anglais, mais elle colle bien au sujet : on voit mieux comment la logique de requête peut servir à construire une lecture produit exploitable, pas seulement à écrire du code.

Vidéo publiée par la chaîne Google Ads.