Angebotsdaten vs. Reservierungsdaten: Worauf Dein Preis-Tool wirklich rechnet

Zwei Preise für dieselbe Nacht – und beide können stimmen

Du suchst heute eine Ferienwohnung für den 20. August: zwei Erwachsene, drei Nächte, mobil, ohne Login. Das Portal zeigt 179 Euro pro Nacht. Im PMS steht für dieselbe Anreise eine Reservierung über 510 Euro. Ist eine Zahl falsch?

Nicht unbedingt. Die 179 Euro sind ein Angebot in einer bestimmten Suchsituation. Die 510 Euro sind ein Reservierungswert mit eigener Belegung, Aufenthaltsdauer, Rate, Steuer- und Gebührenlogik. Vielleicht umfasst er drei Nächte, vielleicht ist eine Endreinigung enthalten, vielleicht wurde die Buchung später geändert. Ohne gemeinsame Einheit vergleichst Du eine Momentaufnahme mit einem Geschäftsvorgang.

Genau hier entsteht ein blinder Fleck vieler Revenue-Dashboards. Eine saubere Oberfläche kann sehr unterschiedliche Datenarten nebeneinanderstellen. Was ein konkretes Preis-Tool davon tatsächlich als Eingang, Zielgröße oder Kontrollsignal nutzt, lässt sich nur aus seiner Dokumentation und Deinem Datenfluss beantworten.

Was Angebotsdaten wirklich zeigen

Angebotsdaten entstehen durch Such- oder Shopping-Abfragen: Welche Unterkunft ist für bestimmte Daten, Gäste, Zimmer, Aufenthaltsdauer und Verkaufskonditionen buchbar – und zu welchem angezeigten Preis? Die Booking.com Demand API verlangt unter anderem Check-in, Check-out, Gäste und Angaben zum Buchenden. Land, Plattform, Nutzergruppe und Reisezweck können die zurückgegebenen Produkte und Preise mitbestimmen. Das macht deutlich: Es gibt nicht den einen öffentlichen Marktpreis unabhängig von der Abfrage.

Ein Snapshot kann enthalten:

• sichtbare Rate oder Gesamtpreis,
• verfügbare Produkte beziehungsweise Einheiten,
• Mindestaufenthalt und andere Buchungsbedingungen,
• Belegung und Zimmer- oder Unterkunftstyp,
• Stornierbarkeit, Zahlungszeitpunkt und Verpflegung,
• Steuern, Gebühren, Rabatte oder Nutzerkonditionen,
• Kanal, Währung und Abrufzeitpunkt.

Die Expedia Shopping API beschreibt ihre Antwort ausdrücklich als aktuelle Raten und Verfügbarkeit für die angefragten Unterkünfte. Vor der Buchung gibt es einen weiteren Price Check, weil sich Preis oder Verfügbarkeit zwischen Suche und Abschluss ändern können. Ein Snapshot ist deshalb zeitgebunden, nicht historisch wahr.

Was ein fehlendes Angebot nicht beweist

„Nicht verfügbar“ bedeutet nicht automatisch „verkauft“. Die Anfrage kann an Mindestaufenthalt, Anreisetag, Gästezahl, Rate-Plan, Vertriebseinstellung oder technischer Übermittlung scheitern. Selbst die Expedia-Schnittstelle kennt unterschiedliche Gründe für Nichtverfügbarkeit und weist darauf hin, dass nicht immer ein handlungsfähiger Grund geliefert wird.

Damit ist auch die Umkehrung gefährlich: Aus wenigen sichtbaren Einheiten folgt keine belastbare Restkapazität des gesamten Betriebs. Der Snapshot beschreibt das Ergebnis einer Anfrage in einem Vertriebskontext. Er zeigt weder sicher belegte Nächte noch Nachfrage, die gesucht, aber nicht gebucht hat.

Was Reservierungsdaten wirklich zeigen

Reservierungsdaten entstehen, wenn ein Buchungsvorgang angelegt und über seinen Lebenszyklus fortgeschrieben wird. Booking.com definiert eine Reservierung als Buchung einer oder mehrerer Zimmernächte und unterscheidet in seiner Reservations API neue, geänderte und stornierte Reservierungsnachrichten. Schon diese drei Zustände zeigen: „gebucht“ ist kein unveränderlicher Endpunkt.

Für Revenue Management sind mindestens folgende Felder relevant, sofern sie im eigenen System vorhanden und korrekt gepflegt sind:

• Buchungs-, Anreise- und Abreisedatum,
• gebuchte Einheit oder Kategorie und Anzahl Nächte,
• Status sowie Zeitpunkte von Änderung und Storno,
• gebuchter Logispreis und dessen nächtliche Verteilung,
• Rabatte, Pakete, Steuern und Gebühren,
• Vertriebskanal und Rate-Plan,
• Kapazität, Sperren und gegebenenfalls No-show.

Reservierungsdaten können On the Books zeigen: den aktuell vorhandenen Bestand künftiger Buchungen. Für tatsächlich realisierte Nachfrage reichen sie erst nach Aufenthalt, Storno- und No-show-Verarbeitung. Eine heute bestätigte Buchung für Dezember kann bis zur Anreise verändert oder storniert werden.

Stornos verändern nicht nur die Auslastung

Ein Storno nimmt künftige belegte Nächte aus dem Buchungsbestand. Je nach Frist und Kondition kann aber Stornoerlös verbleiben. Deshalb sind Zimmernächte, Logisumsatz und Zahlung drei getrennte Größen. Löschst Du stornierte Reservierungen statt Status und Historie zu bewahren, überschätzt Du frühere Netto-Nachfrage oder kannst Pickup nicht mehr rekonstruieren. Zählst Du sie weiter als belegt, überschätzt Du die aktuelle Auslastung.

Auch Änderungen brauchen Ereigniszeitpunkte. Verkürzt ein Gast fünf Nächte auf drei, sind zwei Nächte wieder verkaufbar; der Buchungswert und möglicherweise der Durchschnittspreis verändern sich. Ein bloßer Export des heutigen Endstands zeigt nicht, wann diese Bewegung stattgefunden hat.

Die typischen Verzerrungen beider Datenwelten

Welche Frage die Daten beantworten – und welche nicht

Datenart	Gut geeignet für	Typische Verzerrung
Angebotssnapshot	Sichtbare Positionierung für definierte Suchkriterien	Nur ein Zeitpunkt, Kanal, Aufenthaltsmuster und Nutzerkontext
Reservierung On the Books	Aktueller künftiger Buchungsbestand	Spätere Stornos, Änderungen und No-shows sind noch offen
Realisierter Aufenthalt	Rückblick auf belegte Nächte und verbuchten Logisumsatz	Zeigt nicht die damals sichtbaren Alternativen oder verlorene Nachfrage

Angebotsdaten haben einen Auswahl-Bias: Du beobachtest nur die Betriebe und Produkte, die in Deiner Abfrage erscheinen. Geschlossene, nicht passende oder ausverkaufte Angebote fehlen. Außerdem kann ein Tool bei täglichem Abruf kurze Preisänderungen übersehen.

Reservierungsdaten haben einen Bestands-Bias: Sie zeigen Käufer, nicht alle Suchenden. Nicht abgeschlossene Suchen, telefonische Anfragen oder Nachfrage oberhalb Deiner Kapazität fehlen meistens. Fehlerhafte Kanalzuordnung, Duplikate, Testbuchungen, Eigentümerblöcke und uneinheitliche Statuswerte können den Bestand zusätzlich verzerren.

Keiner der Datensätze ist „besser“. Sie beantworten andere Fragen.

Steuern und Gebühren: Erst die Preisbasis festlegen

Ein Vergleich von 150 Euro mit 165 Euro ist wertlos, wenn die erste Zahl nur Logis und die zweite Endreinigung, Umsatzsteuer oder Ortstaxe enthält. Die Booking.com-Dokumentation zur Verfügbarkeitsantwort unterscheidet Basis-, Anzeige- und Gesamtpreis sowie einzelne Charges. Einige Details werden nur angefordert, wenn die Abfrage zusätzliche Gebühren einschließt. Auch Expedia trennt in der Shopping-API-Dokumentation Basisrate, Steuern, Service- und vor Ort erhobene Gebühren; die Integrationsanforderungen für den Buchungsablauf behandeln Gesamtpreis und separat vor Ort fällige Beträge, die zum Buchungszeitpunkt teilweise variabel sein können.

Lege deshalb vor jedem Vergleich fest:

1. Einheit: pro Nacht, pro Aufenthalt oder pro belegter Einheit?
2. Belegung: für wie viele Erwachsene und Kinder?
3. Umfang: reine Logisrate oder gastseitiger Gesamtpreis?
4. Steuern: enthalten, ausgeschlossen oder separat ausgewiesen?
5. Gebühren: verpflichtend, optional, einmalig oder pro Nacht?
6. Kondition: stornierbar, nicht stornierbar, mit oder ohne Verpflegung?
7. Währung und Zeitpunkt: welcher Kurs und welcher Abruf?

Für Deine Ertragsrechnung brauchst Du zusätzlich eine interne Erlösdefinition. Gastseitiger Gesamtpreis, vereinnahmter Betrag und anrechenbarer Logisumsatz sind nicht automatisch identisch.

Occupancy und Pickup brauchen Stichtage

Auslastung klingt eindeutig, hängt aber am Nenner. Eurostat definiert die Netto-Zimmerauslastung als genutzte Zimmer geteilt durch verfügbare Zimmer, wobei saisonale und andere vorübergehende Schließungen aus der verfügbaren Kapazität herausgerechnet werden. Die offizielle Definition zeigt, warum Du Sperren und Schließungen nicht stillschweigend unterschiedlich behandeln darfst.

Für die operative Vorschau kannst Du rechnen:

On-the-books-Auslastung = aktuell reservierte, nicht stornierte Einheiten-Nächte ÷ definierte verkaufbare Einheiten-Nächte.

Das ist eine Vorschau, keine realisierte Auslastung. Dokumentiere, ob Wartung, Eigennutzung und Vertriebssperren den Nenner reduzieren oder als unverkaufte Kapazität stehen bleiben.

Pickup ist die Veränderung dieses Buchungsbestands zwischen zwei Stichtagen für denselben Aufenthaltszeitraum. Oracle beschreibt seinen Reservation Booking Pace Report als Vergleich der Reservierungen „on the books“ an bestimmten Tagen. Netto-Pickup enthält damit neue Buchungen, Stornos und Änderungen. Ohne tägliche historische Snapshots des Reservierungsbestands kannst Du den früheren Stand nicht verlässlich aus dem heutigen Endbestand zurückrechnen.

Markt und Compset: Vergleichbar ist nicht gleich vollständig

Ein Competitive Set hilft nur, wenn die Objekte für die jeweilige Entscheidung vergleichbar sind. Lage allein genügt nicht. Kapazität, Unterkunftstyp, Qualitätsniveau, Ausstattung, Zielgruppe, Stornobedingung und Aufenthaltsmuster können die sichtbare Rate erklären.

Drei Grenzen solltest Du im Dashboard offen benennen:

• Abdeckung: Welche Kanäle, Betriebe, Zimmerarten und Daten sind überhaupt enthalten?
• Suchdesign: Welche Aufenthaltsdauer, Belegung, Vorlaufzeit und Nutzerkondition wird abgefragt?
• Survivorship: Nicht sichtbare Angebote verschwinden aus dem Vergleich, obwohl der Grund unbekannt ist.

Ein Marktmedian aus sichtbaren Angeboten ist daher kein Beleg für tatsächlich gebuchte Markt-ADR oder Marktauslastung. Er kann eine nützliche Preispositions-Kennzahl sein – wenn Abfrage und Stichprobe konstant bleiben. Ob und wie ein konkreter Anbieter Compsets bildet, fehlende Werte behandelt oder Markt- und Reservierungsdaten gewichtet, bleibt ohne Methodendokumentation offen.

So gleichst Du beide Welten ab

Ein belastbarer Prozess beginnt nicht beim Algorithmus, sondern bei einem Datenvertrag.

1. Gemeinsamen Schlüssel definieren

Ordne Datum, Objekt, Einheitentyp, Rate-Plan, Belegung, Aufenthaltsdauer, Kanal, Währung und Preisbasis eindeutig zu. Ohne diese Dimensionen gibt es keinen fairen Vergleich.

2. Rohdaten und bereinigte Kennzahl trennen

Bewahre Abrufzeit, ursprünglichen Angebotswert, Reservierungsstatus und Änderungen. Bereinigungen – etwa Testbuchungen ausschließen oder Gebühren aus dem Gesamtpreis lösen – gehören in dokumentierte Regeln, nicht in manuelle Tabellenkorrekturen.

3. Drei Kontrollansichten führen

Vergleiche täglich:

• Angebotsrate und buchbaren Status aus definierten Suchfällen,
• Reservierungen On the Books samt Veränderung seit dem letzten Stichtag,
• nach Aufenthalt realisierte Zimmernächte und Logisumsatz.

Abweichungen sind nicht automatisch Fehler. Sie sind Prüfhinweise: Mapping geändert? Rate geschlossen? Storno verspätet verarbeitet? Gebühr doppelt enthalten? Kapazität gesperrt?

4. Reconciliation messbar machen

Prüfe Reservierungsanzahl, Einheiten-Nächte und Logisumsatz je Status und Aufenthaltstag zwischen PMS, Channel Manager und Analyse. Halte Zeitzone, Aktualisierungslatenz und Währung fest. Für Angebotssnapshots protokollierst Du erfolgreiche, leere und fehlgeschlagene Abrufe getrennt. „Keine Rate“ darf nicht mit einem technischen Fehler zu null Euro werden.

5. Tool-Anbieter konkret fragen

Lass Dir schriftlich beantworten:

• Welche eigenen Reservierungsfelder werden importiert?
• Werden Änderungen, Stornos und No-shows historisiert?
• Welche Angebotsquellen und Suchkonstellationen werden beobachtet?
• Wie werden Steuern, Gebühren, Währungen und Aufenthaltslängen normalisiert?
• Was passiert bei fehlenden, veralteten oder widersprüchlichen Daten?
• Kannst Du Rohwert, Aktualisierungszeit und Herkunft einer Empfehlung prüfen?

Erst diese Antworten sagen Dir, worauf Dein Preis-Tool wirklich rechnet. Ein Anbieter kann Angebotsdaten, Reservierungsdaten, beides oder weitere Signale verwenden. Ohne belegte Schnittstellenbeschreibung solltest Du keine dieser Varianten unterstellen.

Die praktische Konsequenz

Angebotsdaten beantworten: „Was war für diese Suche zu diesem Zeitpunkt sichtbar und buchbar?“ Reservierungsdaten beantworten: „Was wurde gebucht und welchen Status hat es jetzt?“ Historisierte Reservierungsstände beantworten: „Wie hat sich der Bestand entwickelt?“ Realisierte Aufenthalte beantworten: „Was blieb am Ende übrig?“

Wenn Du diese Ebenen trennst, werden Preisempfehlungen nicht automatisch richtig. Aber Du erkennst, welche Aussage sie tragen kann, wo Bias entsteht und welche Zahl Du vor einer Preisänderung prüfen musst. Genau diese Nachvollziehbarkeit ist die Grundlage für Revenue Management – nicht die Zahl allein.