Unique customer ID
Von Iago Carballo · Veröffentlicht am 8. Juli 2026
„Die IT muss dem Marketing ein Segment von Hand erstellen und dafür Daten aus Silos aufbereiten. Und es ist nicht dynamisch.“
Wenn Sie im Marketing eines mittelgroßen Händlers arbeiten, kennen Sie das, ohne dass es Ihnen jemand erklären muss. Sie fragen ein Segment an, Kunden aus Madrid, die in den letzten drei Monaten Jeans, aber keinen Hoodie gekauft haben, und die Antwort ist nicht das Segment. Es ist ein Ticket an die IT, eine Warteschlange und ein Liefertermin, der davon abhängt, wie viele Kernprojekte die IT vor Ihrem hat. Wenn das Segment ankommt, ist es nicht mehr dasselbe Segment. Die Kunden, die diese Bedingung vor zwei Wochen erfüllten, sind nicht dieselben, die sie heute erfüllen. Einige haben den Hoodie bereits gekauft. Andere kommen nicht mehr ins Geschäft. Das Segment, das Sie erhalten, ist eine veraltete Momentaufnahme eines Verhaltens, das sich längst geändert hat. In diesem Artikel geht es darum, wie sich das vermeiden lässt: was dynamische Segmentierung ist, wie sie sich von RFM unterscheidet, wo die meisten anfangen, und vor allem, wie Sie von einem klar definierten Segment zu einer laufenden Kampagne kommen, ohne dass das Marketing auf jemanden warten muss.
Die meisten Omnichannel-Händler haben ihre Kundendaten über verschiedene Systeme verstreut: das Kassensystem (POS) im stationären Geschäft, die E-Commerce-Plattform, das CRM, WhatsApp, wenn sie es für die Kundenbindung nutzen, die App, falls vorhanden. Jedes System kennt einen Teil der Geschichte. Keines kennt die ganze. Wenn das Marketing etwas Anspruchsvolleres als einen Massenversand starten will, etwa „Kunden, die in den letzten 60 Tagen im Geschäft gekauft, aber seither nicht online bestellt haben“ oder „Schuhkunden, die durchschnittlich mehr als 80 € ausgeben und in den letzten 30 Tagen keine Kommunikation erhalten haben“, gibt es dafür keinen Knopf. Es gibt eine Anfrage an die IT. Die IT muss diese Daten wiederum dort zusammensuchen, wo sie liegen, sie von Hand verknüpfen, bereinigen und eine Datei liefern. Das ist Dateninstallation, keine Strategie, und konkurriert meist um Priorität mit Projekten, die die IT für kritischer hält: das ERP, das POS selbst, die Sicherheit. Ein Marketingsegment gewinnt dieses Rennen selten. Das Ergebnis hat zwei Probleme, nicht eines. Das erste ist die Geschwindigkeit: Was Minuten dauern sollte, dauert Tage oder Wochen. Das zweite, leisere: Das Segment ist schon bei seiner Entstehung veraltet. Es ist ein einmaliger Auszug, eine Momentaufnahme. Der Kunde, der die Bedingung am Tag der Abfrage erfüllte, erfüllt sie womöglich nicht mehr, wenn die Kampagne startet. Das ist kein Talentproblem des IT-Teams, sondern ein Architekturproblem. Wenn Kundendaten in Silos fragmentiert sind und es keine Ebene gibt, die sie nativ vereint, erfordert jedes halbwegs anspruchsvolle Segment manuelle Eingriffe. Und Manuelles skaliert nicht, geschweige denn aktualisiert es sich selbst. Die Alternative ist nicht, mehr Leute in der IT einzustellen oder den Ticketprozess zu beschleunigen. Sie besteht darin, Tickets überflüssig zu machen. Genau das ändert sich mit dynamischer Segmentierung.
Ein statisches Segment ist eine Momentaufnahme: Es wird einmal mit den zu diesem Zeitpunkt verfügbaren Daten berechnet und bleibt fix, bis es jemand von Hand neu berechnet. Wenn Sie es am Montag erstellt haben, ist es am Freitag bereits veraltet: Einige Kunden, die die Bedingung erfüllten, erfüllen sie nicht mehr, und andere, die sie jetzt erfüllen, blieben außen vor, weil sie sich erst nach dem Stichtag qualifiziert haben. Ein dynamisches Segment ist keine Momentaufnahme. Es ist eine lebendige Regel. Der Kunde tritt automatisch in das Segment ein und wieder aus, je nach seinem tatsächlichen Verhalten, ohne dass jemand etwas neu ausführen muss. Wenn Sie „Kunden, die seit 45 Tagen nicht gekauft haben“ definieren, berechnet sich dieses Segment selbst neu: Der Kunde, der heute 44 Tage ohne Kauf erreicht hat, kommt morgen hinein, und wer wieder kauft, scheidet automatisch aus, ohne dass das Marketing daran denken muss, ihn zu entfernen. Der Unterschied wirkt auf dem Papier klein und ist in der Praxis enorm. Bei einem statischen Segment beginnt jede Kampagne mit der Frage „Ist dieses Segment noch gültig?“. Bei einem dynamischen stellt sich die Frage nicht: Das Segment spiegelt immer das aktuelle Verhalten wider, nicht das zum Zeitpunkt der Berechnung.

Die bekannteste Form dynamischer Segmentierung ist RFM: Recency (Aktualität), Frequency (Häufigkeit) und Monetary value (Kaufwert). Wenn Sie das Modell bereits kennen, wissen Sie, dass es Kunden danach einordnet, wann sie gekauft haben, wie oft und wie viel sie ausgeben. Es ist ein hervorragender Ausgangspunkt, weil es einfach zu verstehen ist und den häufigsten Anwendungsfall abdeckt: die besten Kunden und die abwanderungsgefährdeten zu identifizieren. Aber RFM allein schöpft nicht aus, was dynamische Segmentierung leisten kann. Eine vollständige Engine für dynamische Segmentierung arbeitet mit mehr als 50 verschiedenen Parametern: gekaufte Produktkategorie, bevorzugter Einkaufskanal, Rabattsensibilität, Retourenverhalten, Interaktion über WhatsApp, durchschnittlicher Warenkorb pro Besuch, Wochentag des Einkaufs, Produktkombinationen, die sie noch nie ausprobiert haben. RFM ist der Haupteingang. Die vollständige dynamische Segmentierung ist das ganze Haus.
Hier kommt der Teil, der den Marketingalltag wirklich verändert: Ein dynamisches Segment aufzubauen, sollte weder SQL-Kenntnisse erfordern noch davon abhängen, dass ausgerechnet in dieser Woche jemand verfügbar ist, der sie hat. In der Praxis funktioniert das so: Das Marketing kombiniert Bedingungen visuell, „Kategorie = Schuhe“ + „durchschnittlicher Warenkorb > 80 €“ + „letzter Kauf vor 30 bis 60 Tagen“, und das System erstellt das Segment sofort, ohne dass dafür eine Datenbankabfrage nötig wäre, die jemand schreiben, prüfen und pflegen muss. Das ist keine kosmetische Vereinfachung von etwas, das darunter technisch bleibt. Es ist der Unterschied zwischen einem Marketing, das von einer knappen Ressource abhängt, nämlich jemandem, der Abfragen schreiben kann, und einem, das in voller Autonomie mit einer Engine arbeitet, die für Menschen ohne technisches Profil gemacht ist, die keines haben oder wollen. Die praktische Folge: Der gesamte Zyklus, also eine Kampagnenidee haben, das passende Segment bauen und starten, wird von einem Prozess über Tage oder Wochen mit IT-Beteiligung zu einem Prozess, den das Marketing von Anfang bis Ende in einer einzigen Arbeitssitzung durchführt, ohne ein Ticket zu eröffnen. Genau das ändert sich für CRM- oder Loyalty-Verantwortliche, die heute besser segmentieren wollen, aber für jede Aktion die IT brauchen. Der Engpass wird nicht schneller. Er verschwindet.
Ein gut aufgebautes Segment ist nur die halbe Arbeit. Die andere Hälfte ist das, was danach geschieht: diese Liste in eine Kampagne zu verwandeln, die der Kunde tatsächlich auf dem Kanal erhält, auf dem er sich befindet, und nicht auf dem, der dem Marketing gerade bequem ist. Ein dynamisches Segment, das nicht an die Aktivierung angebunden ist, bleibt eine akademische Übung. Der Kreis schließt sich, wenn dasselbe Segment nativ über die relevanten Kanäle aktiviert werden kann, E-Mail, SMS, In-App-Push, WhatsApp, und zusätzlich als Zielgruppe an Meta Ads und Google Ads exportiert wird, um das bezahlte Budget mit echten Verhaltensdaten hyper-zu segmentieren, statt mit der generischen Segmentierung der Werbeplattform selbst. Ein konkreter Anwendungsfall: schwach besuchte Tage. Die meisten stationären Geschäfte haben im Wochenverlauf ein ungleichmäßiges Kundenaufkommen, Spitzen am Samstag, Flauten am Dienstag und Mittwoch. Mit einem dynamischen Segment aus „Kunden mit hoher Kaufhäufigkeit, die seit 10 Tagen nicht im Geschäft waren“, gezielt per WhatsApp mit einem Anreiz für einen Besuch an einem bestimmten Tag aktiviert, lässt sich ein Teil dieses Aufkommens von den Spitzentagen auf die schwachen Tage verlagern, ohne einen Massenrabatt für die gesamte Kundenbasis, nur für das Segment, das den Tag wirklich wechseln kann. Ein weiterer Anwendungsfall: der abwanderungsgefährdete Kunde. Ein dynamisches Segment, das erkennt, wenn die Recency eines Kunden zu sinken beginnt, bevor er zum inaktiven Kunden wird, ermöglicht eine Reaktivierungskampagne genau in dem Zeitfenster, in dem der Versuch noch sinnvoll ist, und nicht Monate später, wenn es schon zu spät ist. Rechtzeitiges Handeln zählt: Einen Kunden zu verlieren kostet fünf- bis siebenmal mehr, als ihn zu halten, sodass jede Woche, die dieses Segment bis zur Aktivierung braucht, reale und nicht nur theoretische Kosten verursacht. Ein dritter Fall schließt den Kreis mit dem Beispiel vom Anfang dieses Artikels: Cross-Selling nach Kategorie. Das Segment „hat in den letzten 90 Tagen Jeans gekauft, aber keinen Hoodie“ ist keine theoretische Kuriosität, sondern genau die Art von Regel, die bei manueller Berechnung erfordert, POS und E-Commerce zu verknüpfen, nach Kategorie und Datum zu filtern und das Ergebnis als Datei zu liefern. Dynamisch berechnet existiert sie als lebendige Regel, die per E-Mail oder WhatsApp aktiviert wird, sobald der Kunde die Bedingung erfüllt, und nicht erst Wochen nach einer Anfrage an die IT. Es sind dieselben Daten, nur rechtzeitig. Der Grundgedanke: Segmentieren und Aktivieren sind keine zwei getrennten Projekte mit einer Informationsübergabe dazwischen. Es ist derselbe Workflow, ohne Reibung zwischen dem Moment, in dem Sie festlegen, mit wem Sie sprechen, und dem Moment, in dem diese Person die Nachricht erhält.

Es lohnt sich, innezuhalten und zu verstehen, warum die dynamische Natur des Segments, und nicht nur seine Raffinesse, den größten Einfluss auf die Ergebnisse hat. Stellen Sie sich vor, Sie definieren das Segment „gefährdete Kunden“: historisch hohe Kaufhäufigkeit, aber eine Recency, die zu sinken begonnen hat. Würde dieses Segment nur einmal im Monat berechnet, ginge die Hälfte seines Werts verloren. Ein Kunde, der an Tag 3 gefährdet wird, erhält keinerlei Kommunikation, bis das Segment neu berechnet wird, möglicherweise erst Wochen später, wenn er die Grenze zum „inaktiven“ Kunden bereits überschritten hat, bei dem die Reaktivierung teurer ist und schlechter funktioniert. Eine Engine für dynamische Segmentierung bewertet das Verhalten jedes Kunden fortlaufend: Segmente aktualisieren sich in Echtzeit oder alle 2 Stunden, wenn die Komplexität der Regeln das erfordert. Der Unterschied zwischen „Echtzeit“ und „einmal im Monat“ ist keine schrittweise Verbesserung, sondern der Unterschied zwischen einem Eingriff in dem Zeitfenster, in dem der Kunde noch zurückzugewinnen ist, und der zu späten Erkenntnis, dass er es nicht mehr ist. Das verändert auch das Verhältnis des Marketings zum Risiko. Sind die Daten veraltet, ist jede Kampagne eine Wette: Stimmt noch, was ich über dieses Segment angenommen habe? Aktualisiert sich das Segment von selbst, spielt diese Frage keine Rolle mehr: Das Segment, das Sie heute aktivieren, spiegelt das Verhalten von heute wider, nicht das vom letzten Mal, als es jemand von Hand neu berechnet hat.
An dieser Stelle kommt häufig ein Einwand, meist nicht von demjenigen, der das Segment anfordert, sondern von dem, der es bisher gebaut hat: Wenn das Marketing Segmente ohne die IT erstellen und aktivieren kann, verliert die IT dann die Kontrolle darüber, was mit den Kundendaten geschieht? Nein. Es ändert sich die Art der Arbeit der IT, nicht ihre Transparenz. Die Integration wird einmalig über eine einzige Checkout-API gelöst, die sich mit dem POS oder der E-Commerce-Plattform verbindet, ohne dass dafür das ERP, die Preis-Engine oder Geschäftslogik auf Händlerseite angefasst werden müssten. Sobald diese Verbindung steht, erfordert jedes Segment und jede Kampagne, die das Marketing danach aufbaut, keinen weiteren technischen Eingriff. Die IT verliert nicht den Einblick in die Architektur, sie ist nur nicht mehr der operative Engpass für jede einzelne Marketingaktion. Das ist besonders bei Händlern wichtig, bei denen die IT mit Kernprojekten ohnehin am Limit ist und keine Kapazität für eine weitere Baustelle hat. Die Frage, die einen IT-Leiter wirklich interessiert, lautet nicht „Wer hat die Kontrolle?“, sondern „Wie viel neue Arbeit kommt auf mich zu?“. Die Antwort lautet in diesem Modell: eine initiale Integration und danach nichts Wiederkehrendes. Das Marketing arbeitet eigenständig mit Daten, die bereits sauber und vereinheitlicht sind, und nicht mit direktem, unbeaufsichtigtem Zugriff auf die kritischen Systeme des Unternehmens.
Alles Bisherige, ohne SQL aufgebaute Segmente, nativ auf dem richtigen Kanal aktiviert, von selbst aktuell gehalten, führt zu einem einzigen praktischen Schluss: Das Marketingteam kann von Anfang bis Ende mit echter Autonomie arbeiten, ohne dass jede Aktion von der Verfügbarkeit der IT abhängt. Das ist nicht nur eine Frage der Geschwindigkeit, auch wenn Geschwindigkeit zählt. Es geht darum, welche Art von Marketing ein Team machen kann, wenn es nicht jedes Segment vor einer Ticket-Warteschlange rechtfertigen muss. Kampagnen, die den Abstimmungsaufwand früher nicht wert waren, zu spezifisch, zu klein, zu zeitkritisch, um zu warten, werden machbar. Das Marketing beschränkt sich nicht länger auf das, was leicht anzufordern ist, und orientiert sich stärker an dem, was das Unternehmen tatsächlich braucht. Wenn die richtigen Segmente zum richtigen Zeitpunkt aktiviert werden, zeigt sich die Wirkung dort, wo sie am meisten zählt: Plattformdaten zeigen einen um 20 % höheren durchschnittlichen Bestellwert bei Cross-Selling-Kampagnen, die auf Basis echten Verhaltens aktiviert werden, verglichen mit generischen Kampagnen an die gesamte Kundenbasis. Wenn Sie noch von einem Ticket an die IT abhängig sind, um ein Segment zu starten, ist das kein Problem Ihres Marketingteams. Es ist ein Problem der Architektur, auf der Ihr aktueller Stack beruht, und genau das Problem, das native dynamische Segmentierung konzeptionell löst, nicht als Notlösung. Wenn Sie sehen möchten, wie eines dieser Segmente mit Ihren eigenen Daten aufgebaut wird, statt nur in der Theorie, beantwortet ein 30-minütiges Gespräch mit dem Team meist mehr Fragen als jeder Artikel.