Conjoint

Du möchtest herausfinden, welches Hotel Gäste bevorzugen.

Also fragst du zunächst nach einzelnen Eigenschaften.

Wie wichtig ist Ihnen eine gute Lage? 9 von 10. Ein gutes Frühstück? 8 von 10. Ein günstiger Preis? 9 von 10. Kostenlose Stornierung? 9 von 10.

Das Ergebnis überrascht wenig: Fast alles ist wichtig.

Nur hilft uns diese Erkenntnis noch nicht besonders weit, wenn ein Gast tatsächlich ein Hotel buchen muss.

Denn in der Realität bucht niemand eine gute Lage, ein Frühstück oder einen günstigen Preis einzeln.

Man entscheidet sich für ein Gesamtangebot.

Und bei diesem Gesamtangebot bekommt man selten alles gleichzeitig.

Dann entscheide dich

Stellen wir unserem Gast zwei Hotelangebote gegenüber.

Welches Angebot würden Sie buchen?

Wer Angebot A auswählt, bekommt die bessere Lage und das Frühstück inklusive, zahlt dafür aber mehr und verzichtet auf kostenlose Stornierung.

Wer Angebot B auswählt, spart 30 Euro und kann kostenlos stornieren, muss dafür aber weiter zum Strand laufen und zusätzlich für das Frühstück bezahlen.

Der Gast kann nicht mehr einfach sagen, dass ihm alles wichtig ist.

Er muss abwägen.

Er muss einen Trade-off eingehen.

Genau an dieser Stelle wird Conjoint interessant.

Es gibt unterschiedliche Conjoint-Verfahren. Im Folgenden geht es um eine besonders verbreitete Variante: Choice-Based Conjoint. Dabei entscheiden sich Teilnehmer wiederholt zwischen vollständigen Angeboten.

Nicht die Eigenschaft, sondern die Kombination

Bei einer klassischen Wichtigkeitsfrage betrachten wir jede Eigenschaft einzeln:

Wie wichtig ist die Lage?
9 von 10

Wie wichtig ist der Preis?
9 von 10

Wie wichtig ist kostenlose Stornierung?
9 von 10

Das kann vollkommen sinnvoll sein.

Wir wissen danach, dass dem Gast alle drei Dinge wichtig sind.

Was wir nicht wissen:

Wie viel schlechter darf die Lage werden, wenn das Hotel dafür günstiger ist?

Oder:

Ist kostenlose Stornierung noch wichtig genug, wenn sie 30 Euro mehr kostet?

Oder:

Kann ein günstigerer Preis ein nicht enthaltenes Frühstück ausgleichen?

Solche Entscheidungen entstehen erst, wenn Eigenschaften gemeinsam auftreten und gegeneinander abgewogen werden müssen.

Conjoint untersucht deshalb Entscheidungen zwischen Kombinationen von Eigenschaften.

Attribute und Levels

Dafür brauchen wir zwei Begriffe.

Die Eigenschaften, die wir systematisch verändern, werden im Conjoint häufig Attribute genannt.

Für unser Hotel könnten das sein:

Lage
Frühstück
Stornierung
Preis

Jedes Attribut kann verschiedene Ausprägungen haben.

Diese Ausprägungen heißen Levels.

Zum Beispiel:

Attribut: Lage

direkt am Strand
500 m zum Strand
2 km zum Strand

Oder:

Attribut: Frühstück

inklusive
12 €
20 €

Beim Preis:

129 €
149 €
179 €

Wir haben damit noch kein konkretes Angebot beschrieben.

Wir haben zunächst nur festgelegt, welche Eigenschaften wir untersuchen und welche Ausprägungen diese annehmen können.

Aus Levels werden Angebote

Nun kombinieren wir jeweils ein Level aus jedem Attribut.

Zum Beispiel:

Angebot A

Lage           direkt am Strand
Frühstück      inklusive
Stornierung    nicht kostenlos
Preis          179 €

Ein anderes Angebot könnte so aussehen:

Angebot B

Lage           500 m zum Strand
Frühstück      12 €
Stornierung    kostenlos
Preis          149 €

Und ein drittes:

Angebot C

Lage           2 km zum Strand
Frühstück      inklusive
Stornierung    kostenlos
Preis          129 €

Eine solche konkrete Kombination von Levels wird häufig als Profil bezeichnet.

Sobald mehrere solcher Profile innerhalb einer Aufgabe gegeneinander antreten, sind sie die Alternativen, zwischen denen sich der Teilnehmer entscheidet.

Der Teilnehmer wählt also nicht einzelne Levels aus.

Er entscheidet sich für ein vollständiges Angebot.

Die Choice Task

Zeigen wir drei solcher Alternativen gleichzeitig:

Die Aufgabe lautet:

Welches dieser Angebote würden Sie buchen?

Eine solche Entscheidungssituation wird beim Choice-Based Conjoint häufig als Choice Task bezeichnet.

Die Choice Task besteht also aus mehreren Alternativen:

Choice Task

├── Angebot A
│   ├── Lage = direkt am Strand
│   ├── Frühstück = inklusive
│   ├── Stornierung = nicht kostenlos
│   └── Preis = 179 €
│
├── Angebot B
│   ├── Lage = 500 m
│   ├── Frühstück = 12 €
│   ├── Stornierung = kostenlos
│   └── Preis = 149 €
│
└── Angebot C
    ├── Lage = 2 km
    ├── Frühstück = inklusive
    ├── Stornierung = kostenlos
    └── Preis = 129 €

Der Teilnehmer wählt eine der Alternativen.

Manchmal gibt es zusätzlich eine Möglichkeit wie:

Keines dieser Angebote.

Damit kann berücksichtigt werden, dass ein Gast in der Realität möglicherweise keines der dargestellten Angebote wählen würde.

Eine Entscheidung reicht nicht

Angenommen, unser Gast wählt Angebot B.

Was haben wir daraus gelernt?

Offenbar war B in dieser konkreten Situation attraktiver als A und C.

Aber warum?

Vielleicht wegen des Preises.

Vielleicht wegen der kostenlosen Stornierung.

Vielleicht war ihm die Lage von 500 Metern nah genug.

Vielleicht fand er A zwar attraktiver, wollte aber keine 179 Euro bezahlen.

Aus einer einzigen Entscheidung können wir diese Effekte kaum auseinanderhalten.

Deshalb besteht eine Choice-Based-Conjoint-Untersuchung aus mehreren Choice Tasks.

Zum Beispiel:

Task 1
A · B · C
→ B

Task 2
A · B · C
→ A

Task 3
A · B · C
→ C

Task 4
A · B · C
→ B

...

In jeder Task werden andere Kombinationen gezeigt.

Dadurch tritt beispielsweise:

direkt am Strand

einmal gemeinsam mit einem hohen Preis auf, ein anderes Mal mit einem niedrigeren.

Kostenlose Stornierung erscheint mal bei einem günstigen Angebot und mal bei einem teuren.

Frühstück inklusive wird mit unterschiedlichen Lagen kombiniert.

Über viele solcher Entscheidungen entsteht nach und nach Information darüber, welchen Beitrag die verschiedenen Levels zur Wahl eines Angebots leisten.

Warum nicht einfach die Angebote bewerten?

An dieser Stelle könnte man einwenden:

Warum dieser Aufwand?

Wir könnten doch mehrere Angebote zeigen und jedes auf einer Skala bewerten lassen.

Zum Beispiel:

Angebot A    8 von 10
Angebot B    9 von 10
Angebot C    7 von 10

Das kann vollkommen ausreichen.

Wenn unsere Frage lautet:

Welches dieser konkreten Angebote gefällt unseren Gästen am besten?

dann brauchen wir möglicherweise überhaupt kein Conjoint.

Ein klassischer Produkttest oder Concept Test kann für diese Fragestellung genau das richtige Verfahren sein.

Conjoint verfolgt aber ein anderes Ziel.

Wir möchten nicht nur wissen, welches konkrete Angebot gewinnt.

Wir möchten verstehen, welchen Beitrag einzelne Eigenschaften innerhalb der Angebote zur Entscheidung leisten.

Warum nicht einfach nach der Wichtigkeit fragen?

Auch das kann sinnvoll sein.

Wir könnten fragen:

Wie wichtig ist die Lage?
Wie wichtig ist der Preis?
Wie wichtig ist Frühstück?
Wie wichtig ist kostenlose Stornierung?

Das Problem kennen wir bereits:

Viele Eigenschaften können gleichzeitig wichtig sein.

Vor allem zwingt eine solche Frage den Teilnehmer nicht dazu, diese Eigenschaften gegeneinander abzuwägen.

Ein Gast kann problemlos sagen:

gute Lage                  10
günstiger Preis            10
Frühstück inklusive         9
kostenlose Stornierung      9

In einem echten Angebot muss er möglicherweise feststellen:

direkt am Strand
+
Frühstück inklusive
+
kostenlose Stornierung
+
günstig

gibt es nicht.

Dann muss er entscheiden, worauf er verzichten würde.

Genau dieser Trade-off ist für Conjoint entscheidend.

Und warum nicht MaxDiff?

Auch MaxDiff wäre eine Möglichkeit.

Wir könnten beispielsweise diese vier Eigenschaften zeigen:

Lage
Frühstück
Stornierung
Preis

und fragen:

Was ist Ihnen am wichtigsten und was am wenigsten wichtig?

Damit lernen wir etwas darüber, wie diese Eigenschaften relativ zueinander priorisiert werden.

Conjoint stellt jedoch eine andere Frage.

Bei MaxDiff vergleichen wir einzelne Eigenschaften miteinander:

Preis > Frühstück
Lage > Stornierung

Beim Conjoint entscheiden wir zwischen vollständigen Angeboten:

Angebot A:
gute Lage
Frühstück inklusive
teuer

gegen

Angebot B:
schlechtere Lage
Frühstück extra
günstig

Der Teilnehmer sagt also nicht unmittelbar:

Die Lage ist wichtiger als der Preis.

Er entscheidet:

Unter diesen konkreten Bedingungen würde ich Angebot B wählen.

Aus vielen solcher Entscheidungen versuchen wir anschließend abzuleiten, welchen Beitrag die einzelnen Eigenschaften zu diesen Entscheidungen geleistet haben.

MaxDiff eignet sich deshalb gut, wenn wir die relative Präferenz zwischen einzelnen Items verstehen möchten.

Conjoint wird interessant, wenn wir verstehen möchten, wie sich Kombinationen von Eigenschaften auf Entscheidungen zwischen Gesamtangeboten auswirken.

Einfach zusammenwürfeln reicht nicht

Nun könnten wir Attribute und Levels einfach unkontrolliert miteinander kombinieren.

Technisch wäre das einfach:

zufällige Lage
+
zufälliges Frühstück
+
zufällige Stornierung
+
zufälliger Preis

und davon drei Angebote nebeneinanderstellen.

Methodisch wäre das keine besonders gute Idee.

Durch Zufall könnte beispielsweise:

direkt am Strand

fast immer zusammen mit:

179 €

auftreten.

Dann wäre später schwer auseinanderzuhalten, ob die Entscheidungen durch die Lage oder den Preis beeinflusst wurden.

Oder wir erzeugen Aufgaben wie:

Angebot A:
direkt am Strand
Frühstück inklusive
kostenlose Stornierung
129 €

Angebot B:
2 km zum Strand
Frühstück 20 €
keine kostenlose Stornierung
179 €

Für viele Teilnehmer dürfte Angebot A offensichtlich attraktiver sein.

Die Entscheidung liefert dann vergleichsweise wenig neue Information.

Ein gutes Conjoint versucht deshalb, die Kombinationen so zusammenzustellen, dass die untersuchten Effekte möglichst gut voneinander zu unterscheiden sind.

An dieser Stelle brauchen wir einen weiteren Begriff:

Experimental Design.

Experimental Design

Das Experimental Design legt fest, welche Levels miteinander kombiniert werden und welche Alternativen gemeinsam in einer Choice Task erscheinen.

Dabei soll genügend Variation entstehen.

Wir möchten beispielsweise, dass:

direkt am Strand

nicht immer zusammen mit demselben Preis erscheint.

Genauso sollte:

Frühstück inklusive

nicht ausschließlich bei teuren Angeboten auftreten.

Die Zusammenstellung der Choice Tasks ist deshalb kein nebensächliches Detail der Darstellung.

Sie ist ein wesentlicher Bestandteil des Messverfahrens.

Ein schlechtes Design kann dazu führen, dass bestimmte Effekte später kaum voneinander zu trennen sind.

Eine aufwendige statistische Auswertung kann ein grundsätzlich ungeeignetes Experimental Design nicht einfach reparieren.

Nicht jede Kombination ist sinnvoll

Manchmal gibt es Kombinationen, die wir gar nicht zeigen möchten.

Angenommen:

5 Sterne
+
49 € pro Nacht

wäre für den betrachteten Markt vollkommen unrealistisch.

Oder ein bestimmtes Frühstücksangebot ist nur bei einer bestimmten Hotelkategorie verfügbar.

Dann kann das Experimental Design solche Kombinationen ausschließen.

Man spricht dabei häufig von Constraints oder verbotenen Kombinationen.

Das ist allerdings mit Vorsicht zu verwenden.

Je stärker wir den möglichen Raum einschränken, desto weniger unabhängige Variation bleibt möglicherweise übrig.

Ein Constraint sollte deshalb nicht einfach bedeuten:

Dieses Angebot gefällt uns nicht.

Sondern eher:

Dieses Angebot ist fachlich oder realistisch tatsächlich nicht sinnvoll.

Was am Ende tatsächlich gemessen wird

Nach mehreren Choice Tasks haben wir zunächst erstaunlich einfache Daten.

Zum Beispiel:

Teilnehmer | Task | Alternative | Lage   | Frühstück | Storno | Preis | gewählt
--------------------------------------------------------------------------------
4711       | 1    | A           | direkt | inklusive | nein   | 179   | nein
4711       | 1    | B           | 500 m  | 12 €      | ja     | 149   | ja
4711       | 1    | C           | 2 km   | inklusive | ja     | 129   | nein

Für Task 2 kommen drei weitere Alternativen hinzu.

Dann Task 3.

Und so weiter.

Wir speichern also zunächst keine Aussage wie:

direkt am Strand = 84
kostenlose Stornierung = 51
Frühstück inklusive = 38

Solche Werte hat uns der Teilnehmer nie genannt.

Was wir tatsächlich beobachtet haben, sind Entscheidungen:

In Task 1 wurde Alternative B gewählt.
In Task 2 wurde Alternative A gewählt.
In Task 3 wurde Alternative C gewählt.

Das sind unsere Rohdaten.

Von Entscheidungen zu Nutzenwerten

Nun beginnt die eigentliche Auswertung.

Wir suchen ein Modell, das die beobachteten Entscheidungen möglichst gut erklären kann.

Dabei wird häufig angenommen, dass die verschiedenen Levels einen Beitrag zum wahrgenommenen Nutzen einer Alternative leisten.

Sehr vereinfacht könnte ein Modell beispielsweise zu solchen Werten kommen:

Lage

direkt am Strand      +0,8
500 m                 +0,3
2 km                  -0,6

Beim Frühstück:

inklusive             +0,4
12 €                   0,0
20 €                  -0,3

Bei der Stornierung:

kostenlos             +0,5
nicht kostenlos       -0,5

Und beim Preis:

129 €                 +0,7
149 €                 +0,1
179 €                 -0,8

Solche Werte werden häufig Part-Worth Utilities oder Teilnutzenwerte genannt.

Man kann sie sich zunächst als unsichtbare Beiträge vorstellen, die einzelne Levels zur Attraktivität eines Gesamtangebots leisten.

Der Teilnehmer nennt diese Werte aber nicht.

Wir beobachten nur seine Entscheidungen.

Das Modell versucht anschließend, eine Nutzenstruktur zu finden, die zu diesen Entscheidungen passt.

Die wichtige Unterscheidung lautet deshalb:

Die Auswahlentscheidungen sind die gemessenen Daten. Die Utilities sind bereits das Ergebnis eines statistischen Modells.

Ein negativer Nutzenwert bedeutet nicht „schlecht“

Nehmen wir an:

direkt am Strand      +0,8
500 m                 +0,3
2 km                  -0,6

Dann bedeutet der negative Wert für zwei Kilometer nicht:

Ein Hotel in zwei Kilometern Entfernung ist schlecht.

Die Werte sind keine Zufriedenheitsskala.

Entscheidend sind die Unterschiede zwischen den Levels innerhalb des geschätzten Modells.

In unserem Beispiel bedeutet das zunächst nur:

Innerhalb der untersuchten Alternativen wurde eine größere Entfernung relativ weniger bevorzugt.

Ein Hotel in zwei Kilometern Entfernung könnte trotzdem attraktiv sein, wenn andere Eigenschaften diesen Nachteil ausgleichen.

Auch Nutzenwerte existieren immer im Kontext des untersuchten Designs.

Sie lassen sich nicht wie absolute Bewertungen lesen.

Der modellierte Nutzen eines Angebots

In einem vereinfachten additiven Modell können wir uns vorstellen, dass die Teilnutzenwerte gemeinsam zu einem modellierten Nutzen eines Angebots beitragen.

Angenommen, ein Angebot besitzt:

direkt am Strand
Frühstück inklusive
kostenlose Stornierung
179 €

Dann könnten die einzelnen Beiträge in unserem vereinfachten Beispiel sein:

Lage                +0,8
Frühstück           +0,4
Stornierung         +0,5
Preis               -0,8
------------------------
modellierter Nutzen +0,9

Ein anderes Angebot könnte trotz schlechterer Lage attraktiver werden, wenn es erheblich günstiger ist.

Genau solche Abwägungen wollten wir ursprünglich verstehen.

Diese Addition ist allerdings nur ein vereinfachtes Bild. Wie genau Nutzenwerte geschätzt und miteinander verrechnet werden, hängt vom verwendeten Modell ab.

Welche Eigenschaft ist am wichtigsten?

Aus den Nutzenwerten wird häufig auch abgeleitet, wie stark ein Attribut innerhalb des untersuchten Designs zur Entscheidung beiträgt.

Eine einfache Idee besteht darin, zu betrachten, wie stark sich der Nutzen zwischen den Levels eines Attributes verändert.

Wenn beim Preis beispielsweise ein großer Unterschied zwischen:

129 €

und:

179 €

liegt, kann die untersuchte Preisspanne einen starken Einfluss auf die Wahlentscheidung haben.

Wenn sich die verschiedenen Frühstücksvarianten dagegen nur wenig unterscheiden, trägt das Frühstück in diesem Design möglicherweise weniger zur Entscheidung bei.

Daraus lässt sich eine relative Attributbedeutung ableiten.

Dabei ist eine Einschränkung besonders wichtig:

Die Bedeutung eines Attributes hängt nicht nur vom Attribut selbst ab, sondern auch davon, welche Levels wir ihm im Experiment gegeben haben.

Wenn unser Preis lediglich zwischen:

149 €
159 €
169 €

variiert, kann seine geschätzte Bedeutung anders aussehen als bei:

99 €
149 €
249 €

Wir messen also nicht abstrakt:

Wie wichtig ist der Preis?

Sondern eher:

Wie stark beeinflussen die untersuchten Preisunterschiede die Entscheidungen innerhalb dieses konkreten Designs?

Das ist ein wichtiger Unterschied.

Der Preis kann noch mehr verraten

Der Preis ist in vielen Conjoint-Untersuchungen ein besonderes Attribut.

Wenn wir beobachten, wie sich Entscheidungen verändern, wenn gleichzeitig Preis und andere Eigenschaften variieren, können wir diese Veränderungen miteinander in Beziehung setzen.

Unter geeigneten Modellannahmen lässt sich daraus beispielsweise abschätzen, welchen zusätzlichen Preis Teilnehmer für bestimmte Eigenschaften akzeptieren würden.

Zum Beispiel:

Welchen Aufpreis würden Gäste für eine Lage direkt am Strand akzeptieren?

Oder:

Welchen Wert hat kostenlose Stornierung im Verhältnis zu einem Preisunterschied?

Solche Aussagen werden aber nicht direkt abgefragt.

Sie werden aus dem geschätzten Entscheidungsmodell abgeleitet.

Können wir damit neue Angebote untersuchen?

Das ist eine der interessanten Anwendungen von Conjoint.

Nachdem ein Modell geschätzt wurde, können wir auch Kombinationen betrachten, die möglicherweise gar nicht Bestandteil der ursprünglichen Choice Tasks waren.

Zum Beispiel:

Angebot X

500 m zum Strand
Frühstück inklusive
kostenlose Stornierung
159 €

und:

Angebot Y

direkt am Strand
Frühstück 12 €
nicht kostenlos stornierbar
169 €

Anhand der geschätzten Nutzenstruktur können wir untersuchen, wie attraktiv solche Kombinationen im Modell wären.

Damit wird Conjoint nicht nur zu einer Methode, mit der wir bestehende Angebote bewerten.

Wir können auch hypothetische Angebote untersuchen.

Das ist einer der Gründe, weshalb Conjoint häufig für Produktgestaltung und Pricing interessant ist.

Das Modell ist nicht die Realität

Dabei sollte man allerdings vorsichtig bleiben.

Wenn ein Modell nahelegt, dass ein bestimmtes Hotelangebot besonders attraktiv wäre, bedeutet das nicht automatisch:

Genau so werden sich Gäste auf einem echten Buchungsportal verhalten.

Im echten Leben spielen möglicherweise weitere Dinge eine Rolle:

Bewertungen
Marke
Bilder
Verfügbarkeit
Gewohnheiten
Reisebegleitung
Tagesform

Vielleicht haben wir manche davon gar nicht in unser Conjoint aufgenommen.

Conjoint bildet immer nur den Ausschnitt der Entscheidung ab, den wir durch unsere Attribute und Levels beschrieben haben.

Das macht die Methode nicht wertlos.

Es bedeutet lediglich, dass wir verstehen sollten, welche Entscheidungssituation wir tatsächlich modelliert haben.

Je mehr Attribute, desto besser?

Es liegt nahe, möglichst viele Eigenschaften aufzunehmen.

Schließlich könnte auch die Zimmergröße wichtig sein.

Und der Pool.

Und das Fitnessstudio.

Und die Sternebewertung.

Und die Bewertungen anderer Gäste.

Und die Entfernung zum Flughafen.

Und der Check-out-Zeitpunkt.

Irgendwann wird aus einer übersichtlichen Aufgabe aber eine Tabelle, die kaum noch jemand vernünftig vergleichen kann.

Angebot A | Angebot B | Angebot C

12 oder 15 Zeilen mit unterschiedlichen Eigenschaften

Der Teilnehmer muss jedes Angebot verstehen, vergleichen und sich entscheiden.

Mehr Attribute bedeuten deshalb nicht automatisch ein besseres Conjoint.

Wir sollten diejenigen Eigenschaften untersuchen, deren Trade-offs für unsere Fragestellung wirklich relevant sind.

Auch hier beginnt die Methode nicht mit der Software oder dem statistischen Verfahren.

Sie beginnt mit einer guten Forschungsfrage.

Conjoint ist keine komplizierte Frage

Begriffe wie:

Experimental Design
Part-Worth Utilities
Choice Model

lassen Conjoint schnell kompliziert wirken.

Für den Teilnehmer selbst kann die Aufgabe dagegen ausgesprochen einfach sein:

Welches dieser Angebote würden Sie wählen?

Die Komplexität steckt nicht unbedingt in der sichtbaren Frage.

Sie steckt darin, welche Angebote wir zeigen, wie wir ihre Eigenschaften variieren und was wir anschließend aus den Entscheidungen ableiten.

Eine Choice-Based-Conjoint-Untersuchung besteht deshalb im Kern aus drei Aufgaben:

geeignete Choice Tasks erzeugen
        ↓
Entscheidungen erheben
        ↓
Nutzenstruktur aus den Entscheidungen schätzen

Die Wahl zwischen Angebot A, B und C ist nur der sichtbare mittlere Teil.

Das Experimental Design davor und die statistische Auswertung danach gehören genauso zur Methode.

Wenn eine Bewertung nicht mehr reicht

Eine klassische Bewertungsskala ist nicht grundsätzlich schlechter.

Wenn wir wissen möchten:

Wie zufrieden waren Gäste mit einem bestimmten Hotel?

ist eine Bewertungsskala wahrscheinlich wesentlich geeigneter.

Wenn wir einzelne Eigenschaften relativ zueinander priorisieren möchten, kann MaxDiff die passendere Methode sein.

Und wenn wir verstehen möchten, wie Menschen zwischen vollständigen Angeboten entscheiden, deren Eigenschaften gleichzeitig variieren, wird Conjoint interessant.

Sehr verkürzt:

Rating
→ Wie wird ein konkretes Angebot bewertet?

MaxDiff
→ Wie werden einzelne Eigenschaften relativ zueinander priorisiert?

Conjoint
→ Wie wirken sich unterschiedliche Kombinationen von Eigenschaften
  auf die Wahl zwischen Gesamtangeboten aus?

Die Verfahren beantworten unterschiedliche Fragen.

Die Ausgangsfrage lautet deshalb auch hier nicht:

Welche Methode ist die beste?

Sondern:

Was möchte ich am Ende über die Entscheidungen meiner Befragten wissen?

Wenn es genügt zu wissen, dass Lage, Preis und Frühstück wichtig sind, braucht es kein Conjoint.

Wenn wir aber verstehen möchten, was passiert, wenn bessere Lage, höherer Preis, Frühstück und Stornierungsbedingungen miteinander konkurrieren, wird die Methode interessant.

Denn am Ende buchen Menschen keine einzelnen Eigenschaften.

Sie entscheiden sich für Kombinationen daraus.