User State Models: Warum du nicht mehr Leads brauchst, sondern bessere

Ein User State Model ordnet Kontakte danach, wo sie gerade stehen – nicht danach, was sie zuletzt getan haben. In ActiveCampaign lässt sich das mit Tags umsetzen: Jeder Zustand ist ein Tag, jeder Übergang eine Automation. Das Ergebnis ist Kommunikation, die zum aktuellen Stand des Kontakts passt, statt generische Sequenzen für alle zu schicken.

Das Wichtigste in Kürze

• Ein User State Model fragt nicht, was ein Kontakt getan hat, sondern wo er gerade steht – das ist ein anderer Ausgangspunkt als eine Customer Journey Map.
• Drei bis fünf States reichen für den Start; mehr als sechs machen das System kaum noch wartbar.
• State-Übergänge brauchen Kombinationsbedingungen, keine einzelnen Klicks als Auslöser – sonst greifen States zu früh und verlieren ihre Aussagekraft.
• ActiveCampaign bildet jeden State als Tag ab; für jeden Übergang gibt es eine eigene Automation, die das alte Tag entfernt und das neue setzt.
• States können sich rückwärts bewegen – eine Decay-Logik verhindert, dass inaktive Kontakte dauerhaft im falschen Zustand bleiben.

Was ein User State Model von einer Customer Journey Map unterscheidet

Eine Customer Journey Map beschreibt eine Abfolge von Aktionen: Kontakt lädt ein Dokument herunter, öffnet drei E-Mails, besucht die Preisseite, bucht ein Gespräch. Das ist nützlich für das Mapping der Touchpoints, sagt aber wenig darüber aus, in welchem Zustand sich der Kontakt bei jedem dieser Schritte befindet.

Ein User State Model verschiebt den Blick. Es fragt nicht, was dieser Kontakt getan hat, sondern wo er gerade steht. Der Unterschied ist nicht akademisch: Wer annimmt, ein Kontakt sei kaufbereit, weil er zweimal die Preisseite besucht hat, schickt möglicherweise ein Angebot an jemanden, der gerade nur recherchiert, ohne Kaufabsicht. Das Ergebnis ist ein Gespräch im falschen Moment – und im B2B-Kontext verbraucht das Vertrauen, das sich nur langsam aufbaut.

States sind außerdem nicht linear. Jemand, der letzte Woche noch im State Bereit war, kann heute wieder zögerlich sein, weil ein internes Budget-Gespräch schief gegangen ist oder weil ein Wettbewerber sich gemeldet hat. Eine gute State-Logik bildet solche Rückwärtsbewegungen ab, statt sie zu ignorieren.

Warum das im DACH-Kontext besonders zählt

Im deutschsprachigen Markt dauert die Evaluation länger und ist formaler. Angebote werden verglichen, Datenschutzfragen gestellt, Entscheidungen im Team getroffen statt von einer Person. Das verändert die Übergangsbedingungen: Ein einzelner Demo-Besuch ist deutlich seltener ein klares Kaufsignal als in anderen Märkten. Besser funktioniert eine Kombination – Demo-Buchung und mindestens zwei inhaltliche Seiten besucht und vorherige E-Mail-Klicks vorhanden. Diese Grundhaltung prägt, wie die Übergangsbedingungen von Anfang an definiert werden, nicht als nachträgliche Korrektur.

Welche States in der Praxis tragen – und warum weniger mehr ist

Die meisten Teams beginnen mit zu vielen States. Zwölf oder fünfzehn granulare Zustände klingen vollständig, sind in der Praxis aber kaum zu befüllen – der Content, der jemanden sehr spezifisch für einen Micro-State anspricht, existiert schlicht nicht. Das Ergebnis ist ein aufwendig aufgebautes System, das im Betrieb mangels passender Inhalte leerläuft.

Stabiler ist ein Modell mit drei bis fünf States, das nachträglich um ein bis zwei weitere erweitert wird, wenn sich im Betrieb zeigt, was fehlt. Das klingt simpel, ist aber der Ansatz, bei dem die State-Logik tatsächlich zu tragendem Bestandteil der Kommunikation wird.

Der Inaktiv-State ist kein Fail-State, sondern ein Pflege-Zustand mit eigener Re-Engagement-Logik. Kontakte, die ihn erreichen, waren schon einmal tiefer im Prozess – das ist wertvoller als ein frisch eingetragener Kontakt ohne Vorgeschichte.

Abgrenzung: State vs. Tag-Sammlung

Ein State beschreibt immer den aktuellen Zustand, nicht die gesamte Vergangenheit. Ein Kontakt, dem im Lauf der Zeit fünf verschiedene Themen-Tags gesetzt wurden, hat keine fünf States – er hat eine Tag-Geschichte. Der State ist das einzige Tag aus der State-Gruppe, das gerade aktiv ist. Wer das vermischt, baut kein State-Modell, sondern eine kompliziertere Version des Tag-Chaos, das ohnehin schon vorhanden ist.

Wie State-Übergänge messbar gemacht werden

Der schwierigste Teil eines User State Models ist nicht die technische Umsetzung in ActiveCampaign, sondern die Definition der Übergangsbedingungen. Wann gilt ein Kontakt als Prüfend und nicht mehr als Interessiert? Wann ist jemand wirklich bereit, und wann ist er nur kurz neugierig auf die Preisseite?

Schlechte Übergangsbedingungen basieren auf einzelnen Aktionen. Bessere Bedingungen kombinieren mehrere Signale, und zwar mit UND-Verknüpfungen, nicht mit ODER. Ein Kontakt, der entweder eine E-Mail geöffnet hat oder die Preisseite besucht hat, ist noch kein gutes Signal. Einer, der beide Aktionen gezeigt hat und dazu mindestens zwei unterschiedliche Inhalte geklickt hat, ist deutlich aussagekräftiger.

E-Mail-Verhalten als Signal

Öffnungen allein sind kein verlässliches Kriterium – Vorschau-Panels und automatische Prozesse verfälschen die Rate erheblich. Klicks sind aussagekräftiger, weil sie eine aktive Entscheidung erfordern. Noch besser: Klicks auf bestimmte Inhaltstypen. Wer auf einen Referenz-Link klickt, zeigt ein anderes Verhaltensmuster als jemand, der einen Blog-Artikel-Link anklickt.

Für den Übergang von Interessiert zu Prüfend eignet sich eine Kombination wie diese: Klick auf mindestens zwei inhaltlich unterschiedliche E-Mails in den letzten 14 Tagen. Das filtert Kontakte heraus, die nur an einem einzigen Thema interessiert waren, und zeigt stattdessen ein breites Engagement.

Website-Verhalten über Site Tracking

ActiveCampaigns Site Tracking gibt jedem Seitenaufruf eines bekannten Kontakts ein Ereignis – das lässt sich in Automationen direkt als Auslöser oder Bedingung nutzen. Für den Übergang zu Prüfend ist das besonders hilfreich: Wer die Preisseite besucht und mindestens eine Case Study gelesen hat, zeigt ein anderes Muster als jemand, der ausschließlich Blogartikel liest. Der technische Aufwand für das Site Tracking ist gering – ein JavaScript-Snippet auf der Website – der Informationsgewinn für die State-Logik ist aber deutlich größer als durch reines E-Mail-Tracking.

Explizite Signale als Übergangskatalysatoren

Manche Signale sind eindeutig: Eine Demo-Buchung, eine Preisanfrage oder das Ausfüllen eines Qualifizierungsformulars sind klare Übergänge in den State Bereit, die keine weiteren Kombinationsbedingungen brauchen. Das sind harte Auslöser, keine Indizien.

Der Fehler liegt hier oft darin, zu zögern: Wer erst prüft, ob der Kontakt nach der Demo-Buchung nochmals die Preisseite besucht, verzögert das Signal ans Vertriebsteam und verliert den Moment, in dem der Kontakt am aktivsten ist.

So baust du ein User State Model in ActiveCampaign auf

Der folgende Aufbau startet mit drei Basis-States – Interessiert, Prüfend und Bereit. Das ist absichtlich schlank: Es ist einfacher, später States hinzuzufügen, als ein zu komplexes System wieder zu vereinfachen. Alle Änderungen an Tags und Automationen lassen sich jederzeit erweitern, ohne die bestehende Logik zu unterbrechen.

1. Tags anlegen: Öffne in ActiveCampaign den Bereich Kontakte, dann Tags verwalten. Lege folgende Tags an: State_Interessiert, State_Prüfend, State_Bereit, State_Inaktiv. Das einheitliche Präfix State_ hält die Tags im Kontaktprofil erkennbar und verhindert, dass sie mit Kampagnen-Tags oder Themen-Tags vermischt werden.
2. Übergangs-Automation für Interessiert zu Prüfend: Gehe zu Automationen, dann Erstellen, Auslöser: Tag wurde hinzugefügt = State_Interessiert. Füge danach eine Warten-bis-Bedingung ein: Kontakt hat in den letzten 14 Tagen mindestens zwei verschiedene E-Mail-Links geklickt UND hat die Preisseite oder eine Case Study besucht. Wenn die Bedingung eintrifft: Tag State_Prüfend hinzufügen, Tag State_Interessiert entfernen. Diese Automation überwacht ausschließlich diesen einen Übergang.
3. Übergangs-Automation für Prüfend zu Bereit: Neue Automation: Auslöser = Tag State_Prüfend hinzugefügt. Warten bis: Kontakt hat Demo gebucht ODER Preisanfrage ausgefüllt. Wenn Bedingung eintrifft: Tag State_Bereit hinzufügen, Tag State_Prüfend entfernen. Optional: Interne Benachrichtigung an das Sales-Team per Notification-Aktion.
4. Inhalts-Automationen pro State: Unabhängig von den Übergangs-Automationen braucht jeder State eine eigene Inhaltsserie. Auslöser ist jeweils das Hinzufügen des entsprechenden State-Tags. Für State_Interessiert: Bildungsinhalt, Hintergrundartikel, Einblick in das Vorgehen. Für State_Prüfend: Case Studies, konkrete Vergleiche, Referenzen. Für State_Bereit: Klare nächste Schritte, Gesprächsangebot, spezifische Lösungsbeschreibung.
5. Decay-Automation einrichten: Erstelle eine Automation, die täglich läuft und prüft: Kontakt hat den Tag State_Prüfend und seit 45 Tagen kein Engagement gezeigt. Wenn Bedingung erfüllt: Tag State_Prüfend entfernen, Tag State_Inaktiv hinzufügen. Denselben Mechanismus für State_Interessiert mit einem anderen Schwellenwert – zum Beispiel 30 Tage. Der konkrete Schwellenwert hängt vom Vertriebszyklus ab; er stellt sich im Betrieb heraus, nicht vorab.
6. Einstiegspunkt festlegen: Entscheide, welche Aktion einen Kontakt in den ersten State bringt. Typisch: Formular-Eintrag mit einem Download = Tag State_Interessiert wird gesetzt. Das ist die einzige Aktion, die manuell oder über eine bestehende Automation ausgelöst werden muss – alles danach übernimmt das State-Modell selbst.

Typische Fehler – und was dahinter steckt

States auf Basis einzelner Aktionen definieren

Wer einen einzelnen Klick direkt als Übergang zu Prüfend wertet, bemerkt schnell, dass der State zu voll wird und seine Unterscheidungskraft verliert. Ein Kontakt, der versehentlich auf einen Link geklickt hat, landet im selben State wie einer, der gezielt inhaltlich gearbeitet hat. States sollten Zustände abbilden, keine Einzelereignisse. Der Übergang braucht ein Muster, keinen Treffer.

Keine Decay-Logik einbauen

Das langfristige Ergebnis: Der State Bereit enthält nach zwei Jahren Betrieb Hunderte von Kontakten, von denen die meisten das schon längst vergessen haben. Das verzerrt jede Auswertung und führt dazu, dass Vertriebsteams der State-Logik nicht mehr vertrauen. Eine Decay-Automation löst das Problem, bevor es entsteht – und ist der Teil des Systems, der am häufigsten fehlt.

States für Einzelkampagnen zweckentfremden

Ein häufiges Muster: Eine Kampagne soll nur an Kontakte im State Prüfend gehen. Das klingt sinnvoll, aber wenn die Kampagnen-Automation gleichzeitig das State-Tag verändert oder entfernt, bricht die gesamte State-Logik zusammen. States sind Zustands-Informationen, keine Segment-Filter für Einzelkampagnen.

Die saubere Lösung: Kampagnen-Segmente bilden, die den aktuellen State-Tag als Bedingung nutzen, ohne ihn zu verändern. Das State-System bleibt intakt, die Kampagne funktioniert trotzdem.

Das Modell zu früh ausrollen

Ein State-Modell, das in Produktion geht, bevor die Übergangsbedingungen an realen Kontakten getestet wurden, produziert zuverlässig falsche States. Besser: Die ersten 30 bis 50 Kontakte manuell begleiten, den State-Übergang von Hand setzen und erst dann die Automation aktivieren, wenn die Bedingungen verlässlich greifen. Das kostet zwei Wochen, spart aber Monate der Nachkorrektur.

Keine Abstimmung mit dem Vertriebsteam

Ein State-Modell, das im Marketing aufgebaut wird, ohne dass das Sales-Team weiß, was der State Bereit bedeutet und welche Aktion von ihm erwartet wird, ändert nichts. Die Technik kann den Übergang sauber tracken – der Unterschied entsteht erst, wenn aus dem State eine definierte Handlung folgt. Das Gespräch mit dem Vertrieb gehört zur Planung des Modells, nicht zur nachträglichen Einführung.

Wann ein User State Model nicht passt

User State Models lohnen sich ab einer bestimmten Kombination aus Listengröße und Vertriebskomplexität. Bei sehr kurzen Sales-Cycles oder einfachen Transaktionen, bei denen der Kauf unmittelbar auf den ersten Kontakt folgt, ist ein mehrstufiges State-Modell unverhältnismäßiger Aufwand. Der Betrieb des Systems – Automation-Pflege, Tag-Qualitätssicherung, Decay-Logik – rechnet sich erst, wenn das Nurturing tatsächlich mehrere Wochen oder Monate dauert.

Auch für sehr kleine Listen ist das manuelle Gespräch oft effizienter als ein vollautomatisches State-System. Die Grenze liegt nicht bei einer festen Kontaktzahl, sondern dort, wo das manuelle Qualifizieren jeden Kontakts nicht mehr machbar ist.

Ein State-Modell ist außerdem kein Ersatz für einen Vertriebsprozess. Wenn das Sales-Team keine definierten Handlungen kennt, die beim Erreichen des States Bereit ausgelöst werden, bleibt die gesamte Logik im Marketing-Tool stecken und erzeugt keinen messbaren Unterschied im Ergebnis. Die technische Umsetzung ist der einfachste Teil – die organisatorische Abstimmung entscheidet über Nutzen oder Leerlauf.

Häufige Fragen

Wie viele States brauche ich für den Anfang?

Drei States reichen für den Start: Interessiert, Prüfend und Bereit. Das ergibt zwei Übergänge, die sauber definiert und getestet werden können, ohne das System unübersichtlich zu machen. Erst wenn sich im Betrieb zeigt, dass ein State zwei sehr verschiedene Verhaltensgruppen enthält – zum Beispiel weil Prüfend sowohl ernsthafte Evaluatoren als auch gelegentliche Neugierige umfasst – lohnt es sich, ihn aufzuteilen.

Was passiert, wenn ein Kontakt gleichzeitig mehrere State-Tags trägt?

Das ist ein Zeichen, dass die Automation nicht vollständig bereinigt. Jeder Übergang muss das bisherige State-Tag explizit entfernen, bevor das neue gesetzt wird. Kontakte mit mehreren State-Tags gleichzeitig empfangen falsche Inhalte und machen jede Auswertung unbrauchbar. Die Lösung ist technisch einfach: In jeder Übergangs-Automation alle anderen State-Tags entfernen, nicht nur das unmittelbar vorherige.

Wie erkenne ich, ob meine Übergangsbedingungen zu früh oder zu spät greifen?

Das zeigt sich am verlässlichsten im Vertriebsfeedback. Wenn das Sales-Team regelmäßig meldet, dass Kontakte im State Bereit noch gar nicht so weit sind, greift der Übergang zu früh – die Kombination der Bedingungen ist zu locker. Wenn umgekehrt Kontakte manuell identifiziert werden, die längst ein Angebot hätten bekommen sollen, greift der Übergang zu spät. Das Feedback-Loop zwischen Vertrieb und Marketing ist dabei wichtiger als jedes technische Monitoring-Dashboard.

Kann ich ein User State Model mit Lead Scoring kombinieren?

Ja, und diese Kombination ist oft aussagekräftiger als jedes der beiden Systeme allein. Das Lead Scoring in ActiveCampaign bewertet kumulativ, was ein Kontakt getan hat; das State Model zeigt, wo er gerade steht. Ein Kontakt kann einen hohen Score haben und gleichzeitig im State Inaktiv sein – frühere Aktivität ist eingeschlafen. Wer beide Signale zusammendenkt, trifft bessere Einschätzungen. Die Verknüpfung läuft über Automationen, die State-Tag und Score-Schwellenwert als Bedingung prüfen.

Wie teste ich ein State-Modell, bevor ich es live schalte?

Erstelle zunächst alle Tags und Automationen, lasse die Automationen aber im inaktiven Zustand. Wähle dann 20 bis 30 bestehende Kontakte aus und weise ihnen den State-Tag manuell zu. Beobachte über eine bis zwei Wochen, ob die Übergangsbedingungen realistisch greifen und ob die Inhalts-Automationen das richtige Material ausspielen. Erst wenn die Logik für diese Testgruppe zuverlässig funktioniert, wird die Automation für neue Kontakte geöffnet. Dieser Test kostet Zeit, eliminiert aber die häufigsten Startfehler, bevor sie eine größere Liste betreffen.

Ein User State Model ist kein Einmal-Projekt. Die Übergangsbedingungen, die heute gut passen, müssen in einigen Monaten geprüft werden – Verhalten ändert sich, das Produktangebot ändert sich, und der Markt ändert sich. Wer mit drei States beginnt, sauber testet und erst dann erweitert, hat ein System, das sich anpassen lässt, ohne von Grund auf neu gebaut werden zu müssen. Als nächsten Schritt lohnt es sich, die Automationen in ActiveCampaign so aufzubauen, dass State-Übergänge, Inhalts-Steuerung und Decay-Logik sauber voneinander getrennt laufen – das macht jede spätere Anpassung wesentlich einfacher.