Les données CRM sont très demandées et peu fiables dans la plupart des entrepôts. Ces notes couvrent les patterns d’architecture qui transforment les données Salesforce et HubSpot en modèles de warehouse fiables avec dbt et BigQuery.
Les défis
Défis d’extraction des données CRM — Pourquoi les données CRM sont plus difficiles que la plupart des sources : mutabilité, extraction par API, suppressions logicielles, angles morts des champs de formule et limites de débit. Commencez ici si vous êtes nouveau dans l’entrepôt de données CRM.
Comprendre les systèmes source
Salesforce vs HubSpot : modèles de données — Comment les deux CRM structurent les données différemment. Salesforce utilise des modèles relationnels pilotés par les métadonnées avec des relations de recherche et maître-détail. HubSpot utilise des associations many-to-many avec des tables de liaison et des étiquettes optionnelles. Cette différence structurelle façonne chaque décision de modélisation.
Patterns de modélisation
Patterns de modélisation CRM dans dbt — Comment appliquer le pattern base-intermédiaire-mart aux données CRM. Des exemples de code concrets pour Salesforce et HubSpot, incluant les conventions de modèles de base, l’enrichissement intermédiaire, la conception des marts et les stratégies incrémentales pour BigQuery.
SCD Type 2 avec les snapshots dbt — Suivi des changements historiques dans les enregistrements CRM. Stratégies timestamp vs check, Fivetran History Mode comme alternative, requête de l’état à un instant donné, et analyse de la durée des étapes.
Conception de schéma
Star Schema vs One Big Table — Quand utiliser des modèles séparés par entité vs des tables larges dénormalisées. Benchmarks de performance BigQuery, la réponse pratique consistant à construire les deux à différentes couches, et comment les packages Fivetran implémentent ce pattern.
Patterns spécifiques à HubSpot
Hub pipeline BigQuery HubSpot — L’index complet des notes de jardin spécifiques à HubSpot : associations, étapes de cycle de vie, étapes de deal et historique des propriétés.
Tables de liaison des associations HubSpot — Comment le modèle d’association many-to-many de HubSpot nécessite des tables de liaison à chaque couche, le problème de fan-out et la résolution de la société principale.
Étapes de cycle de vie HubSpot dans le warehouse — Le modèle “Became a Stage Date”, les transitions unidirectionnelles, les patterns de mart en entonnoir et les artefacts de contacts fusionnés.
Modélisation des étapes de deal HubSpot — La table DEAL_STAGE, les colonnes is_closed vs label, le temps dans chaque étape et l’analyse des taux de conversion.
Mécaniques de l’historique des propriétés HubSpot — Limites de rétention, inflation des propriétés CALCULATED et déduplication au niveau de la couche de base.
Packages et outillage
Packages dbt Fivetran pour le CRM — Ce que dbt_salesforce et dbt_hubspot fournissent directement : couverture des modèles, colonnes pass-through pour les champs personnalisés, support du mode History, configuration multi-org et compromis des conventions de nommage.
Notes d’architecture connexes
Ces notes existantes fournissent les concepts fondamentaux sur lesquels s’appuie la modélisation CRM :
- Architecture trois couches dbt — Le pattern de couches base-intermédiaire-mart
- Patterns de la couche base dbt — Ce qui appartient aux modèles de base
- Patterns de la couche intermédiaire dbt — Enrichissement sans réduire la granularité
- Patterns de la couche mart dbt — Agrégation spécifique au consommateur
- Modèles incrémentaux dans dbt — Quand et comment utiliser la matérialisation incrémentale
- Framework de décision pour la stratégie incrémentale — Choisir entre merge, insert_overwrite et autres
- Patterns de pruning des partitions BigQuery — Partitionnement et clustering pour l’optimisation des coûts
- Anatomie des packages dbt — Comment les packages dbt sont structurés
- Stratégie ELT hybride — Quand acheter l’extraction gérée vs construire une extraction personnalisée