ooligo
STACK

Warehouse-native GTM-Stack — Aktivierung ohne zweite Kopie der Wahrheit

Ein GTM-Team, das bereits Snowflake oder BigQuery betreibt und Segmentdefinitionen in dbt statt im Audience-Builder eines Anbieters halten will — mit Reverse-ETL-Aktivierung statt einer anbietereigenen CDP.

Difficulty
Profi
Tools
3
RevOps

The stack

Das Warehouse enthält die Definition eines qualifizierten Accounts bereits. Dieser Stack hindert Sie daran, eine zweite Kopie davon in einem Marketing-Tool zu pflegen. Snowflake oder BigQuery besitzt die modellierte Kundentabelle, Hightouch synchronisiert sie nach außen, Clay liefert die Felder, die das Warehouse nicht selbst erzeugen kann, und in HubSpot handelt ein Mensch auf Basis des Ergebnisses.

Das Argument für diesen Aufbau ist kein architektonischer Geschmack. Es ist, dass jedes GTM-Tool mit eigenem Segment-Builder irgendwann mit dbt darüber streitet, wer als Kunde zählt — und diese beiden Definitionen jedes Quartal abzugleichen kostet mehr, als die Aktivierungsschicht pro Jahr kostet. Rechnen Sie mit 6-10 Wochen bis zum Betrieb, überwiegend für das Datenmodell und nicht für eines der drei Tools.

Wie die Teile zusammenpassen

  • Das Warehouse ist die Source of Truth. Snowflake, BigQuery, Databricks oder Redshift — der Stack ist agnostisch, mit einer Einschränkung unter Varianten. Ihre dbt-Modelle erzeugen eine Tabelle auf Account-Ebene mit genau den Feldern, auf die GTM tatsächlich reagiert: ICP-Tier, Fit Score, Produktnutzungsstatus, Flag für offene Pipeline. Nichts weiter unten definiert ein Segment. Die Tools weiter unten lesen eines. Diese Schicht macht den Rest des Stacks vor einem Board vertretbar — und genau sie verkauft Ihnen niemand.

  • Hightouch ist der Aktivierungs-Bus. Sie schreiben SQL gegen das Warehouse, definieren einen Sync, und die Zeilen landen als Felder in HubSpot, als Audiences in Werbeplattformen oder als Profile in Lifecycle-Tools — ohne zweite Kopie der Kundendaten im Speicher eines Anbieters. Der kostenlose Tier Basic Reverse ETL ist auf 2 aktive Syncs begrenzt, bringt aber unbegrenzte Ziele und unbegrenzte User-Seats mit; der kostenpflichtige Composable CDP misst nach Monthly Tracked Rows statt nach Seats, weshalb ein 40-köpfiges Growth-Team bei gleichem Volumen so viel kostet wie ein vierköpfiges. Ein Bereitstellungsdetail, das Sie im Trial klären sollten: Die Dokumentation von Hightouch hält fest, dass der eigene MCP-Server nicht in allen Workspaces aktiviert ist und angefragt werden muss, auch wenn er nichts extra kostet.

  • Clay füllt die Lücken. Das Warehouse hält, was Sie beobachtet haben. Clay liefert, was Sie nie gesehen haben: Firmografie, Headcount-Veränderungen, Technografie, Jobwechsel. Die Snowflake-Integration bringt die Aktionen Insert Row, Lookup Row und Upsert Row mit, sodass ein Anreicherungslauf in eine Staging-Tabelle zurückschreibt, statt in einer Clay-Tabelle zu enden, die sonst niemand liest. Stand August 2026 ist die BigQuery-Integrationsseite von Clay weiterhin als Coming Soon markiert — diese Asymmetrie entscheidet über Ihre Verkabelung, nicht über Ihre Architektur.

  • HubSpot ist die Aktionsschicht, nicht die Wahrheitsschicht. Owner-Zuweisung, Sequenz-Enrollment, Deal-Stages, Aufgaben. Die operative Disziplin, die diesen Stack trägt: Jede HubSpot-Eigenschaft, die ein Hightouch-Sync schreibt, ist für manuelle Bearbeitung gesperrt. Wenn ein Rep icp_tier in der CRM-Oberfläche überschreiben kann, haben Sie wieder zwei Sources of Truth und die ganze Prämisse ist hinfällig. Sperren Sie diese Eigenschaften am ersten Tag.

Benannte Übergaben

  1. Modell an CRM. dbt materialisiert gtm_accounts → der Hightouch-Sync liest sie → die HubSpot-Unternehmenseigenschaften (icp_tier, fit_score, next_best_action) werden aktualisiert. Nur geänderte Zeilen sollten gegen den Tracked-Rows-Zähler abrechnen, und das ist eine Eigenschaft Ihres Modells, nicht von Hightouch.
  2. Lücke an Anreicherung. Eine Warehouse-View mit Accounts ohne Firmografie → Clay Lookup Row oder Tabellenimport → Anreicherungslauf → Clay Upsert Row schreibt nach clay_enrichment_staging → dbt merged in das Account-Modell → der nächste Hightouch-Sync trägt die neuen Felder nach außen.
  3. Eigenschaftsänderung an Vertriebsaktion. icp_tier springt auf Tier 1 → ein HubSpot-Workflow weist einen Owner zu und meldet den Kontakt in der passenden Sequenz an. Diese Übergabe läuft vollständig innerhalb von HubSpot; die Verantwortung von Hightouch endete beim Schreibvorgang.
  4. Ergebnis zurück ins Warehouse. Deal-Stage, Sequenz-Ergebnis und Closed-Won-Status kehren ins Warehouse zurück, damit der nächste Modelllauf gegen Ergebnisse und nicht gegen Vermutungen scort. An diesem Bein schlägt die Tier-Entscheidung unten am härtesten durch.

Warum diese Kombination

Die naheliegende Alternative ist, Hightouch wegzulassen und HubSpots eigenen Warehouse-Sync in beide Richtungen zu nutzen. Rechnen Sie vorher nach. Die Dokumentation von HubSpot setzt den Snowflake-Sync hinter Data Hub oder Smart CRM auf Enterprise-Niveau plus HubSpot Credits, hält ausdrücklich fest, dass Syncs nach Zeitplan laufen und nicht in Echtzeit aktualisieren, und begrenzt eine Quelltabelle oder View auf 10 GB, 200 Spalten und 30 Millionen Datensätze pro Lauf. Data Hub Enterprise ist mit $2.000/Monat gelistet. Die Hausvariante kostet also $24.000 pro Jahr, läuft nur nach Zeitplan und bedient genau ein Ziel — das CRM, das Sie ohnehin haben.

Der mediane Jahresvertrag von Hightouch liegt laut Vendr bei $15.000 über 170 ausgewertete Käufe, mit einer Spanne von $9.600 bis $75.000 und durchschnittlich 26% Rabatt auf die Liste. Für weniger als das HubSpot-Tier-Upgrade bekommen Sie das CRM-Bein plus jedes Werbe-, Lifecycle- und Support-Ziel aus einem Katalog von über 300 Integrationen. Der Vergleich fällt nur dann zugunsten von HubSpot aus, wenn das CRM wirklich für immer Ihr einziges Ziel ist — und dann brauchen Sie diesen Stack ohnehin nicht.

Der zweite Grund: Jede Schicht hat genau eine Aufgabe. Das Warehouse definiert, Hightouch bewegt, Clay füllt, HubSpot handelt. Wenn eine Zahl falsch ist, gibt es genau eine Stelle zum Nachsehen. Stacks, die diese Grenzen verwischen — eine CDP, die auch modelliert, ein CRM, das auch anreichert — erzeugen den Fehlerfall, in dem drei Tools leicht abweichende Umsatzzahlen halten und niemand sagen kann, welche stimmt.

Kostenrealität

Jahresbänder für ein Mid-Market-B2B-Team mit 10 Seats und moderatem Volumen:

  • Warehouse (nur der Zuwachs): BigQuery veröffentlicht $6,25 pro gescanntem TiB On-Demand in der US-Multiregion und $0,06 pro Slot-Stunde in der Enterprise Edition. Snowflake zeigt auf seiner Preisseite keinen statischen Listenpreis — die Sätze variieren nach Plattform und Region — und Drittanbieter-Tracker verorten Standard bei rund $2,00-$2,50 pro Credit und Enterprise bei rund $3,00. Behandeln Sie GTM-Aktivierung als Zuwachs auf einer bestehenden Rechnung, realistisch $2K-$12K pro Jahr, weit stärker getrieben von der Sync-Frequenz als von der Zeilenzahl.
  • Hightouch: $15.000/Jahr im Median laut Vendr. Dieselbe Quelle nennt Bänder von rund $1.000-$2.500/Monat bis 100.000 Monthly Tracked Rows und $2.500-$8.000/Monat von 100.000 bis 1 Million. Jenseits des kostenlosen Tiers ist nichts veröffentlicht, jede Zahl hier stammt also von Käufern und nicht aus einem Anbieterangebot.
  • Clay: Launch kostet $185/Monat ($167 jährlich abgerechnet), Growth $495/Monat ($446 jährlich abgerechnet), nach der Preisumstellung vom 11. März 2026, die die Abrechnung in Data Credits und Actions aufgeteilt hat. Self-Serve-Teams landen bei $2.000-$5.400 pro Jahr; Enterprise-Verträge werden um einen Median von $30.000 pro Jahr berichtet.
  • HubSpot: Sales Hub Professional kostet $90/Seat/Monat bei jährlicher Abrechnung ($100 bei monatlicher), also $10.800 pro Jahr für 10 Seats, plus eine einmalige Onboarding-Gebühr von $1.500. Enterprise liegt bei $150/Seat/Monat.

Gesamt: etwa $30K-$60K pro Jahr für 10 Seats, mit Hightouch als größtem Posten. Rechnen Sie $24.000 dazu, falls Sie zusätzlich Data Hub Enterprise kaufen — was Sie, wenn Sie Hightouch kaufen, meist nicht tun sollten.

Die Kosten, die auf keiner Rechnung stehen: Aufbau und laufende Pflege der dbt-Modelle, der eigentliche Eintrittspreis; Warehouse-Compute, das auf aus Gewohnheit statt aus fachlichem Bedarf gesetzte Sync-Zeitpläne zurückgeht; und Clay-Top-ups, die über Ihrem Plansatz abrechnen, sobald einer der beiden Zähler leer läuft.

Match-Regeln

Nutzen Sie diesen Stack, wenn:

  • Ein Warehouse bereits produktiv läuft, mit einer modellierten Account- oder Kundentabelle. Aktivierung erzeugt keine Daten; sie vor dem Modell zu kaufen heißt, für ein leeres Rohr zu zahlen.
  • Jemand das dbt-Projekt verantwortet und es auch in einem Jahr noch verantwortet. Dieser Stack hat einen benannten Betreuer oder er verfällt.
  • Sie zwei oder mehr Aktivierungsziele haben oder innerhalb von 12 Monaten erwarten. Ein einziges Ziel rechtfertigt keinen Aktivierungs-Bus.
  • Sie auf eine Segmentdefinition zeigen können, die heute sowohl in dbt als auch in einer Anbieteroberfläche existiert, und sagen können, wann beide zuletzt auseinanderliefen. Genau diesen Schmerz nimmt dieser Stack weg.

Nutzen Sie diesen Stack nicht, wenn:

  • Sie kein Warehouse haben. Kaufen Sie eine paketierte CDP, die Events selbst erhebt; Sie brauchen Ingestion und Identität vor Aktivierung.
  • HubSpot Ihr einziges Ziel ist und bleibt. HubSpots nativer Snowflake-Sync ist langsamer und tier-gebunden, aber es sind ein Anbieter und eine Rechnung.
  • Niemand im Team SQL schreibt. Das Warehouse-native Muster tauscht Anbieteroberfläche gegen SQL, und dieser Tausch lohnt nur, wenn Sie ihn leisten können.
  • Sie vor dem Product-Market-Fit stehen und noch lernen, welche Signale Conversion vorhersagen. Dieser Stack operationalisiert eine Definition guter Accounts; er findet sie nicht.

Übliche Varianten

  • BigQuery statt Snowflake. Alles bleibt, außer dem Clay-Bein — der native BigQuery-Konnektor ist noch nicht verfügbar, also leiten Sie die Anreicherung über einen Hightouch-Sync in Clays HTTP API (Plan Growth und aufwärts) und lassen Clay auf demselben Weg zurückschreiben. Das fügt einen Hop hinzu und ändert nichts am Datenmodell. Wechseln Sie zurück zu den nativen Aktionen, sobald der Konnektor erscheint.
  • Salesforce statt HubSpot. Der richtige Tausch, wenn der Einkauf des Käufers oder eine bestehende Salesforce-Org ihn erzwingt. Der Zielkatalog von Hightouch deckt beides ab, die Aktivierungsschicht bleibt also unberührt; was sich ändert, ist, dass Salesforce mit dem eigenen Data-Cloud-Angebot um dasselbe Budget konkurriert — und günstiger wird es dadurch nicht.
  • Clay streichen. Wenn firmografische Anreicherung bereits im Warehouse ankommt — ein ZoomInfo- oder Clearbit-Data-Share oder ein Anbieter-Feed, den Ihr Datenteam ohnehin einliest — ist Clay hier redundant und der am ehesten verzichtbare Posten. Behalten Sie es nur, wenn die AI-Recherche pro Account etwas leistet, das ein Massen-Feed nicht kann.
  • Fivetran Census statt Hightouch. Fivetran hat Census im Mai 2025 übernommen und als Fivetran Activations eingegliedert. Wählen Sie es, wenn Sie Fivetran ohnehin für Ingestion kaufen und eine Rechnung wollen; wählen Sie Hightouch, wenn Aktivierung die schwerere Hälfte Ihres Problems ist — dort sind Zielkatalog und Identitätsschichten tiefer.

Was dieser Stack NICHT ersetzt

  • Die dbt-Modelle. Hightouch verteilt die Definition, die Sie ihm geben, an 300 Ziele, treu und schnell. Eine falsche Definition ist überall falsch.
  • Die Ingestion. Fivetran, Airbyte oder native Konnektoren bringen die Daten ins Warehouse; dieser Stack beginnt danach und trägt nichts dazu bei.
  • Identitätsauflösung, die Sie nicht gemacht haben. Erscheint eine Person dreimal über Produkt, Billing und CRM, synchronisiert die Aktivierung alle drei.
  • Eine Demand-Engine. Paid, Content und Outbound erzeugen die Accounts, die dieser Stack scort und routet; er verarbeitet Volumen, er schafft keines.
  • Conversation Intelligence und Vertriebsmethodik. Sobald die Sequenz auslöst und ein Termin steht, hat dieser Stack keine Meinung mehr — siehe Gong für das, was danach kommt.