Der Kerngedanke hinter Hightouch lässt sich auf einen Satz verdichten: Das Data Warehouse ist die einzige Wahrheit, und von dort werden die Daten aktiviert. Während eine klassische CDP die Kundendaten in einer eigenen, geschlossenen Datenbank sammelt und dort ein zweites Mal vorhält, verzichtet Hightouch bewusst auf diese Kopie. Die Daten bleiben im Warehouse, das das Unternehmen ohnehin betreibt – etwa in Snowflake, BigQuery, Databricks, Redshift oder einer relationalen Datenbank –, und Hightouch fungiert als Schicht, die diese Daten operativ nutzbar macht. Genau diese Umkehrung der Datenflussrichtung ist mit dem Begriff Reverse ETL gemeint: Klassisches ETL lädt Daten in das Warehouse hinein, Reverse ETL holt sie zur Aktivierung wieder heraus.
Drei Eigenschaften prägen Hightouch:
Um den Wert von Hightouch zu verstehen, hilft ein Blick auf die typische Ausgangslage. In vielen Unternehmen ist über Jahre ein leistungsfähiges Data Warehouse entstanden, in dem Bestell-, Nutzungs- und Kundendaten sauber zusammenlaufen. Diese Daten sind hervorragend für Berichte und Analysen geeignet – aber sie liegen im Warehouse fest, während die operativen Teams in Marketing, Vertrieb und Support in ihren eigenen Werkzeugen arbeiten und dort oft nur einen Bruchteil des Wissens zur Verfügung haben. Zwischen der analytischen Wahrheit im Warehouse und dem operativen Alltag klafft eine Lücke.
Hightouch schließt genau diese Lücke. Es macht die im Warehouse berechneten Kennzahlen, Segmente und Merkmale in den operativen Werkzeugen verfügbar, ohne dass dafür individuelle Schnittstellen programmiert werden müssen. Für den Mittelstand bedeutet das vor allem: Investitionen, die ohnehin in das Warehouse geflossen sind, werden endlich operativ nutzbar. Der Preis dafür ist die Voraussetzung, dass ein solches Warehouse überhaupt existiert und die relevanten Daten dort in brauchbarer Qualität vorliegen. Wer diese Grundlage nicht hat, für den ist Hightouch das falsche Werkzeug zum falschen Zeitpunkt.
Hightouch richtet sich an Organisationen, die bereits ein Data Warehouse betreiben oder aufbauen und die ihre Kundendaten aktiv für Marketing, Vertrieb und Kundenbetreuung nutzen wollen. Besonders wohl fühlt sich Hightouch dort, wo ein Data- oder Analytics-Team vorhanden ist, das mit SQL umgehen kann und die Datenmodelle im Warehouse versteht. In solchen Umgebungen entfaltet der warehouse-native Ansatz seine volle Stärke – die vorhandene Datenkompetenz wird direkt zur operativen Aktivierung verlängert.
Weniger passend ist Hightouch für Unternehmen, die noch gar kein Warehouse besitzen und primär Rohdaten von Web und App einsammeln wollen – dafür sind andere Werkzeuge gebaut. Ebenso wenig ersetzt Hightouch eine klassische CDP für Teams, die eine geschlossene, fertig konfigurierte Marketing-Plattform ohne technischen Unterbau erwarten. Hightouch ist ein mächtiger Hebel für Datenaktivierung, aber er setzt eine reife Datengrundlage voraus.
Die entscheidende Weichenstellung, die Hightouch von einer klassischen CDP unterscheidet, ist die Frage, wo die Kundendaten leben. Eine paketierte CDP legt eine eigene Datenbank an, in die alle Kundendaten kopiert werden; sie ist ein geschlossenes System mit eigenem Speicher, eigener Profillogik und eigener Verwaltung. Der Composable-Ansatz, für den Hightouch steht, dreht diese Logik um: Das Data Warehouse bleibt der zentrale Datenspeicher, und die einzelnen Funktionen einer CDP – Modellierung, Identitätsauflösung, Segmentierung, Aktivierung – werden als austauschbare Bausteine darauf aufgesetzt. Man setzt die CDP gewissermaßen aus Komponenten zusammen, statt eine fertige Blackbox zu kaufen.
Dieser Unterschied ist nicht nur technisch, sondern strategisch. Er entscheidet über Datenhoheit, über Datenverdopplung, über die Abhängigkeit von einem einzelnen Anbieter und über die Frage, wer die Kontrolle über die Kundendaten behält. Hightouch positioniert sich klar auf der composable Seite und macht den warehouse-native Charakter zu seinem zentralen Verkaufsargument. Für Unternehmen, die ohnehin in ihr Warehouse investieren, ist das ein überzeugendes Versprechen – für solche ohne Warehouse ist es dagegen eine Voraussetzung, die erst geschaffen werden müsste.
In der Landschaft der Customer Data Platforms positioniert sich Hightouch als warehouse-native Aktivierungsschicht mit klarem Fokus auf die operative Nutzung vorhandener Daten. Anders als CDPs, die als geschlossene Marketing-Suiten mit eigenem Datenspeicher auftreten, versteht sich Hightouch als offene Ergänzung zum Data Warehouse. Die eigentliche Datensammlung und -aufbereitung überlässt Hightouch weitgehend dem Warehouse und den davorgeschalteten Datenprozessen; sein Beitrag ist die Aktivierung.
Diese Positionierung hat eine wichtige Konsequenz: Hightouch ist stark in der Aktivierung, aber es ersetzt nicht das Warehouse und nicht die vorgelagerten Datenpipelines. Wer eine All-in-One-Lösung erwartet, die von der Datenerfassung bis zur Kampagne alles abdeckt, missversteht die Rolle. Hightouch ist die Brücke zwischen der analytischen Datenwelt und den operativen Werkzeugen – nicht mehr, aber auch nicht weniger. Diese Klarheit über die Rolle ist entscheidend, um Hightouch richtig einzuordnen.
Im Zentrum von Hightouch steht die Verbindung zum Data Warehouse. Eine Source ist die Anbindung an die eigene Datenquelle – typischerweise ein cloudbasiertes Warehouse wie Snowflake, BigQuery, Databricks oder Redshift, aber auch relationale Datenbanken. Auf dieser Verbindung definiert man Modelle: Sie legen fest, welche Daten Hightouch überhaupt sieht und aktiviert. Ein Modell wird häufig als SQL-Abfrage formuliert, kann aber auch aus vorhandenen Tabellen oder aus den Ergebnissen eines Transformations-Werkzeugs stammen. Das Modell ist damit die Definition der Daten, mit denen anschließend gearbeitet wird.
Der praktische Vorteil dieses Ansatzes ist, dass die volle Ausdruckskraft des Warehouse zur Verfügung steht. Alles, was sich im Warehouse berechnen lässt – ein Kundenwert, ein Segment, eine abgeleitete Kennzahl –, kann zur Grundlage einer Aktivierung werden, ohne dass die Logik ein zweites Mal in einem fremden System nachgebaut werden müsste. Für Unternehmen mit einem gepflegten Warehouse ist das ein erheblicher Effizienzgewinn: Die Datenlogik lebt an einer einzigen Stelle und wird von dort aus nutzbar gemacht.
Der eigentliche Aktivierungs-Mechanismus sind die Syncs. Ein Sync verbindet ein Modell mit einer Destination – also mit einem Zielsystem wie einem CRM, einer E-Mail-Plattform, einem Werbekonto oder einem Support-Tool – und sorgt dafür, dass die im Modell definierten Daten dorthin geschrieben und aktuell gehalten werden. Hightouch erkennt dabei Veränderungen im Datenbestand und überträgt in der Regel nur die Unterschiede, statt bei jedem Lauf alles neu zu senden. Das macht die Übertragung effizient und schont sowohl das Warehouse als auch die Zielsysteme.
Das Zusammenspiel ist der eigentliche Alltagsnutzen: Man definiert einmal, welche Daten in welches Ziel gehören, und Hightouch hält diese Verbindung dauerhaft aktuell. Ein neu berechnetes Segment im Warehouse steht so kurze Zeit später im Marketing-Tool zur Verfügung. Ein besonders wichtiger Aspekt ist die Zuverlässigkeit dieser Übertragung – Fehlerbehandlung, Wiederholungen und Transparenz darüber, was tatsächlich übertragen wurde, gehören zu den Funktionen, auf die man bei der Bewertung achten sollte, weil an ihnen der operative Betrieb hängt.
Damit nicht für jede Zielgruppe SQL geschrieben werden muss, bietet Hightouch mit dem Customer Studio eine Oberfläche, die sich an Marketing-Teams richtet. Dort lassen sich über einen visuellen Segment-Builder Audiences zusammenstellen: Zielgruppen, die auf den im Warehouse vorhandenen Merkmalen und Ereignissen beruhen, aber ohne Programmierkenntnisse definiert werden können. Aus den Rohdaten lassen sich abgeleitete Merkmale berechnen und Zielgruppen bilden, die sich automatisch aktualisieren, sobald sich die zugrunde liegenden Daten ändern.
Dieser Self-Service-Charakter ist ein wichtiges Argument, weil er die Kluft zwischen technischem Data-Team und operativem Marketing überbrückt. Das Data-Team pflegt die verlässliche Datengrundlage im Warehouse, das Marketing-Team baut darauf eigenständig seine Zielgruppen. Die Identitätsauflösung findet dabei ebenfalls auf der eigenen Datenbasis statt: Verstreute Datensätze werden zu einer konsolidierten Personensicht zusammengeführt, ohne dass die Daten dafür in ein fremdes System kopiert werden müssten. Gerade weil hier vollständige Personenprofile entstehen, ist der Datenschutz besonders sorgfältig zu bedenken – dazu mehr in Kapitel 09.
Unter dem Begriff AI Decisioning verfolgt Hightouch den Gedanken, die Auswahl der besten Ansprache je Person nicht mehr von Hand über starre Regeln zu steuern, sondern einem KI-gestützten System zu überlassen. Statt eine feste Kampagnen-Logik zu definieren – wer welche E-Mail zu welchem Zeitpunkt bekommt –, formuliert man Ziele und Rahmenbedingungen, und das System entscheidet auf Basis der Warehouse-Daten und der beobachteten Ergebnisse, welche Variante für welche Person am erfolgversprechendsten ist. Der Anspruch ist, Personalisierung von einer manuell gepflegten Regelmenge zu einem lernenden, datengetriebenen Prozess weiterzuentwickeln.
Der praktische Reiz liegt darin, dass die Entscheidungen auf derselben verlässlichen Datengrundlage beruhen wie die übrige Aktivierung – dem eigenen Warehouse. Wichtig ist jedoch eine nüchterne Erwartung: Die Qualität solcher Entscheidungen hängt unmittelbar von der Menge, Sauberkeit und Aussagekraft der zugrunde liegenden Daten ab. Ohne eine belastbare Datenbasis und ohne genügend Beobachtungen, aus denen ein System lernen kann, bleiben auch die klügsten Modelle Ratespiele. AI Decisioning ist zudem ein jüngerer, sich entwickelnder Baustein, dessen genauer Funktionsumfang und dessen Reife für den konkreten Anwendungsfall beim Anbieter zu prüfen sind.
Aus unserer Sicht ist bei allen KI-Funktionen eine nüchterne Haltung angebracht. Sie können die Arbeit mit Kundendaten spürbar erleichtern und die Ansprache intelligenter machen. Sie sind aber selten allein der Grund, sich für oder gegen eine Plattform zu entscheiden – und sie werfen zusätzliche Fragen auf: Welche Daten fließen in die Entscheidungen ein? Wo werden sie verarbeitet? Wie verträgt sich das mit den Datenschutz-Anforderungen? Gerade beim Einsatz von KI-Funktionen eines US-Anbieters lohnt es sich, den Verarbeitungsweg genau zu betrachten, bevor man sie produktiv nutzt.
Ein Vorteil des warehouse-native Ansatzes ist, dass die Rohdaten grundsätzlich im eigenen Warehouse verbleiben. Dennoch sollte man klären, welche Daten die KI-Funktion tatsächlich benötigt, wohin sie zur Verarbeitung gelangen und welche Ableitungen daraus entstehen. Diese Fragen gehören in die Datenschutz-Betrachtung und sollten dokumentiert werden, statt sie im Vertrauen auf den Anbieter zu überspringen.
Neben AI Decisioning liegt der eigentliche Automatisierungs-Gewinn von Hightouch im Datenfluss selbst. Einmal eingerichtete Syncs laufen nach einem definierten Zeitplan oder ausgelöst durch Veränderungen und halten die Zielsysteme ohne manuelles Zutun aktuell. Zielgruppen aktualisieren sich automatisch, sobald sich die zugrunde liegenden Warehouse-Daten ändern, und abgeleitete Merkmale werden fortgeschrieben. Diese Form der Automatisierung ist weniger spektakulär als lernende KI, in der Praxis aber oft wertvoller: Sie sorgt dafür, dass die richtigen Daten zuverlässig an der richtigen Stelle ankommen.
Für den Mittelstand ist das häufig der überzeugendere Hebel als jede einzelne KI-Funktion. Ein gut gebauter, verlässlich laufender Datenfluss entlastet die Teams dauerhaft und beseitigt manuelle Exporte und Importe, die früher Zeit gekostet und Fehler produziert haben. Die Zuverlässigkeit eines sauber konfigurierten Sync-Netzes schlägt kurzfristige Effekthascherei – und sie ist der wahre Automatisierungs-Nutzen, den Hightouch liefert.
Hightouchs Katalog aus Destinations umfasst eine sehr große Zahl fertiger Integrationen zu gängigen operativen Werkzeugen – von CRM- und Vertriebssystemen über E-Mail- und Marketing-Automation, Werbeplattformen und Analyse-Tools bis zu Support- und Kommunikationslösungen. Der entscheidende Punkt: Diese Verbindungen sind vorgefertigt. Statt für jedes Zielsystem eine eigene Schnittstelle zu programmieren und eine eigene Datenpipeline zu warten, aktiviert man in Hightouch eine Destination und verbindet sie über einen Sync mit dem passenden Modell.
Für den Mittelstand ist dieser Katalog der eigentliche wirtschaftliche Hebel. Er ersetzt in vielen Fällen individuelle Entwicklungsarbeit, die sonst nötig wäre, um Daten aus dem Warehouse in die operativen Systeme zu bringen. Diese Aufgabe – Daten aus dem Warehouse verlässlich in Zielsysteme zu schreiben – ist erfahrungsgemäß aufwendig und fehleranfällig, wenn man sie selbst baut. Der Katalog macht sie zu einer Konfigurationsaufgabe und macht die Werkzeug-Landschaft flexibel: Ein Zielsystem lässt sich ergänzen oder austauschen, ohne dass eine neue Pipeline programmiert werden muss.
Die andere Seite des Ökosystems sind die Sources – die Anbindungen an die eigenen Datenquellen. Hightouch verbindet sich mit den gängigen cloudbasierten Data Warehouses und Datenbanken und lässt sich in bestehende Datenprozesse einfügen, etwa in die Modelle eines Transformations-Werkzeugs. Weil die Daten dabei im Warehouse verbleiben und Hightouch sie nur liest und die relevanten Ausschnitte an die Ziele überträgt, entsteht keine zweite vollständige Datenkopie in einer fremden Plattform.
Diese warehouse-zentrierte Architektur ist auch strategisch relevant. Sie verringert die Abhängigkeit davon, dass alle Kundendaten in einer geschlossenen CDP liegen, und sie hält die Rohdaten in einem System, das das Unternehmen selbst kontrolliert – dessen Standort, Zugriff und Absicherung das Unternehmen selbst bestimmt. In der Diskussion um Datenhoheit ist das ein gewichtiger Baustein: Je mehr die Wahrheit im eigenen Warehouse liegt, desto unabhängiger ist das Unternehmen von einem einzelnen Anbieter – ein Gedanke, der auch für die Datenschutz-Betrachtung eine wichtige Rolle spielt.
So stark der Katalog ist, er hat Grenzen. Nicht jede Integration ist gleich tief: Manche Destinations unterstützen nur einen Teil der möglichen Objekte oder Felder eines Zielsystems, andere bilden bestimmte Funktionen nicht vollständig ab. Vor der Einführung lohnt es sich deshalb, für die wirklich wichtigen Ziele genau zu prüfen, welche Daten in welcher Tiefe übertragen werden können – der Katalog löst das Verbindungsproblem, aber nicht automatisch jede fachliche Feinheit.
Hinzu kommt, dass auch mit dem besten Katalog die konzeptionelle Arbeit bestehen bleibt. Ein Sync schnell zu aktivieren heißt nicht, dass die Daten fachlich richtig zugeordnet sind. Der Katalog spart Programmierarbeit, ersetzt aber nicht das Nachdenken darüber, welche Daten überhaupt an welches Ziel gehören und wofür. Wer das übersieht, verwechselt technische Verbindungsfähigkeit mit fachlicher Datenqualität – ein Trugschluss, der sich in der operativen Nutzung später rächt.
Census ist der direkteste Wettbewerber von Hightouch: Beide sind warehouse-native Reverse-ETL-Plattformen mit demselben Grundversprechen – das Warehouse als Wahrheit, die Aktivierung von dort aus. In der Kategorie gelten sie als die beiden prägenden Anbieter. Die Unterschiede liegen weniger im grundsätzlichen Ansatz als in den Details: im Zuschnitt der Marketing-Oberfläche, in der Tiefe einzelner Integrationen, im Umfang der KI- und Zusatzfunktionen und in der jeweiligen Betonung von Data-Team gegenüber Marketing-Team.
Für die Auswahl zwischen beiden empfehlen wir eine anwendungsbezogene Bewertung statt einer pauschalen Vorliebe. Entscheidend sind die konkreten Zielsysteme und deren Integrationstiefe, die Frage, wie viel Self-Service das Marketing-Team tatsächlich braucht, und die jeweiligen Datenschutz- und Vertragsbedingungen. Beide sind reife Vertreter der Composable-Idee; wer eine warehouse-native Aktivierung sucht, sollte beide in eine engere Auswahl nehmen und anhand der eigenen Anforderungen vergleichen, statt sich von der Marke leiten zu lassen.
Der grundlegendste Vergleich ist der mit der klassischen, paketierten CDP – etwa vom Typ Segment oder mParticle. Eine solche Plattform legt einen eigenen Datenspeicher an, sammelt Ereignisse selbst und bringt eine geschlossene, fertig konfigurierte Umgebung mit. Für Unternehmen ohne Warehouse und ohne Data-Team ist das eine niedrigere Einstiegshürde: Man muss keine eigene Datenbasis aufbauen, sondern kann direkt mit der Erfassung beginnen.
Hightouch gewinnt gegen die klassische CDP dort, wo bereits ein Warehouse existiert und Datenhoheit, die Vermeidung einer weiteren Datenkopie sowie die Nutzung vorhandener Datenlogik im Vordergrund stehen. Die klassische CDP gewinnt, wenn kein Warehouse vorhanden ist, die Event-Sammlung von Web und App im Zentrum steht und eine schlüsselfertige Lösung ohne technischen Unterbau gewünscht ist. Beide Ansätze schließen sich nicht zwingend aus – manche Unternehmen sammeln Ereignisse mit einem klassischen Werkzeug ins Warehouse und aktivieren anschließend mit Hightouch von dort aus.
RudderStack wird häufig als entwicklernahe, warehouse-zentrierte Alternative mit einer besonderen Stärke in der Datenerfassung wahrgenommen und verfügt ebenfalls über Reverse-ETL-Fähigkeiten. Der Schwerpunkt liegt dort traditionell stärker auf dem Sammeln und Weiterleiten von Ereignissen in das Warehouse, während Hightouch seinen Ursprung und seine Kernstärke in der Aktivierung aus dem Warehouse heraus hat. Beide teilen die warehouse-freundliche Grundhaltung.
Hightouch gewinnt dort, wo die operative Aktivierung vorhandener Warehouse-Daten und das marketingnahe Customer Studio im Vordergrund stehen. RudderStack punktet, wenn die entwicklernahe Erfassung von Ereignissen und deren Weiterleitung ins Warehouse den Schwerpunkt bilden. In der Praxis überschneiden sich die Fähigkeiten zunehmend, sodass die Wahl weniger an einzelnen Funktionen als an der Frage hängt, ob der Schwerpunkt des eigenen Vorhabens eher auf der Erfassung oder auf der Aktivierung liegt.
Hightouch ist eine betreute Cloud-Plattform. Die Steuerungsebene – also die Software, die Modelle verwaltet, Syncs auslöst und den Datentransfer orchestriert – betreibt der Anbieter. Das einsetzende Unternehmen muss sich nicht um Server, Skalierung oder Verfügbarkeit dieser Ebene kümmern. Der Vorteil ist ein geringer infrastruktureller Betriebsaufwand für die Aktivierungsschicht. Der entscheidende Unterschied zur klassischen CDP: Die Kundendaten selbst verbleiben im eigenen Warehouse; Hightouch liest sie und überträgt die relevanten Ausschnitte an die Ziele, hält aber keinen vollständigen eigenen Datenbestand vor.
Für den Mittelstand ist wichtig zu verstehen, wo die eigene Verantwortung liegt: nicht im Betrieb der Aktivierungssoftware, sondern im Betrieb und in der Pflege des Warehouse, in der Qualität der Modelle und – ganz wesentlich – in der datenschutzkonformen Nutzung. Hightouch liefert das Werkzeug für die Aktivierung; die fachliche und rechtliche Verantwortung für den Umgang mit den Kundendaten bleibt beim Unternehmen als Verantwortlichem im Sinne der Datenschutz-Grundverordnung.
Die Dauer einer Hightouch-Einführung hängt fast vollständig vom Reifegrad der Datengrundlage ab. Ist ein gepflegtes Warehouse mit sauberen, dokumentierten Modellen vorhanden, kann die eigentliche Anbindung und die Einrichtung erster Syncs vergleichsweise schnell gelingen. Fehlt diese Grundlage oder ist die Datenqualität unzureichend, verschiebt sich der Schwerpunkt: Dann steckt der eigentliche Aufwand in der vorgelagerten Datenaufbereitung, die vor der ersten Aktivierung stehen muss.
Entscheidend ist die Erkenntnis, dass Hightouch eine reife Datengrundlage voraussetzt. Ohne ein Warehouse und ohne jemanden, der die Modelle versteht und pflegt, entfaltet die Plattform ihren Wert nicht. Wer diese Grundlage nicht hat, sollte sie einplanen – der Aufbau eines Warehouse und die Datenmodellierung sind ein eigenes Projekt, das Hightouch nicht ersetzt, sondern voraussetzt. An dieser Stelle entscheidet sich, ob Hightouch zum wertvollen Aktivierungshebel oder zu einer teuren, halb genutzten Investition wird.
Aus unserer Erfahrung passt Hightouch besonders gut zu Mittelständlern, die bereits ein Data Warehouse betreiben oder ernsthaft aufbauen, die über ein Data- oder Analytics-Team mit SQL-Kompetenz verfügen und die ihre vorhandenen Daten operativ für Marketing, Vertrieb und Kundenbetreuung nutzen wollen. Diese Profile holen den vollen Nutzen der warehouse-native Aktivierung ab und rechtfertigen damit auch den Aufwand und die Kosten – zumal die Investition ins Warehouse ohnehin bereits getätigt wurde.
Weniger gut passt Hightouch zu Unternehmen, die noch kein Warehouse besitzen und dafür auch keine Grundlage schaffen wollen – hier fehlt schlicht das Fundament, auf dem Hightouch aufsetzt. Ebenso wenig ist Hightouch die richtige Wahl für Teams, die eine geschlossene, schlüsselfertige Marketing-Suite ohne technischen Unterbau erwarten oder deren Schwerpunkt auf der reinen Event-Sammlung von Web und App liegt. In solchen Fällen sind eine klassische CDP oder ein spezialisiertes Erfassungswerkzeug oft die passendere Antwort, und Hightouch käme erst später als Aktivierungsschicht ins Spiel.
In der Praxis sehen wir einen wiederkehrenden Entwicklungspfad. Unternehmen führen Hightouch meist ein, nachdem ihr Warehouse einen gewissen Reifegrad erreicht hat und die Frage aufkommt, wie sich die dort liegenden Daten operativ nutzbar machen lassen. Der Einstieg erfolgt fast immer über Reverse ETL: Zunächst werden die wichtigsten Zielsysteme angebunden und die zentralen Segmente und Kennzahlen aktiviert. In dieser Phase geht es vor allem darum, den Nutzen der vorhandenen Datengrundlage sichtbar zu machen.
Erst mit zunehmender Reife kommen die weiteren Bausteine hinzu: das Customer Studio, sobald das Marketing-Team eigenständig Zielgruppen bauen soll, und KI-Funktionen wie AI Decisioning, sobald eine belastbare Datenbasis und genügend Erfahrung vorhanden sind. Dieser schrittweise Ausbau ist sinnvoll und wirtschaftlich vernünftig, weil man nur für das zahlt, was man tatsächlich nutzt. Er verlangt aber Disziplin: Jeder neue Baustein sollte einem konkreten, geklärten Anwendungsfall folgen, nicht dem bloßen Wunsch, mehr Funktionen zu haben.
Die Kosten von Hightouch richten sich in der Regel nicht nach der Zahl der Nutzer, sondern nach der Nutzung – etwa nach der Zahl der synchronisierten Datensätze oder aktivierten Personen sowie nach den genutzten Funktionsbausteinen. Der genaue Preismechanismus und die aktuellen Konditionen sollten beim Anbieter geprüft werden; entscheidend für die Planung ist das Verständnis der Logik. Hightouch bietet üblicherweise ein begrenztes Einstiegsangebot, darüber gestaffelte Stufen und schließlich individuell verhandelte Verträge für größere Volumina und Enterprise-Anforderungen.
Für die Budgetierung folgt daraus ein wichtiger Grundsatz: Die Kosten skalieren mit dem Umfang der Aktivierung. Wächst die Zahl der aktivierten Personen oder werden mehr Bausteine wie Customer Studio oder AI Decisioning genutzt, wächst tendenziell auch die Rechnung. Deshalb gehören eine realistische Prognose und regelmäßige Nutzungs-Reviews fest zur wirtschaftlichen Steuerung. Ein Aspekt, den man mitdenken sollte: Die Kosten für das Data Warehouse selbst kommen hinzu und sind Teil der Gesamtrechnung des warehouse-native Ansatzes. Konkrete Zahlen nennen wir bewusst nicht, da sie sich ändern und stark vom Einzelfall abhängen; die Konditionen sind immer aktuell beim Anbieter zu prüfen.
Der zentrale und positive Unterschied gegenüber einer klassischen CDP ist bei Hightouch der Umgang mit dem Datenbestand. Weil die Kundendaten im eigenen Data Warehouse verbleiben und Hightouch keine vollständige zweite Kopie in einer geschlossenen Plattform anlegt, behält das Unternehmen ein hohes Maß an Kontrolle. Es bestimmt selbst, in welcher Region das Warehouse betrieben wird, wer Zugriff hat und wie die Daten abgesichert sind. Für die Datenhoheit ist das ein gewichtiges Argument: Die Wahrheit liegt im selbst kontrollierten System, nicht in der Datenbank des Anbieters.
Dieser Vorteil ist real, sollte aber nicht überzeichnet werden. Hightouch liest aus dem Warehouse und überträgt Ausschnitte an die Zielsysteme – dabei werden personenbezogene Daten von der Steuerungsebene verarbeitet und in die Destinations geschrieben. Zudem stehen die Zielsysteme, in die aktiviert wird, jeweils unter ihren eigenen Datenschutz-Bedingungen. Der warehouse-native Ansatz entschärft die Frage der zentralen Datenkopie, ersetzt aber weder die Betrachtung der Steuerungsebene noch die der Zielsysteme. Datenhoheit gewinnt man vor allem dadurch, dass man das Warehouse bewusst in einer geeigneten Region betreibt und die Datenflüsse sauber kontrolliert.
Da Hightouch ein Produkt eines US-amerikanischen Unternehmens ist, sind mehrere Aspekte zu klären. Zunächst der Standort des eigenen Warehouse: Hier haben Unternehmen die Wahl und sollten bewusst eine geeignete Region wählen, denn dort liegen die eigentlichen Rohdaten. Sodann die Steuerungsebene von Hightouch: Wo läuft sie, welche Daten sieht und verarbeitet sie, und bietet der Anbieter eine EU-Region für die Plattform an? Ob und in welchem Umfang eine solche EU-Option für den konkreten Anwendungsfall verfügbar ist und was sie genau abdeckt, sollte direkt beim Anbieter geprüft und vertraglich festgehalten werden.
Selbst bei einer EU-Region bleibt Hightouch ein US-Unternehmen, das grundsätzlich US-Recht unterliegt. Für jeden Datentransfer in die USA oder für Zugriffe mit Drittlandbezug sind die geltenden Transfer-Mechanismen – etwa geeignete vertragliche Garantien und etwaige zusätzliche Schutzmaßnahmen – sowie das daraus folgende Restrisiko zu bewerten. Diese Bewertung ist kein Automatismus, sondern eine bewusste Abwägung, die dokumentiert werden sollte. Für besonders sensible Datenkategorien oder streng regulierte Umfelder kann sie anders ausfallen als für weniger kritische Anwendungen.
Neben dem Transfer sind die üblichen Bausteine eines datenschutzkonformen Betriebs zu beachten. Dazu gehört der Abschluss eines Auftragsverarbeitungsvertrags (im internationalen Kontext oft als Data Processing Agreement bezeichnet), der die Rollen und Pflichten regelt. Da Hightouch personenbezogene Daten in operative Systeme schreibt, kommt der Rechtsgrundlage für diese Verarbeitung und, wo erforderlich, einem sauberen Einwilligungs-Management Bedeutung zu – insbesondere dann, wenn Daten für Werbezwecke an externe Plattformen übertragen werden.
Weil auf der Warehouse-Grundlage vollständige Personensichten entstehen und aktiviert werden, sind zudem die Betroffenenrechte sorgfältig abzubilden – insbesondere Auskunft, Löschung und Datenexport. Ein Vorteil des warehouse-native Ansatzes ist, dass sich diese Rechte zu großen Teilen im eigenen Warehouse umsetzen lassen, das das Unternehmen ohnehin kontrolliert. Vor dem Produktivbetrieb sollte dennoch praktisch getestet werden, dass sich Löschungen und Auskünfte über Warehouse und Syncs hinweg konsistent abbilden lassen. Die Verantwortung für den rechtmäßigen Umgang mit den Kundendaten bleibt durchgehend beim einsetzenden Unternehmen als Verantwortlichem im Sinne der Datenschutz-Grundverordnung; Hightouch ist das Werkzeug, nicht der Verantwortliche.
Zum Abschluss eine ehrliche, verdichtete Einschätzung. Hightouch ist im richtigen Anwendungsfall eine ausgesprochen elegante Aktivierungsschicht – aber nicht in jeder Situation die passende Wahl, und mit klaren Grenzen, die man vor der Entscheidung kennen muss.
