Drei Profile behaupten dasselbe. Wie Hotelsysteme herausfinden, wer eigentlich wer ist.
Hotelsoftware · Guide · 11 min Lesezeit Anna Becker kommt wieder.
Eigentlich eine gute Nachricht.
Sie war vor zwei Jahren schon einmal da. Damals über Booking.com. Dieses Mal bucht sie direkt auf der Hotelwebsite. Beim ersten Aufenthalt hat sie ihre private E-Mail-Adresse angegeben, heute die geschäftliche.
An der Rezeption wird ihr Profil gesucht.
Und gefunden.
Sogar dreimal.
Anna Becker mit privater E-Mail-Adresse.
Anna Becker mit geschäftlicher E-Mail-Adresse.
Anna Becker mit einer weiteren Kontaktadresse aus einer früheren Buchung.
Drei Profile. Drei Aufenthaltshistorien. Ein Mensch.
Und alle drei behaupten: Ich bin Anna Becker.
Anna selbst hat kein Identitätsproblem.
Das PMS schon.
Was nach einem kleinen Schönheitsfehler in der Datenbank klingt, zieht sich weiter: Der Stammgast sieht im Reporting möglicherweise aus wie drei Erstgäste. Aufenthalte und Umsätze verteilen sich auf unterschiedliche Profile. Das CRM segmentiert auf Basis unvollständiger Informationen. Und beim nächsten Aufenthalt wird Anna womöglich behandelt, als wäre sie zum ersten Mal da.
Das Problem wird größer, sobald neben dem PMS weitere Systeme ins Spiel kommen. Booking Engine, CRM, POS, Spa, Loyalty, Newsletter. Überall entstehen Daten. Und überall muss entschieden werden:
Ist das derselbe Mensch – oder nur jemand, der zufällig genauso heißt?
Genau darum geht es bei Guest Identity und Identity Resolution.
Also um eine ziemlich menschliche Frage für ein ziemlich technisches Problem:
Wer ist eigentlich wer?
Guest Identity bezeichnet die eindeutige Identität eines Gastes über unterschiedliche Buchungen, Aufenthalte, Systeme und Kontaktpunkte hinweg.
Identity Resolution ist der Prozess dahinter: Unterschiedliche Datensätze werden geprüft und – wenn sie tatsächlich zur selben Person gehören – miteinander verknüpft oder zu einem einheitlichen Profil zusammengeführt.
Das klingt zunächst nach Dublettenbereinigung.
Ist aber mehr.
Denn es geht nicht nur darum, zweimal vorhandene Namen zu löschen.
Ein Gast kann im PMS als Anna Becker stehen, in der Booking Engine als A. Becker, im CRM mit einer anderen E-Mail-Adresse und im Loyalty-System mit einer eigenen Mitgliedsnummer.
Die Datensätze sind nicht identisch.
Die Person schon.
Identity Resolution versucht genau diesen Zusammenhang herzustellen.
Moderne Systeme arbeiten dafür mit verschiedenen Identifikatoren und Matching-Regeln. Oracle beschreibt Identity Resolution beispielsweise als einen Prozess, bei dem Datensätze aus unterschiedlichen Quellen anhand von Merkmalen wie E-Mail-Adresse, Telefonnummer, Name oder Kunden-ID abgeglichen und anschließend einem gemeinsamen Masterprofil zugeordnet werden.
Vereinfacht:
Guest Identity beantwortet die Frage „Wer ist der Gast?“
Identity Resolution beantwortet die Frage „Welche Datensätze gehören zu diesem Gast?“
Kleine sprachliche Differenz.
Großer Unterschied für die Datenbank.
Die kurze Antwort:
Weil Menschen keine Kundennummern sind.
Zum Glück.
Die etwas längere Antwort beginnt beim Buchungsprozess.
Anna bucht ihren ersten Aufenthalt mit: anna.becker@privat.de
Den nächsten: a.becker@firma.de
Später vielleicht über eine OTA mit einer vom Vermittler bereitgestellten Kontaktadresse.
Wenn ein System die E-Mail-Adresse als wichtiges Merkmal zur Identifikation verwendet und keinen ausreichend guten Zusammenhang zu einem vorhandenen Profil erkennt, kann ein neuer Datensatz entstehen.
Aus: anna.becker@email.de
wird: anna.bekcer@email.de
Menschen erkennen das. Datenbanken zunächst einmal nicht zwingend.
Dasselbe gilt für:
Anna Becker
A. Becker
Dr. Anna Becker
Anna Maria Becker
Anna Becker-Schmidt
Vielleicht dieselbe Person.
Vielleicht nicht.
Direktbuchung.
OTA.
Telefon.
Reisebüro.
Firmenbuchung.
Gruppenreservierung.
Jeder Buchungsweg kann Daten anders erfassen, formatieren oder an das PMS übertragen.
Wie solche Daten zwischen Hotelsystemen transportiert werden, erklären wir ausführlicher in unserem Beitrag „Schnittstellen im Hotel“.
Denn selbst wenn eine Schnittstelle technisch tadellos funktioniert, kann sie einen neuen Datensatz tadellos übertragen.
Technisch korrekt ist nicht automatisch datenlogisch richtig.
Im Grundlagenartikel zu Gästedaten im Hotel haben wir genau dieses Problem beschrieben:
PMS, Booking Engine, CRM, POS, Newsletter und weitere Systeme besitzen jeweils nur Ausschnitte der Gästebeziehung.
Das PMS kennt den Aufenthalt.
Das Restaurant den Tisch.
Das CRM die Kommunikation.
Die Booking Engine die Direktbuchung.
Und plötzlich existiert nicht nur innerhalb eines Systems mehr als ein Profil.
Sondern über die gesamte Systemlandschaft verteilt ein kleines Rudel davon.
Nun könnte man sagen:
Na gut. Dann steht Anna eben dreimal im PMS.
Sie bekommt deshalb ja nicht dreimal Frühstück.
Das stimmt.
Das eigentliche Problem taucht an anderen Stellen auf.
Angenommen, Anna hat dreimal im Hotel übernachtet.
Die Aufenthalte liegen aber auf drei unterschiedlichen Profilen.
Dann kann ein Reporting statt: 1 Gast · 3 Aufenthalte
unter Umständen sinngemäß sehen: 3 Gäste · jeweils 1 Aufenthalt
Damit verändern sich Kennzahlen und Analysen rund um Wiederkehrer, Gästebindung oder Kundenwert. Die Daten sind einzeln nicht unbedingt falsch.
Der Zusammenhang fehlt.
Und genau das macht schlechte Daten so unangenehm. Sie sehen oft ziemlich korrekt aus.
Zimmerumsatz auf Profil A.
Restaurantumsatz auf Profil B.
Spa auf Profil C.
Wer den Wert eines Gastes über die gesamte Beziehung zum Hotel verstehen möchte, bekommt so nur Teilbilder.
Aus einer möglicherweise sehr wertvollen Stammkundin werden drei mittelmäßig interessante Datensätze.
„Schön, Sie zum ersten Mal bei uns begrüßen zu dürfen.“
Beim vierten Aufenthalt.
Charmant 🫠
Doppelte oder fragmentierte Profile können dazu führen, dass Präferenzen, frühere Aufenthalte oder Kommunikationshistorien fehlen.
Das betrifft nicht nur Marketing.
Auch Front Office, Reservierung oder Guest Relations arbeiten dann mit einem unvollständigen Bild.
In der 2025 veröffentlichten Branchenbefragung The Future of Hotel Data von Revinate und Hapi gaben 49 % der befragten Hotelfachleute an, Schwierigkeiten beim Zugriff auf Daten für wichtige Umsatz- und operative Entscheidungen zu haben. 40 % nannten getrennte Systeme als größtes Datenhindernis; 8,38 % explizit doppelte Daten.
Das Interessante daran:
Dubletten sind nur ein Teil des Problems. Der größere Gegner ist die Fragmentierung insgesamt.
Anna muss also nicht nur innerhalb des PMS wiedererkannt werden. Im Idealfall muss das Hotel verstehen, dass Anna im PMS, Anna im CRM und Anna im Restaurant dieselbe Anna sind.
Wie bringt man die Annas dieser Welt wieder zusammen?
Mit Matching.
Dabei werden Merkmale verschiedener Datensätze miteinander verglichen.
Zum Beispiel:
Entscheidend ist, wie eindeutig die Übereinstimmung ist.
Beim deterministischen Matching werden klar definierte Merkmale oder Kombinationen davon verglichen.
Zum Beispiel:
gleiche Loyalty-ID
oder:
gleiche E-Mail-Adresse + gleiche Telefonnummer
Treffen die festgelegten Regeln zu, werden Datensätze als zusammengehörig erkannt.
Das ist vergleichsweise streng.
Und damit kommen wir zum Problem.
Menschen halten sich nicht besonders gern an Datenmodelle.
Schon wird aus „eindeutig“ ziemlich schnell „wahrscheinlich“.
Hier können mehrere Merkmale gemeinsam bewertet werden.
Beispielsweise:
Die Kombination kann stark darauf hindeuten, dass beide Profile zur selben Person gehören.
Moderne Plattformen kombinieren dafür regelbasierte und teilweise probabilistische Verfahren. Oracle beschreibt für seine Datenplattform beispielsweise deterministische und probabilistische Matching-Verfahren; andere Hospitality-Plattformen arbeiten ebenfalls mit automatisierten Deduplizierungs- und Matching-Logiken.
Die Grundidee bleibt unabhängig vom Produkt dieselbe:
Nicht ein einzelnes Feld entscheidet. Der Zusammenhang entscheidet.
Jetzt könnte man die Matching-Regeln einfach etwas großzügiger einstellen.
Problem gelöst.
Leider nein.
Nehmen wir: Thomas Müller.
Gleicher Name. Gleiche Stadt. Vielleicht sogar dasselbe Geburtsjahr.
Zusammenführen?
Bitte nicht vorschnell.
Denn Identity Resolution hat zwei mögliche Fehler:
False Negative: Zwei Profile gehören zur selben Person, werden aber nicht zusammengeführt.
False Positive: Zwei unterschiedliche Personen werden fälschlicherweise zu einem Profil gemacht.
Der zweite Fehler kann deutlich unangenehmer werden.
Plötzlich landet die Aufenthaltshistorie des einen Gastes beim anderen.
Präferenzen werden falsch zugeordnet.
Oder Informationen werden einer Person angezeigt, zu der sie gar nicht gehören.
Deshalb braucht Identity Resolution nicht möglichst viele Zusammenführungen.
Sie braucht möglichst zuverlässige Zusammenführungen.
Das ist ein wichtiger Unterschied.
Wie vorsichtig aktuelle Systeme damit umgehen, zeigt ein konkretes Beispiel.
Cloudbeds dokumentiert seit 2026 eine automatische Deduplizierung von Gästeprofilen. Das System bewertet mögliche Übereinstimmungen und führt Profile bei einem hohen Konfidenzniveau automatisch zusammen; laut aktueller Dokumentation liegt diese Schwelle bei 90 % oder höher. Daneben gibt es weiterhin einen manuellen Merge-Prozess.
Oracle OPERA Cloud Loyalty verfolgt ebenfalls einen Match-and-Merge-Ansatz: Hotels können Regeln definieren und potenzielle Dubletten entweder manuell prüfen oder bestimmte Übereinstimmungen automatisch zusammenführen lassen.
Das sind keine universellen Branchenstandards.
Und 90 % sind schon gar keine magische Zahl, die jedes Hotel irgendwo einstellen sollte.
Die Beispiele zeigen aber gut, wohin sich die Technik entwickelt:
Automatisieren, wenn die Übereinstimmung sehr sicher ist.
Prüfen, wenn sie es nicht ist.
Denn auch die cleverste Matching-Logik sollte im Zweifelsfall sagen dürfen:
Keine Ahnung.
Für Software ist das manchmal die intelligenteste Antwort.
Eine naheliegende Frage lautet:
Muss das PMS das alles lösen?
Nein.
Das PMS ist zwar häufig eine zentrale Quelle für Gäste- und Aufenthaltsdaten. Wie ein Property Management System grundsätzlich arbeitet, haben wir separat erklärt.
Aber Guest Identity wird spätestens dann größer als das PMS, wenn Daten aus mehreren Systemen zusammenkommen.
Ein PMS kann möglicherweise doppelte Profile innerhalb seines eigenen Datenbestands erkennen und zusammenführen.
Es kennt deshalb aber nicht automatisch jede Interaktion aus jedem anderen System.
Je komplexer die Systemlandschaft wird, desto wichtiger wird deshalb die Frage:
Wo soll die übergreifende Gastidentität geführt werden?
Das kann je nach Architektur beispielsweise ein CRM, eine Customer Data Platform oder eine andere zentrale Datenebene übernehmen.
Eine pauschale Antwort gibt es nicht.
Und genau deshalb wäre: „Wir haben Dubletten. Wir brauchen eine CDP.“ etwas voreilig.
Vielleicht.
Vielleicht auch nicht.
Ob CRM oder CDP für welche Aufgabe sinnvoll ist, behandeln wir deshalb separat im Clusterartikel „CRM oder CDP: Was braucht ein Hotel wirklich?“
Guest Identity klingt schnell nach großem Datenprojekt.
Der erste Schritt ist wesentlich banaler.
Gut, vielleicht nicht nach dem eigenen.
Aber nach Stammgästen.
Ein paar reale Fälle sagen oft mehr als eine 40-seitige Systemdokumentation.
Wer diese Regeln nicht kennt, kann die Qualität der Gästedaten kaum beurteilen.
Kann das PMS mögliche Dubletten erkennen?
Automatisch?
Manuell?
Nach welchen Kriterien?
Was passiert beim Zusammenführen mit:
Ein Merge-Button ist schnell gedrückt.
Die interessantere Frage lautet, was danach mit den Daten passiert.
Woher kommen die doppelten Profile?
Aus manueller Eingabe?
OTA?
Booking Engine?
CRM?
Migration?
Schnittstelle?
Wenn dieselbe Ursache täglich neue Dubletten produziert, ist monatliches Aufräumen ungefähr so effizient wie Wischen bei offenem Dach.
Erst Ursache.
Dann Putzlappen.
Wer kümmert sich eigentlich um Datenqualität?
Front Office?
Reservierung?
Marketing?
IT?
Niemand so richtig?
Dann ist das möglicherweise bereits Teil des Problems.
Guest Identity ist kein einmaliges Bereinigungsprojekt.
Neue Daten kommen permanent hinzu.
Deshalb braucht es Regeln dafür, wie Profile angelegt, geprüft, zusammengeführt und zwischen Systemen synchronisiert werden.
Das gehört zum Datenmanagement im Hotel – und damit zur Systemarchitektur, nicht nur zur Datenpflege an der Rezeption.
Bis hierhin wissen wir:
Anna Becker ist Anna Becker.
Sehr schön.
Damit ist aber noch nicht automatisch bekannt, was Anna Becker in allen Systemen gemacht hat.
Guest Identity ist deshalb eine Voraussetzung für eine Single Customer View – aber nicht dasselbe.
Guest Identity sagt:
Diese Datensätze gehören zu Anna.
Eine Single Customer View versucht daraus anschließend ein konsistentes Gesamtbild zu machen:
Das ist Anna. Das sind ihre Aufenthalte. Das sind ihre relevanten Umsätze. Das sind ihre Interaktionen. Das sind ihre Präferenzen.
Oder noch kürzer:
Identity Resolution erkennt die Person.
Die Single Customer View setzt ihre Daten zusammen.
Das ist der nächste logische Schritt unseres Gästedaten-Clusters. Denn erst wenn klar ist, wer ein Gast ist, lohnt sich die Frage, was das Hotel über ihn weiß.
Ein Gast wird nicht zu drei Menschen, nur weil er dreimal anders bucht. Für Hotelsysteme kann genau das trotzdem passieren.
Andere E-Mail-Adresse.
Anderer Buchungskanal.
Tippfehler.
Neuer Nachname.
Weitere Systeme.
Und schon verteilt sich eine Gästebeziehung über mehrere Profile.
Guest Identity löst dieses Problem nicht dadurch, dass möglichst aggressiv Datensätze zusammengeschoben werden. Sondern dadurch, dass Zusammenhänge zuverlässig erkannt werden.
Das ist wichtig für saubere Aufenthaltshistorien. Für Reporting. Für Segmentierung. Für Personalisierung. Für CRM. Für Loyalty. Und letztlich für jede Anwendung, die behauptet, einen Gast zu kennen.
Denn bevor Hotels über 360-Grad-Profile, KI und hyperpersonalisierte Guest Journeys sprechen, wäre eine wesentlich simplere Frage ganz hilfreich:
Wissen die Systeme überhaupt, welche Anna Anna ist?
Wenn nicht, fangen wir dort an.