Les pièges du data blending dans Looker Studio

Le data blending de Looker Studio interroge chaque source de données séparément et joint les résultats côté client. Plusieurs modes de défaillance peuvent gonfler silencieusement les coûts et produire des résultats incorrects.

Ce que fait le blending

Le data blending de Looker Studio interroge chaque source séparément et joint les résultats côté client — dans l’infrastructure de Looker Studio elle-même, et non dans BigQuery. Chaque source génère sa propre requête BigQuery ; les résultats sont joints en mémoire.

Cette architecture a deux conséquences :

1. Chaque requête source s’exécute indépendamment, ce qui signifie que vous perdez les bénéfices d’optimisation offerts par la jointure dans BigQuery. BigQuery peut pousser les filtres en aval, utiliser le partition pruning et optimiser l’ordre des jointures lorsqu’elles se font en SQL. Looker Studio ne le peut pas.

2. Les clés de jointure absentes ou mal alignées créent des produits cartésiens. Si la source A contient 10 000 lignes et la source B en contient 5 000, et que la clé de jointure ne correspond pas correctement, Looker Studio crée 50 000 000 lignes de résultat (10 000 × 5 000). Il s’agit d’une cross join — chaque ligne de gauche multipliée par chaque ligne de droite. C’est exactement ce que signifie l’erreur “This chart requested too much data”, que vous verrez lorsque cela se produit.

Identifier le problème

Trois signes indiquant que le blending est à l’origine de vos problèmes de performance :

1. L’erreur “This chart requested too much data” sur les graphiques utilisant des sources de données blendées. Cela indique presque toujours une cross join ou un jeu de résultats involontairement volumineux résultant du blending.

2. Le volume de requêtes explose lors des changements de filtres. Avec des sources blendées, modifier un filtre déclenche une requête par source, plus une jointure côté client potentiellement très coûteuse. Sur un tableau de bord avec 3 sources blendées et 4 contrôles de filtres, un seul changement de filtre peut déclencher 12 requêtes ou plus.

3. Les dépenses BigQuery attribuées à vos identifiants augmentent brutalement sans changement correspondant du volume de données. Consultez INFORMATION_SCHEMA.JOBS filtré par requestor = 'looker_studio' et comparez les octets traités avant et après l’ajout de sources blendées à un rapport.

Pourquoi les clés de jointure sont défaillantes

La cause la plus fréquente des cross joins silencieuses est une clé de jointure qui semble devoir correspondre, mais qui ne correspond pas :

• Incompatibilités de types : une source a un champ de date stocké sous forme de chaîne ('2026-01-15'), l’autre sous forme de type DATE. La comparaison de Looker Studio échoue silencieusement et revient à une cross join.
• Différences de casse : 'GOOGLE' ne correspond pas à 'google'. De simples problèmes de sensibilité à la casse provoquent des cross joins en cascade.
• Valeurs nulles : si la clé de jointure contient des nulls dans l’une ou l’autre source, ces lignes ne correspondent à aucune clé de l’autre source. Selon la façon dont Looker Studio gère cela, vous pouvez obtenir des lignes dupliquées inattendues ou des lignes supprimées.
• Incompatibilités de grain : la source A est au grain journalier, la source B est au grain de la session. Sauf si vous en agrégez une avant le blend, la jointure multiplie les lignes.

La solution : pré-joindre dans BigQuery

La bonne solution pour presque tous les cas d’usage du blending est de pré-joindre les données dans BigQuery en SQL, puis de connecter Looker Studio à une seule source de données.

À la place de ceci (deux sources de données Looker Studio, blendées) :

• Source 1 : sessions GA4 par date + campagne
• Source 2 : dépenses Google Ads par date + campagne
• Blendé sur : date + campagne

Faites ceci dans BigQuery (une vue SQL ou un modèle dbt unique) :

CREATE OR REPLACE VIEW `project.analytics.dashboard_acquisition` AS
SELECT
  ga.date,
  ga.campaign,
  ga.sessions,
  ga.conversions,
  ads.impressions,
  ads.clicks,
  ads.cost_usd
FROM analytics.ga4_sessions_daily ga
LEFT JOIN ads.google_ads_daily ads
  ON ga.date = ads.date
  AND ga.campaign = ads.campaign_name  -- Alias explicite pour garantir la correspondance de type

Connectez Looker Studio à dashboard_acquisition. Une requête par graphique. Aucune jointure côté client. Aucun risque de cross join. Et vous pouvez valider la logique de jointure en SQL avant de la déployer.

C’est pour la même raison que le partitionnement et le clustering fonctionnent mieux que les filtres Looker Studio pour la maîtrise des coûts : l’optimisation se produit dans le moteur de requêtes de BigQuery, qui est conçu pour cela, plutôt que dans la couche de reporting, qui ne l’est pas.

Quand le blending est inévitable

Parfois, le blending est véritablement nécessaire — généralement lorsque vous devez combiner des données provenant de différents produits Google (Search Console + GA4, par exemple) pour lesquels une représentation BigQuery partagée n’existe pas, ou lorsque le pipeline nécessaire à sa création n’en vaut pas l’effort.

Si vous devez blender :

1. Limitez-vous à 5 sources ou moins. Looker Studio supporte jusqu’à 5 sources dans un blend, mais les performances se dégradent rapidement au-delà de 2 à 3. Chaque source supplémentaire représente un aller-retour de requête supplémentaire et une jointure en mémoire supplémentaire.

2. Vérifiez que les clés de jointure correspondent exactement. Vérifiez les types de données, la casse et le grain avant la publication. Ajoutez un graphique de test affichant le nombre de lignes de chaque source et du résultat blendé — si le nombre blendé est significativement supérieur à celui de l’une ou l’autre source, vous avez une cross join.

3. Agrégez avant de blender. Si la source A est au niveau événement et la source B au niveau session, créez un champ calculé Looker Studio ou utilisez une requête personnalisée qui agrège la source A au niveau session avant le blend.

4. Utilisez le mode extract pour les sources blendées stables. Si l’une de vos sources blendées est une table de référence qui change mensuellement (une taxonomie de campagnes, un mapping de pays), placez-la en mode extract. Cela réduit la charge de requêtes en temps réel et limite l’impact des erreurs de cross join.

L’alternative de la couche sémantique

Le problème sous-jacent du blending Looker Studio est l’absence d’une couche sémantique. Looker (Enterprise) le résout grâce à la syntaxe join de LookML, qui définit les relations une seule fois et les applique à l’ensemble des explores. Lightdash lit les définitions de jointure à partir des fichiers YAML de dbt. Looker Studio ne dispose d’aucun de ces mécanismes — il place la charge de la logique de jointure sur chaque auteur de rapport, qui peut ne pas comprendre les implications en termes de grain.

Si vous vous retrouvez à gérer plus de 2 à 3 sources de données blendées dans plusieurs rapports, la charge de maintenir ces blends — déboguer les cross joins, corriger les rapports cassés lors de changements de schéma des sources, réexpliquer la logique de jointure à chaque nouvel analyste — est généralement suffisante pour justifier le déplacement des jointures dans BigQuery, ou l’évaluation d’un outil BI doté d’une sémantique de jointure de première classe. Le cadre de sélection des outils BI couvre ces compromis.