HubSpot utilise des associations many-to-many avec des labels optionnels plutôt que les relations lookup et master-detail de Salesforce. L’historique des champs est distribué dans des tables d’historique de propriétés séparées par objet avec des limites de rétention plutôt qu’un seul objet d’historique. Ces différences structurelles nécessitent des patterns de modélisation distincts à chaque couche.
Ce hub couvre le pipeline HubSpot-vers-BigQuery complet. L’article de référence est HubSpot vers BigQuery : un pipeline complet avec dbt. Ces notes isolent des concepts individuels de cet article.
Ingestion et structure
Salesforce vs HubSpot : Modèles de données — Différences structurelles entre le modèle basé sur les associations de HubSpot et le modèle de clé étrangère de Salesforce, et comment ces différences affectent la modélisation en aval.
Choisir entre Fivetran, Airbyte et dlt — Cadre de décision pour les outils d’ingestion. Considérations spécifiques à HubSpot : Fivetran couvre 50+ tables, Airbyte a une limite stricte de 10K résultats sur l’API CRM Search, dlt fournit les objets principaux avec un package dbt compagnon, et le connecteur BigQuery natif de HubSpot couvre moins d’objets mais ne coûte rien.
Défis principaux du modèle de données
Les associations HubSpot comme tables de jonction — HubSpot n’a pas de clés étrangères sur les objets principaux. Chaque relation — contact vers société, deal vers contact, deal vers société — passe par une table de jonction. Couvre la modélisation correcte des associations, la gestion du problème de fan-out, et la résolution de la question de la société principale sans perdre les contacts multi-sociétés.
Étapes du cycle de vie HubSpot dans l’entrepôt — HubSpot estampille une propriété « Became a Stage Date » sur les contacts pour chaque étape du cycle de vie atteinte. Couvre le fonctionnement des transitions de cycle de vie unidirectionnelles, comment extraire les timestamps d’étape dans les modèles de base, comment construire le mart de l’entonnoir du cycle de vie, et comment détecter les artefacts de fusion de contacts qui produisent des séquences de dates impossibles.
Modélisation des étapes de deal HubSpot — Les transitions d’étapes de deal se trouvent dans DEAL_STAGE, pas dans DEAL_PROPERTY_HISTORY. Couvre le fonctionnement conjoint des colonnes is_closed et label, les patterns de temps-par-étape et les modèles de taux de conversion du pipeline.
Mécanique de l’historique des propriétés HubSpot — Les tables d’historique de propriétés par objet ont des limites de rétention (45 valeurs pour les contacts, 20 pour les autres). Le type de propriété CALCULATED gonfle les coûts de synchronisation en mettant toujours à jour les timestamps du curseur même quand les valeurs n’ont pas changé. Couvre la détection, la déduplication à la couche de base, et l’activation de l’historique dans le package dbt_hubspot.
Le package dbt_hubspot
Packages dbt Fivetran pour CRM — dbt_hubspot (v1.6.1) génère 147 modèles quand il est entièrement activé. Couvre la configuration des seuls modules dont vous avez besoin, les colonnes pass-through pour les propriétés personnalisées, et construire au-dessus du package vs le remplacer avec des modèles personnalisés. Le package utilise insert_overwrite comme stratégie incrémentale BigQuery.
Notes CRM associées
- Hub d’architecture des données CRM — Le paysage plus large de la modélisation CRM
- Défis de l’extraction des données CRM — Mutabilité, suppressions logiques, limites de taux et extraction basée sur API
- Patterns de modélisation CRM dans dbt — Le pattern à trois couches appliqué aux données CRM
- SCD Type 2 avec les snapshots dbt — Suivi de l’état historique des enregistrements CRM
- Star Schema vs One Big Table — Décisions de conception de mart pour l’analytique CRM