Conception des Dashboards d'Attribution

La mission d’un dashboard d’attribution est de rendre les sorties des modèles actionnables. Les données sous-jacentes proviennent d’un modèle de comparaison qui réunit plusieurs modèles d’attribution avec un discriminateur model_type. La couche dashboard ajoute de l’interactivité — changement de modèle, vues adaptées aux audiences et le contexte visuel qui transforme des chiffres en décisions.

La segmentation par audience est la principale décision de conception : les dirigeant·es ont besoin de réponses directionnelles d’un seul modèle ; les managers ont besoin de changer de modèle pour tester la robustesse des performances des canaux ; les analystes ont besoin d’une granularité complète pour l’investigation des chemins. Montrer la même vue à tous·tes les trois produit un dashboard qui ne sert aucun·e d’entre eux·elles.

Métriques Essentielles

Contribution par canal selon le modèle

La vue principale. Un graphique à barres montrant les revenus attribués par canal, avec le modèle d’attribution comme filtre déroulant. Les utilisateurs·rices basculent entre les modèles premier contact, dernier contact, linéaire, basé sur la position, décroissance temporelle et autres pour voir comment le crédit se déplace entre les canaux.

Cette seule vue communique l’insight le plus important : quels canaux contribuent le plus, et dans quelle mesure cette réponse est-elle stable selon différentes hypothèses de modélisation ? Si les classements restent à peu près les mêmes d’un modèle à l’autre, la confiance est élevée. Si un canal passe de la 2e place sous premier contact à la 7e place sous dernier contact, cette instabilité est l’histoire à raconter.

Vue de comparaison des modèles

Un graphique à barres groupées montrant tous les modèles côte à côte pour chaque canal. Cela met immédiatement en évidence les points de divergence entre modèles. Les canaux avec l’écart le plus large entre barres sont ceux où l’attribution est la plus incertaine — ceux qui méritent une investigation avec des tests d’incrémentalité.

Cette vue est la représentation visuelle du concept de désaccord comme signal. L’écart lui-même est l’insight.

Conversions assistées

Les touchpoints qui ont contribué à une conversion mais n’étaient pas le touchpoint crédité sous les modèles à contact unique. Calculez-les comme le nombre de touchpoints dans un chemin de conversion moins un :

WITH path_lengths AS (
  SELECT
    conversion__id,
    touchpoint__channel,
    COUNT(*) OVER (
      PARTITION BY conversion__id
    ) AS total_touchpoints_in_path
  FROM {{ ref('mrt__attribution__first_touch') }}
)

SELECT
  touchpoint__channel,
  COUNT(DISTINCT conversion__id) AS total_conversions,
  COUNT(DISTINCT CASE
    WHEN total_touchpoints_in_path > 1 THEN conversion__id
  END) AS assisted_conversions,
  SAFE_DIVIDE(
    COUNT(DISTINCT CASE
      WHEN total_touchpoints_in_path > 1 THEN conversion__id
    END),
    COUNT(DISTINCT conversion__id)
  ) AS assist_rate
FROM path_lengths
GROUP BY touchpoint__channel

Des taux élevés de conversions assistées indiquent des canaux qui nourrissent plutôt que qui ferment. Ces canaux semblent faibles sous l’attribution au dernier contact mais peuvent être essentiels au parcours client. Cette métrique donne à ces canaux un moyen de démontrer leur contribution en dehors des modèles à contact unique qui les ignorent.

CPA et ROAS par modèle

Le coût par acquisition et le retour sur dépenses publicitaires, calculés pour chaque modèle d’attribution. La formule change selon le modèle dont vous utilisez les revenus au dénominateur :

SELECT
  c.model_type,
  c.touchpoint__channel,
  SUM(c.touchpoint__attributed_revenue) AS attributed_revenue,
  s.total_spend,
  SAFE_DIVIDE(SUM(c.touchpoint__attributed_revenue), s.total_spend) AS roas,
  SAFE_DIVIDE(s.total_spend, COUNT(DISTINCT c.conversion__id)) AS cpa
FROM {{ ref('mrt__attribution__comparison') }} c
LEFT JOIN {{ ref('mrt__marketing__channel_spend') }} s
  ON c.touchpoint__channel = s.channel
  AND DATE(c.conversion__converted_at) = s.spend_date
GROUP BY c.model_type, c.touchpoint__channel, s.total_spend

La jointure des revenus attribués avec les données de dépenses réelles des plateformes publicitaires vous donne un ROAS calculé sur un terrain neutre — la même méthodologie d’attribution appliquée de manière cohérente à tous les canaux, en utilisant les dépenses réelles plutôt que les métriques rapportées par les plateformes.

Distribution de la longueur des chemins

Un histogramme montrant combien de touchpoints les conversions incluent typiquement. Les chemins courts (1 à 2 touchpoints) favorisent les modèles à contact unique — premier contact et dernier contact donnent la même réponse quand il n’y a qu’un seul touchpoint. Les chemins plus longs (5+ touchpoints) rendent les modèles multi-touch plus importants car les modèles à contact unique ignorent la majorité du parcours client.

Cette distribution éclaire le choix du modèle. Si 80% de vos conversions ont des chemins à touchpoint unique, la différence entre les modèles est minime et vous pouvez simplifier votre approche. Si la longueur médiane du chemin est de 6 touchpoints, les modèles multi-touch fournissent des résultats substantiellement différents (et sans doute plus informatifs).

Hiérarchie de Dashboards par Audience

Tout le monde n’a pas besoin du même niveau de détail. Structurez vos dashboards autour des besoins décisionnels, pas de la hiérarchie organisationnelle.

Dashboard Dirigeant·e (CMO, CEO)

L’impact sur les résultats de l’entreprise. Total des revenus attribués, revenus par canal à un niveau élevé, ROI global, coût d’acquisition client. Cadence hebdomadaire ou mensuelle.

Pas de sélection de modèle. Affichez une vue fusionnée ou le modèle principal approuvé par l’entreprise. Les dirigeant·es ont besoin de réponses directionnelles, pas de choix méthodologiques. Si vous présentez cinq modèles à un·e CMO, il·elle demandera « lequel est le bon ? » et la réponse — « aucun d’eux, l’étendue est l’insight » — requiert un contexte qui ne rentre pas dans un dashboard exécutif.

Pré-sélectionnez la vue. Ajoutez un seul encadré pour les canaux où les modèles divergent significativement, formulé comme « zones d’incertitude » plutôt que « nous ne savons pas ».

Dashboard Manager

Performances des canaux par modèle, décompositions au niveau des campagnes, recommandations d’allocation budgétaire. Cadence hebdomadaire.

Incluez le sélecteur de modèle pour que les managers puissent tester la robustesse des performances de leurs canaux sous différentes hypothèses. Un·e manager paid media devrait pouvoir basculer du dernier contact (qui fait probablement bien paraître son canal) au premier contact (qui le fait probablement moins bien paraître) et comprendre la plage.

Ajoutez des courbes de tendance. Les revenus attribués à un canal qui changent entre modèles au fil du temps révèlent si le rôle du canal dans le parcours évolue — passant de la notoriété (crédit premier contact) à la conversion (crédit dernier contact) ou inversement.

Dashboard Analyste

Analyse granulaire des touchpoints, exploration des chemins, détails de comparaison des modèles, analyse du délai de conversion. Accès quotidien.

Accès complet à tous les filtres et dimensions pour une investigation approfondie. C’est ici que la table de comparaison détaillée (pas le résumé pré-agrégé) devrait être accessible. Les analystes ont besoin de pouvoir examiner des chemins de conversion individuels quand quelque chose d’inattendu apparaît dans les vues agrégées.

Implémentation Looker Studio

Looker Studio est le chemin de moindre résistance pour les équipes BigQuery — il est gratuit et se connecte nativement. L’implémentation s’appuie directement sur le modèle de comparaison.

Connexion aux données. Connectez-vous à la table mrt__attribution__comparison_summary dans BigQuery. Le modèle de résumé pré-agrégé offre de meilleures performances que la table détaillée pour la plupart des vues.

Sélecteur de modèle. Créez un contrôle déroulant lié au champ model_type et ajoutez-le à chaque page. Cela donne aux utilisateurs·rices un changement de modèle en un clic. Le menu déroulant récupère automatiquement les nouveaux modèles quand vous les ajoutez à l’union de comparaison — aucune modification du dashboard n’est nécessaire.

Tableau croisé de comparaison. Pour la vue de comparaison des modèles, utilisez un tableau croisé dynamique avec le canal en lignes, model_type en colonnes et SUM(touchpoint__attributed_revenue) comme métrique. Cela crée une comparaison côte à côte sans configuration de graphique complexe.

Contrôle de plage de dates. Ajoutez un contrôle de plage de dates lié à conversion_date. L’attribution évolue dans le temps à mesure que votre mix de canaux change, donc la plage de dates est plus importante ici que dans beaucoup d’autres dashboards.

Contournement des Limitations de Looker Studio

Looker Studio est gratuit et s’intègre bien avec BigQuery, mais il a des contraintes qui affectent spécifiquement les dashboards d’attribution.

Limite de visualisation de 5 000 lignes. Les graphiques ne peuvent afficher que 5 000 lignes. Pour les données au niveau des touchpoints, cette limite est vite atteinte. Le modèle de résumé pré-agrégé dans le pattern de comparaison résout cela — agrégez au niveau jour/canal dans dbt plutôt que de s’appuyer sur Looker Studio pour agréger au rendu.

Pas de diagrammes Sankey natifs. La visualisation des chemins est une demande courante pour les dashboards d’attribution, mais Looker Studio ne prend pas en charge les graphiques Sankey. Contournements :

• Plugins de visualisation communautaires tiers (qualité variable)
• Un tableau d’analyse des chemins montrant les N premières séquences de canaux par conversion
• Déplacer la visualisation des chemins vers un outil distinct si c’est une exigence critique

Drill-through limité. Il n’est pas facile de cliquer sur un canal et de passer dans ses campagnes, puis dans des conversions individuelles. Contournez cela avec des dashboards liés : ajoutez un paramètre de filtre qui transmet le canal sélectionné à une page de détail via des paramètres d’URL.

Pas de contrôle de version. Les modifications du dashboard ne sont pas suivies. Documentez les modifications manuellement ou maintenez un journal des modifications à côté de votre projet dbt. Il s’agit d’une lacune de gouvernance — la couche de données a un historique Git complet via dbt, mais la couche de visualisation n’en a aucun.

Quand Envisager des Alternatives

Les limitations de Looker Studio deviennent pénibles à grande échelle. Envisagez des alternatives quand :

• Vous avez besoin de la visualisation des chemins (diagrammes Sankey) comme fonctionnalité centrale
• Vous avez besoin d’un drill-through sur plusieurs niveaux de détail
• La gouvernance des dashboards (contrôle de version, workflows de revue) est une exigence
• Votre équipe dépasse ~20 utilisateurs·rices réguliers·ères de dashboards et nécessite des permissions différenciées

Tableau (~70 $/utilisateur/mois) offre une meilleure visualisation des chemins et un meilleur drill-through. Metabase (gratuit en auto-hébergement) fonctionne bien si vous l’utilisez déjà. Power BI (10-20 $/utilisateur/mois) s’intègre dans les écosystèmes Microsoft. Lightdash lit directement depuis le YAML dbt. Chacun présente des compromis ; Looker Studio reste la valeur par défaut pour les petites et moyennes équipes BigQuery.