Welche HubSpot-Tabellen laden — und welche ausschließen

Ein HubSpot-Portal ist eine konfigurierte Revenue-, Marketing- und Service-Anwendung und kein universelles Analytics-Modell. Objekte und Properties werden erst dann zu freigegebenen Quellen, wenn sie eine benannte Entscheidung auf einer definierten Zählebene unterstützen.

Das Ziel ist keine generische Tabellenliste, die jedes HubSpot-Portal laden sollte. Das Ziel ist ein prüfbarer Quellumfang für eine Entscheidung oder eine kompatible Gruppe von Entscheidungen. Er dokumentiert, warum jedes Objekt, jede Tabelle, Beziehung oder jedes Feld eingeschlossen, konditional, zurückgestellt, ausgeschlossen oder getrennt wird.

Herausforderung

Der Connector listet Contacts, Companies und Deals. Alles wird geladen „für Pipeline-Reporting“. Wochen später fehlen Stage-Semantik und Zählebene der verantwortlichen Person — der Mart ist breit, die Vertriebsentscheidung unbeantwortet.

Ein kataloggetriebener Ansatz startet mit dem Katalog aus CRM-Objekten, Properties und Associations, einem Connector-Inventar oder einer Exportvorschau. Weil eine Struktur existiert und abgefragt werden kann, wird sie „für später“ ausgewählt. Das Ergebnis ist eine breite Landing Zone, deren Business-Bedeutung, Zählebene und Zugriffsgrenze erst geklärt werden, wenn Downstream-Teams bereits Daten verbinden.

Ein typisches Inventar kann enthalten:

• Contacts, Companies, Deals und Tickets
• Products, Line Items und aktivierte Commerce-Objekte
• verantwortliche Person, Teams, Pipelines, Stages und Referenz-Properties
• Aktivitäten wie Calls, Meetings und Communications
• Custom Objects, Custom Properties und Association Labels
• Property History, archivierte Datensätze, Merges und Löschsignale
• Notes, Messages, Files, Attachments und technische Datensätze

Diese Kategorien führen nicht automatisch zu einschließen oder Ausschluss. Ihre Bedeutung hängt von der konfigurierten Anwendung, aktivierten Features, Custom Extensions und dem gewählten Geschäftsprozess ab.

Typische Fehlermuster sind vorhersehbar:

• technisch verfügbare Strukturen werden mit freigegebenen analytischen Quellen verwechselt;
• aktueller Zustand, History, Events und Snapshots werden ohne Zeitvertrag vermischt;
• Parent-, Child-, Header-, Line- oder Association-Strukturen werden ohne Ziel-Zählebene verbunden;
• Display Labels gelten als stabile Business-Definitionen, obwohl die konfigurierte Semantik abweicht;
• personenbezogene Daten, Freitext und Attachments erweitern Access- und Retention-Grenze;
• Custom Process Structures werden ignoriert, weil Standardnamen vertrauter wirken;
• jedes Downstream-Produkt erfindet eigene Interpretationen, Duplication Rules und Exception Handling.

Unterschiedliche Entscheidungen benötigen unterschiedliche Scopes

• Pipeline-Steuerung nach Deal Stage und verantwortliche Person benötigt Deal-Zählebene, governte Stage-Daten sowie die relevanten verantwortliche Person- und Company-Associations.
• Revenue nach Produkt benötigt Line-Item-Zählebene und eine kontrollierte Beziehung vom Deal zum Line Item sowie bei Bedarf zu einer wiederverwendbaren Product Reference.
• Lifecycle Conversion nach Quelle benötigt ein abgestimmtes Lifecycle-Modell, Event- oder Property-History-Semantik und explizite Contact-Company-Association-Regeln.
• Ticket Resolution nach Team benötigt Ticket-Zählebene, Status- und Datumssemantik, Category-Referenzen und nur die Aktivitäten, die die Kennzahl tatsächlich verwendet.

Der richtige Quellumfang ist deshalb kontextabhängig. Er wird aus der Entscheidung abgeleitet und gegen die reale Konfiguration validiert.

Ansatz

Definiere den Scope in der folgenden Reihenfolge. Connector- und Extraction Design folgen später.

1. Entscheidung, Population und Ziel-Zählebene formulieren

Beschreibe die Anforderung als Entscheidung mit Nutzer, Handlung, Population, Zeithorizont und Zählebene. „Ein Dashboard aus HubSpot-Portal bauen“ ist zu schwach, weil damit nicht feststeht, welche Datensätze, Beziehungen oder historischen Zustände erforderlich sind.

Beschreibe für jeden vorgesehenen Fakt eine Zeile in Business-Begriffen. Definiere das Event, das den Fakt erzeugt, die interpretierenden Dimensionen und das steuernde Reporting Date. Eine Quellzeile ist nicht automatisch ein analytischer Fakt.

2. Strukturen nach fachlicher Rolle klassifizieren

Kern für den gewählten Anwendungsfall

• Companies oder Contacts, wenn sie den governten Kundenkontext definieren
• Deals für Pipeline- oder Revenue-Entscheidungen
• Tickets für ein definiertes Service-Produkt
• verantwortliche Personen oder Teams, wenn Verantwortlichkeit benötigt wird
• Pipeline-, Stage-, Datums- und Source-Properties der Kennzahl
• Line Items, wenn Revenue explizit auf Positions-Zählebene liegt

bedingt

• Products und Product References
• Campaign- und Attributionsobjekte
• Calls, Meetings und Communication Activities
• Quotes, Orders, Invoices, Subscriptions oder Payments, wenn aktiviert und erforderlich
• ausgewählte Property History
• Custom Objects und Custom Association Labels

Ausschluss ohne konkrete Anforderung

• ungenutzte Feature-Objekte
• All-Property-Exporte
• doppelte Convenience-Repräsentationen
• unbeschränkte Notes, Messages, Files und Attachments
• technische Datensätze ohne benanntes Analytics- oder Kontrollregel-Produkt

Die Gruppen sind Muster und keine universellen Listen. Reale Application Configuration, Custom Objects, aktivierte Module, Security und Business Meaning haben Vorrang vor generischen Beispielen.

3. Beziehungen vor den Joins modellieren

Nutze ein beziehungszentriertes Modell statt einer flachen Tabellenliste:

Company ↔ Contact
   \       /
      Deal → Line Item → Product Reference
       |
Ticket oder Activity nur bei Bedarf

Für jede Beziehung werden dokumentiert:

• analytischer Zweck der Association
• Richtung, Kardinalität und Optionalität
• Association Label und konfigurierte Business-Bedeutung
• Auswirkung auf die Ziel-Zählebene
• Verantwortung für doppelte oder mehrdeutige Beziehungen
• aktuell- gegenüber Historical-Bedeutung
• personenbezogene Daten-Klassifikation und Permitted Use

Ein Join wird nicht allein deshalb freigegeben, weil beide Keys verfügbar sind. Ein technisch gültiger Join kann Fakten duplizieren, aktuellen Kontext auf historische Events anwenden oder eine ungelöste Many-to-many-Beziehung erzeugen.

Teste explizit diese Failure Cases:

• eine Many-to-many-Beziehung zwischen Contact und Company wird auf eine willkürliche Company reduziert
• ein Deal wird einmal je zugeordnetem Contact gezählt
• Product Definitions und deal-spezifische Line Items werden als derselbe Zählebene behandelt
• Activities werden durch wiederholte Associations aufgebläht
• Custom Objects des tatsächlichen Prozesses werden ausgelassen

4. aktuellen Zustand, Ereignisse, Historie und Snapshots trennen

Der Quellumfang unterscheidet:

• aktueller Objektzustand
• Property History für freigegebene Properties
• explizite Lifecycle- oder Business-Events
• plattformseitige Created- und Update-Timestamps
• bewusst erzeugte Snapshots für vollständige Point-in-time-Zustände

Ein generischer Created- oder Updated-Timestamp beweist keine vollständige Business History. Audit Data ist nicht automatisch ein Process Event Log. Für Point-in-time-Rekonstruktion muss feststehen, welcher Zustand erhalten bleibt, wie Corrections erscheinen und ob Plattform-Snapshots benötigt werden.

5. Feld-, Datenschutz- und Zugriffskontrollen anwenden

Die Aufnahme eines Objekts oder einer Tabelle autorisiert nicht alle Felder. Erstelle eine Allowlist und entscheide separat über:

• E-Mail-Adressen, Telefonnummern und Contact-Identifier
• Notes, Messages und Communication Bodies
• freie Beschreibungen und Betreffzeilen
• Files und Attachments
• Verhalten archivierter, zusammengeführter und gelöschter Datensätze

Bevorzuge kontrollierte Kategorie, Count, Flag oder abgeleitetes Age, wenn die Entscheidung keinen Raw Content benötigt. Permitted Use, Role- und Domain Access, Masking, Retention, Deletion Propagation und Incident Verantwortung werden vor der Extraktion definiert.

6. Einen expliziten Entscheidungsstatus vergeben

Nutze mehr als eine binäre Load-or-ignore-Entscheidung:

• einschließen — Bedeutung, Autorität, Zählebene, Zugriff und Qualitätskontrollen sind freigegeben.
• bedingt — die Quelle wird nur für eine benannte Variante oder Kennzahl mit klarer Aktivierungsbedingung benötigt.
• zurückstellen — der Bedarf ist valide, aber Verantwortung-, History-, Security-, Quality- oder Extraction-Nachweis ist unvollständig.
• Ausschluss — kein freigegebener analytischer Zweck existiert oder die Struktur ist redundant, instabil oder unverhältnismäßig riskant.
• separates Produkt — ein operativer, sicherheitsbezogener, auditbezogener oder eingeschränkter Anwendungsfall existiert, darf aber nicht in das allgemeine Business-Produkt gemischt werden.

Jede nicht eingeschlossene Entscheidung benötigt Begründung und Review-Auslöser.

7. Gegen das konfigurierte System validieren

Namen und Standardbeispiele sind keine Verträge. Prüfe den tatsächlichen Prozess mit fachlich Verantwortlichen, Anwendungsadministratoren, Privacy, Security und Integrationsteam. Bestätige Custom Objects, aktivierte Module, Statusmodelle, Labels, Keys, Access und Lifecycle-Verhalten im realen Tenant oder in der Instanz.

Checkliste

Entscheidung und Zählebene

• Die Business-Frage benennt Nutzer, Handlung, Grundgesamtheit und Zeithorizont.
• Jeder Fakt besitzt einen festgelegte Zählebene.
• Event und Reporting Date sind explizit.
• aktueller Zustand, Event History und Snapshots sind getrennt.
• Kennzahlen und Status-Semantik besitzen accountable verantwortliche Person.

Quellstrukturen und Beziehungen

• Jede eingeschlossene Struktur unterstützt eine benannte Anforderung.
• Custom und application-spezifische Strukturen wurden geprüft.
• Keys, Kardinalität und Optionalität sind dokumentiert.
• Duplicate-, Orphan- und Many-to-many-Verhalten ist definiert.
• Reference Labels und Codes besitzen ein freigegebenes Mapping.

Risiko und Lifecycle

• Eine Field Freigabeliste existiert.
• personenbezogene Daten, sensible Attribute und Freitext sind klassifiziert.
• Attachments und Binary Content besitzen eine separate Entscheidung.
• Deletion-, Merge-, Archive- oder Deactivation-Verhalten ist definiert.
• Retention und Permitted Use sind freigegeben.

Betrieb

• Aktualität und erwartetes Volumen sind verstanden.
• Completeness, Uniqueness und Beziehung Quality sind testbar.
• Business und technischer Betreiber sind benannt.
• Abgleichkontrollen sind definiert.
• Jede zurückstellen-, Ausschluss- oder separate Produkt-Entscheidung besitzt einen Review-Auslöser.

Artefakt

Erstelle ein governtes Source-Scope-Register je Data Product oder kompatiblem Entscheidungsportfolio. Es ist der freigegebene Vertrag zwischen Business Requirement und späterem Extraction Design.

Pflichtfelder

Erforderliche Outputs

• freigegebener Objektumfang
• Property Freigabeliste
• freigegebene Association Map
• explizite Ausschluss-Liste
• History- und Deletion-Vereinbarung
• offene Fragen und Übergabe an Ingestion

Das Artefakt wird versioniert. Neue Module, Custom Objects, Prozessänderungen, Statusmodelle, Änderungen an Zugriffsrichtlinien oder wesentliche Datenqualitätsvorfälle lösen einen Review aus. Abfragbarkeit ist keine Freigabe.

Tools

Nutze den Quellumfang Builder, um einschließen-, bedingt-, zurückstellen-, Ausschluss- und separate Produkt-Entscheidungen mit Zählebene, Autorität, Risiko und Review-Auslösern zu dokumentieren.

Nutze Suppliers für produktspezifischen Kontext und den PII and DSDR Readiness Checker, wenn der Scope personenbezogene Daten, Freitext, Löschungen oder Betroffenenrechte umfasst.

Die Tools strukturieren Evidenz. Sie ersetzen keine Freigabe durch fachlich verantwortliche Person, Steward, Anwendungsverantwortliche, Privacy oder Security.

Ressourcen

• HubSpot-Dokumentation zu CRM Associations
• HubSpot-Dokumentation zum CRM Object Model
• HubSpot-Leitfaden zu Custom Objects

Die konfigurierte HubSpot-Portal bleibt die entscheidende technische Evidenz. Produktdokumentation beschreibt Capabilities; sie bestimmt nicht Business Authority, Zählebene oder Permitted Use.