BigQuery ML pour le lead scoring

Le lead scoring par règles atteint généralement une précision de 60 à 70 %. Les modèles ML entraînés sur des données de conversion historiques peuvent atteindre 80 à 90 % en identifiant des patterns indiscernables par inspection. BigQuery ML le permet sans quitter le SQL.

Exigence minimale en données : 1 000 conversions historiques pour un modèle significatif, avec 5 000+ nécessaires pour que le ML surpasse clairement des règles bien calibrées. En dessous de ce seuil, le scoring par règles est le point de départ approprié.

Entraîner le modèle

BigQuery ML utilise la syntaxe SQL standard CREATE MODEL. Commencez par la régression logistique — elle est interprétable, ce qui est important quand vous devez expliquer le modèle aux équipes commerciales :

CREATE OR REPLACE MODEL `project.ml.lead_scoring_model`
TRANSFORM(
  ML.STANDARD_SCALER(lead__website_visits) OVER() AS lead__website_visits_scaled,
  ML.STANDARD_SCALER(lead__email_engagement) OVER() AS lead__email_engagement_scaled,
  ML.QUANTILE_BUCKETIZE(lead__company_size, 5) OVER() AS lead__company_size_bucket,
  ML.IMPUTER(lead__days_since_last_activity, 'mean') OVER() AS lead__days_inactive,
  lead__industry,
  lead__job_seniority,
  lead__is_converted
)
OPTIONS(
  model_type = 'LOGISTIC_REG',
  input_label_cols = ['lead__is_converted'],
  auto_class_weights = TRUE
) AS
SELECT
  lead__website_visits,
  lead__email_engagement,
  lead__company_size,
  lead__days_since_last_activity,
  lead__industry,
  lead__job_seniority,
  lead__is_converted
FROM {{ ref('mrt__sales__lead_training_dataset') }}

Les données d’entraînement proviennent d’un modèle dbt qui joint les features comportementales, démographiques et firmographiques avec le label de conversion historique. Voir Feature engineering pour le ML dans dbt pour créer ce dataset d’entraînement.

La clause TRANSFORM

Sans TRANSFORM, les étapes de prétraitement (normalisation, discrétisation, imputation) doivent être répliquées à l’identique au moment de la prédiction. Tout désalignement entre le prétraitement à l’entraînement et à la prédiction crée un bug silencieux : le modèle prédit sur des données brutes alors qu’il a été entraîné sur des données normalisées, produisant des scores incorrects sans message d’erreur.

La clause TRANSFORM intègre le prétraitement dans le modèle lui-même. Quand vous appelez ML.PREDICT, les mêmes transformations s’exécutent automatiquement sur vos données de prédiction. Vous ne pouvez pas désaligner le prétraitement entraînement/prédiction car il n’existe qu’un seul endroit où cette logique vit.

Les transformateurs spécifiques utilisés ici :

• ML.STANDARD_SCALER — normalise les features continues à moyenne 0, écart type 1. Requis pour la régression logistique, qui est sensible à l’échelle des features.
• ML.QUANTILE_BUCKETIZE — convertit la taille de l’entreprise (une variable continue asymétrique) en 5 intervalles ordinaux. Gère mieux les valeurs aberrantes que les valeurs brutes.
• ML.IMPUTER — remplace les valeurs manquantes par la moyenne de la colonne. Les fiches de leads contiennent souvent des lacunes, et les entrées NULL bloquent l’entraînement du modèle.

Pour les colonnes catégorielles de type chaîne comme industry et job_seniority, BigQuery ML gère automatiquement l’encodage one-hot. Vous n’avez pas besoin de créer des variables indicatrices manuellement.

Gérer le déséquilibre de classes

auto_class_weights = TRUE est nécessaire pour le lead scoring. Les leads convertis représentent typiquement 2 à 10 % du total des leads. Sans pondération de classes, un modèle prédisant “ne convertira pas” pour chaque lead atteint 90 à 98 % de précision sur les données d’entraînement — haute précision, mais le modèle n’identifie jamais un cas positif.

auto_class_weights = TRUE pondère les exemples positifs (conversions) inversement proportionnellement à leur fréquence. Manquer une vraie conversion est pénalisé plus lourdement qu’un faux positif. Cela échange la précision globale contre un meilleur rappel sur la classe minoritaire.

Évaluer le modèle

Après l’entraînement, interrogez les métriques d’évaluation :

SELECT
  precision,
  recall,
  accuracy,
  f1_score,
  roc_auc
FROM ML.EVALUATE(MODEL `project.ml.lead_scoring_model`)

Visez un AUC (aire sous la courbe ROC) de 0,80 ou plus. L’AUC mesure la capacité du modèle à séparer les convertisseurs des non-convertisseurs sur tous les seuils possibles — un modèle qui classe les convertisseurs au-dessus des non-convertisseurs 80 % du temps a un AUC de 0,80.

La précision seule est trompeuse avec des données déséquilibrées. Un modèle qui prédit “ne convertira pas” pour chaque lead a 95 % de précision si votre taux de conversion est de 5 %. L’AUC pénalise cela — un classifieur aléatoire a un AUC de 0,5, et un modèle “toujours prédire négatif” ne fera pas beaucoup mieux.

La précision et le rappel ensemble révèlent le compromis effectué. La précision indique : parmi tous les leads que le modèle considère comme chauds, quelle fraction a réellement converti ? Le rappel indique : parmi tous les vrais convertisseurs, quelle fraction le modèle a-t-il identifiée ? Vous ne pouvez pas optimiser les deux simultanément. Pour la plupart des équipes commerciales, le rappel est plus important — manquer un vrai acheteur coûte plus cher que contacter quelqu’un qui ne convertit pas.

Importance des features

Après l’entraînement, ML.GLOBAL_EXPLAIN montre quelles features pilotent les prédictions du modèle :

SELECT *
FROM ML.GLOBAL_EXPLAIN(MODEL `project.ml.lead_scoring_model`)
ORDER BY attribution DESC

Cela retourne une liste classée des scores d’importance des features. Utilisez-la pour vérifier la cohérence du modèle (“si les visites de la page tarifaire se classent sous les visites de la page d’accueil, quelque chose ne va pas”) et pour expliquer le modèle aux commerciaux en termes compréhensibles : “le modèle pondère principalement les visites de la page tarifaire et la taille de l’entreprise” est plus crédible que “l’AUC est 0,84.”

L’importance des features indique également où investir dans la collecte de meilleures données. Si une feature que vous pensiez prédictive se classe bas, soit elle n’est réellement pas prédictive (bon à savoir), soit la qualité des données est trop bruitée pour être utile (également bon à savoir).

Quand passer aux arbres boostés

La régression logistique est votre point de départ car elle est interprétable. Quand vous voulez une meilleure précision et que l’interprétabilité est moins critique, remplacez par un arbre à gradient boosté :

OPTIONS(
  model_type = 'BOOSTED_TREE_CLASSIFIER',
  ...
)

L’implémentation d’arbres boostés de BigQuery ML est XGBoost sous le capot. Sur des données tabulaires avec des types de features mixtes (continus, catégoriels, épars), XGBoost surpasse systématiquement la régression logistique en pratique. La contrepartie est que ML.GLOBAL_EXPLAIN vous donne l’importance des features mais ne peut pas vous dire la directionnalité — vous ne pouvez pas dire “une taille d’entreprise plus grande augmente le score” comme vous le pouvez avec les coefficients de régression logistique.

La régression logistique est le point de départ approprié pour comprendre les features et valider le pipeline. Les arbres boostés sont appropriés quand une précision prédictive plus élevée est nécessaire et que l’interprétabilité est moins prioritaire.

Réintégrer les prédictions dans dbt

Exécutez les prédictions sur votre population de leads actuelle en appelant ML.PREDICT dans un modèle dbt :

-- models/marts/mrt__sales__ml_lead_scores.sql
SELECT
  lead_id,
  predicted_lead__is_converted_probs[OFFSET(1)].prob AS lead__conversion_probability,
  CASE
    WHEN predicted_lead__is_converted_probs[OFFSET(1)].prob > 0.7 THEN 'hot'
    WHEN predicted_lead__is_converted_probs[OFFSET(1)].prob > 0.3 THEN 'warm'
    ELSE 'cold'
  END AS lead__score_tier
FROM ML.PREDICT(
  MODEL `project.ml.lead_scoring_model`,
  (SELECT * FROM {{ ref('int__lead__scoring_features') }})
)

Cela s’intègre naturellement au reste de votre DAG dbt. Le modèle ML vit dans BigQuery. L’appel de prédiction se trouve dans un modèle mart comme n’importe quel autre modèle mart. Les modèles en aval et les outils de reverse ETL le consomment de la même façon qu’ils consommeraient n’importe quelle sortie de mart.

Pour envoyer ces scores vers Salesforce ou HubSpot, voir Patterns de reverse ETL pour l’activation CRM.