Blogartikel

13min. Lesezeit

Product Manager vs. Product Owner: Wo liegt der Unterschied?

Gehüpft wie gesprungen? Wo liegt der Unterschied zwischen einem Product Manager und einem Product Owner … oder ist das im Grunde der gleiche Job?

Nein, ein Produktmanager und ein Product Owner haben nicht dieselbe Rolle. Sie verfolgen zwar ein gemeinsames Ziel – Produkte, die Usern lieben und nutzen – haben jedoch nicht denselben Verantwortungsbereich.

In der Regel sind Produktmanager für das Warum verantwortlich. Sie erstellen die Produkt-Roadmap auf Grundlage der Bedürfnisse und Wünsche der User. Sie konzentrieren sich auf Geschäftskennzahlen und darauf, ob sich ein Produkt in die richtige Richtung entwickelt.

Product Owner ihrerseits sind für die Erstellung und Abwicklung des Product Backlogs verantwortlich. Sie sind im operativen Prozess involviert und an eine Deadline gebunden. Für sie dreht sich alles um Scrum, das Hin und Her mit den Entwicklern und darum, anstehende Aufgaben zu erledigen.

Doch oft lässt sich keine klare Trennlinie zwischen den beiden ziehen. Je nachdem, wo Sie arbeiten, sind Sie möglicherweise an unterschiedliche Situationen gewöhnt. Um die Unterschiede und die Ähnlichkeiten zwischen diesen beiden Jobs besser zu verstehen, haben wir unseren firmeninternen Produktmanager Yoann Grange gebeten, Klarheit zu schaffen.

Sie haben nur wenig Zeit? Klicken Sie direkt auf den Abschnitt, der Sie interessiert.

[toc]

Welche Verantwortlichkeiten hat der Product Manager? Welche der Product Owner?

Diese Frage beschäftigt mich schon seit über fünf Jahren. Und das so sehr, dass ich bereits 2016 25 Video-Interviews [auf Französisch] mit Product Ownern, Produktmanagern, Heads of Product usw. geführt habe.

Meine Antwort lautet kurz und knapp: Kommt drauf an.

Product Manager Experience

Sie denken jetzt bestimmt „Na klar! Gilt das nicht für alles?“

Aber hier, in diesem Fall, hängt dies tatsächlich von vielen verschiedenen Faktoren ab. Einige werden in diesem Artikel näher behandelt.

Product Manager vs Product Owner: Was wann in Betracht ziehen sollte

Wir dürfen nicht aus den Augen verlieren, dass es Produkte unterschiedlichster Art gibt: Industrieprodukte, landwirtschaftliche Produkte, Dienstleistungen, Chemikalien, Modeprodukte … und Softwareprodukte.

Im SaaS MarTech Bereich herrscht die Meinung vor, dass alle Produkte gleich aufgebaut sind und alle Unternehmen die gleiche Struktur aufweisen. Die Branche tendiert zur Annahme, dass hinter jedem Feature ein Produktmanager und ein Product Owner steckt.

Die Wirklichkeit sieht aber anders aus: Manchmal ist es der eine oder der andere, manchmal beide oder sogar keiner von beiden. Welche Faktoren bestimmen diese Struktur? Sehen wir uns ein paar davon näher an.

1. Dynamik

Das wichtigste Kriterium ist „die Dynamik des Unternehmens“. Was verstehe ich unter diesem Begriff?

Wie neu/alt ist das Unternehmen?

Diese Frage ist wichtig. Sie steht nicht in direktem Zusammenhang mit der Größe des Unternehmens. Sie bezieht sich auch nicht auf die Anzahl der Kunden. Ich kenne zum Beispiel ein Unternehmen mit neun Personen und über 200.000 zahlenden Kunden. Die Firma ist mittlerweile „schon“ sechs Jahre alt und die Produkt-Funktion wird hier mehr oder weniger von allen wahrgenommen.

Wie weit ist das Unternehmen von einem bestimmten „Schlüsselmoment“ entfernt?

product owner vs product manager ab tasty

Unter „Schlüsselmoment“ verstehe ich Schlüsselphasen oder Ereignisse im Lebenszyklus eines Unternehmens. Zum Beispiel:

  • Gründung des Unternehmens
  • Verkauf des Unternehmens
  • neue Finanzierung
  • Steuerprüfung
  • Release eines Mitbewerbers
  • Krise
  • Neuer CEO
  • … Sie wissen, wovon ich spreche.

Diese verschiedenen Schlüsseletappen wirken sich auf die Praxis der Produktentwicklung aus.

Sie bestimmen deshalb, was ein Produktmanager und was ein Product Owner macht.

Kurz nach der Gründung eines Unternehmens ist der CEO wahrscheinlich am besten geeignet, die Produktrollen zu betreuen. Häufig ist der CEO (zumindest in skalierbaren SaaS Unternehmen) derjenige, der die Funktion von PO, PM, QA und Support inne hält, was weder eine bewusste Entscheidung noch eine Strategie ist, sondern einfach nur das, was im entsprechenden Moment notwendig ist.

Wie man mit der Dynamik eines Unternehmens umgeht, bestimmt in der Regel außerdem wie „gut“ sich das Unternehmen macht.

Wurde der gegenwärtige Moment antizipiert oder ist er nur das Ergebnis der Reaktion auf den vorhergehenden Moment? Sie können davon ausgehen, dass ein Unternehmen umso „agiler“ ist, je öfter es reagiert. Je mehr Momente antizipiert werden, desto „visionärer“ das Unternehmen. Gleichzeitig agil und visionär zu sein, ist eine große Herausforderung.

2. Die Größe zählt

Mit Größe meine ich nicht nur die Anzahl der Mitarbeiter. Die Größe eines Unternehmens bezieht sich auch auf die Anzahl der:

  • Produkte
  • Modelle
  • Features
  • Scopes
  • Preistabellen
  • oder Märkte, die das Unternehmen anspricht.

Produkte auf die richtigen „Dimensionen“ zurechtzuschneiden und zu entscheiden, ob sie nach Markt, Produktlinie oder Thema aufgeteilt werden sollen, kann eine Lebensaufgabe sein: Die Dinge ändern sich ständig und je schneller sich ein Unternehmen entwickelt, desto öfter sind Änderungen nötig.

Die Größe kann auch durch die Anzahl der User, Kunden, Partner, Händler, Sprachen, Einheitensysteme usw. definiert werden. Noch häufiger aber ergibt sich aus einer Kombination all dieser Faktoren, wie viele PMs, POs und Heads of Product Ihr Unternehmen benötigt.

In vielen NGOs zum Beispiel hängt die Anzahl der Produktmanager von den Spender-Personas ab. Es gibt einen PM für kleine Spendenbeträge (z. B. 10 $ bis 500 $), einen für größere Beträge (500 $ bis 10 000 $) und einen weiteren für noch höhere Beträge. Warum? Weil sich die Erwartungen der verschiedenen Typen von Personas stark unterscheiden. Die Fähigkeit, auf jede Persona einzugehen, trägt langfristig zum Wachstum gemeinnütziger Unternehmen bei.

Kurz gesagt, die Größe eines Unternehmens (sein Kundenportfolio, sein Produktkatalog usw.) kann darüber entscheiden, was der PM macht, was der PO macht und wie viele PMs und POs eingesetzt werden.

3. Weitere Kriterien

Wie viele PMs, POs oder andere Mitarbeiter im Produktbereich benötigt werden, hängt nicht nur von den genannten Faktoren ab. Es können noch zahlreiche andere Faktoren einfließen, z. B.:

  • Anzahl der Entwickler
  • Anzahl der Designer
  • Versandgeschwindigkeit
  • technische Stacks
  • Tools
  • Produktlebenszyklus
  • individuelle Wünsche
  • Wachstumspotenzial
  • abgedeckter Anteil des existierenden Bedarfs
  • Legacy-Anteil
  • Personalpolitik
  • der Markt, den Sie ansprechen
  • Schließlich kommt es auch noch darauf an, welche Politik das Unternehmen verfolgt.

Im Großen und Ganzen ist man sich (zumindest in SaaS Unternehmen) darüber einig, dass sich die Trennlinie zwischen PM und PO folgendermaßen ziehen lässt: Vision vs. operative Prozesse, Planung vs. Dringlichkeit, Nutzen vs. Kennzahlen. Doch beide gehören zusammen.

product manager vs product owner infographic

Obwohl sich die beiden Rollen voneinander abgrenzen, sind sie letztlich nicht voneinander zu trennen.

Kein Unternehmen gleicht dem anderen. Deshalb gibt es keine Standardantwort auf die Frage, was ein PM im Vergleich macht. Sie müssen Ihren eigenen Weg finden. Manche Unternehmen werden viele PMs und POs brauchen, manche überhaupt keine. Es ist schon schwierig genug, dafür zu sorgen, dass Menschen erfolgreich zusammenarbeiten. Einfach eine Methode zu kopieren, hilft nicht. Sie müssen Ihr eigenes Konzept finden.

Sollte ich die Frage dennoch beantworten müssen, würde ich sagen, dass PMs eher das letzte Wort bei der Priorisierung haben und für Unternehmenskennzahlen verantwortlich sind. POs hingegen sind für die Einhaltung der Termine des Teams verantwortlich. Doch auch diese Antwort ist immer noch zu simpel.

Kann eine Person sowohl die Rolle des Produktmanagers als auch die Rolle des Product Owners übernehmen?

Ja. Absolut. Das bedeutet nicht, dass es so sein muss, aber dass es definitiv möglich ist.

Tatsächlich ist das bei relativ vielen Startups in ihrer Anfangsphase der Fall. Meistens treten mindestens zwei Personen auf den Plan: eine der beiden ist technikorientiert, die andere eher geschäftsorientiert. Oft übernimmt die geschäftsorientierte Person die Produktfunktion. Sie kann aber auch von beiden oder von der technikorientierten Person übernommen werden.

Wie gesagt sind Vision vs. operative Prozesse, Planung vs. Dringlichkeit, Nutzen vs. Kennzahlen die zwei Seiten von drei verschiedenen Dingen, die die Product-Person bei jeder Entscheidung berücksichtigen muss.

Die Konfiguration aus einem PM mit mehreren POs ist häufiger anzutreffen als ein PO mit mehreren PMs. Aber im Endeffekt, warum nicht? Alles hängt von den oben genannten Kriterien ab.

Besteht Deiner Erfahrung nach ein Gehaltsunterschied zwischen Product Owner und Produktmanager?

Ja. Produktmanager verdienen eher mehr als Product Owner. Auch hier liegt der Grund darin, dass es für beide Rollen eine gewisse Standardauslegung gibt und die Rolle des Product Owners als weniger anspruchsvoll betrachtet wird. Dabei handelt es sich einfach nur um zwei verschiedene Rollen. Pure kognitive Verzerrung.

Product manager salary pendo report

Der Report Stand der Produktführerschaft 2020 von Pendo zeigt überraschenderweise eine negative Korrelation zwischen „Glücksgefühl“ und Gehalt der befragten Produktmanager auf. Es dreht sich also nicht alles nur ums Geld.

 

Welche Fähigkeiten muss ein guter Produktmanager und/oder Product Owner mitbringen?

Das ist meine Lieblingsfrage, auf die jeder eine andere Antwort hat. Doch sind sich mehr oder weniger alle einig, dass der Rahmen relativ weit gefasst ist.

Mir sträuben sich die Haare, wenn ein Stellenangebot in etwa so beginnt: „Fachhochschule oder Master-Abschluss in Informatik …“ Für Produktler braucht es mehr als nur technische Kompetenz. Je geradliniger die Menschen denken, die an Ihrem Produkt arbeiten, desto geradliniger ist auch Ihr Produkt. Und desto schneller wird es angenommen.

Zoom und Fokus

Ich würde sagen, dass ein PM/PO in erster Linie fähig sein muss, verschiedene Perspektiven einzunehmen, um ein Problem sowohl aus der Mikro- als auch aus der Makroperspektive zu erfassen.

Manchmal müssen Sie ins kleinste Detail gehen. In anderen Fällen müssen Sie das Gesamtproblem verstehen, das durch das Produkt oder Feature gelöst werden soll. Jederzeit die Perspektive zu ändern, ist der Schlüssel zum Erfolg. Die Makroperspektive hilft Ihnen, die Konkurrenz und den Markt zu verstehen, die Mikroperspektive ermöglicht es, die Details einer Komponente zu verstehen. Sie müssen sich jederzeit vor Augen halten, warum Sie was tun.

Semantik und Semiologie

Mein Fremdsprachen-Hintergrund hat mir gleich zu Beginn geholfen, als Schnittstelle zwischen Entwicklern und Usern/Kunden zu agieren. Ich komme auch heute noch ziemlich oft darauf zurück, um zu entscheiden, was wichtig ist und was nicht. Dieser Hintergrund hilft, sich bei einem User Test auf eine bestimmte Anmerkung zu konzentrieren und bei einem zehnminütigen Video zu erfassen, was wichtig ist. Außerdem versteht man dadurch besser, warum ein Symbol problematisch ist und weshalb die Kombination eines bestimmten Labels mit einem bestimmten Symbol nicht funktioniert, warum beide notwendig sind, warum es besser wäre, überhaupt darauf zu verzichten (allerdings nur für einige User) …

Ob technisch oder funktional, schriftlich oder mündlich, optisch oder akustisch: Bei Sprachen geht es in erster Linie darum, den Sinn zu vermitteln. Von Team zu Team, vom User zur Maschine, von der Spezifikation zum fertigen reellen Feature: Alles dreht sich darum, einander zu verstehen. Obwohl diese Evolution seit so vielen Jahren in Gang ist, sind wir auf diesem Gebiet nicht viel besser geworden.

Das Design zählt ebenfalls dazu. Wer Wireframes und Mockups erstellen kann, hat schon viel gewonnen. Selbst wenn sie nicht in Ihren Aufgabenbereich fallen, können diese Visualisierungsformen einen Prozess beschleunigen oder den Weg für andere Lösungen ebnen.

Wichtig ist auch, was jeder Einzelne unter „Kommunikation“ versteht, denn Sie haben es mit Usern, Dritten, Stakeholdern aller Art, manchmal auch mit den Medien usw. zu tun. Deshalb ist es von Vorteil, wenn Sie eine Präsentation, ein Webinar oder eine Schulung abhalten.

Zu guter Letzt sollten Sie gerne Geschichten schreiben und erzählen. Die meisten Menschen lieben es, Geschichten zu hören, aber nicht jeder schreibt sie auch gerne.

Iteration und Lernprozess

Weitere wichtige Fähigkeiten schließen alles ein, was unter „testen -> messen -> verbessern“ fällt.

„Testen“ heißt zweifeln. Wer sich seiner Sache allzu sicher ist, riskiert zu scheitern. Die Fähigkeit, eine Hypothese aufzustellen ist ebenfalls wichtig. Nehmen Sie nie etwas als Selbstverständlich hin.

Und in puncto Messung kann die Erfahrung mit einem wissenschaftlichen Ansatz hilfreich sein, ebenso wie die Fähigkeit, die Dinge klar zu erkennen und die Performance zu messen. Das schließt analytische (quantitative) Kenntnisse oder verhaltensanalytische (qualitative) Skills ein.

Philosophisch gesehen muss ein erfolgreicher Produktmanager oder Product Owner schon im Vorfeld des Versuchs ein Scheitern in Kauf nehmen. Und er muss akzeptieren, dass er irgendwann mit den Verbesserungen Schluss machen muss, wenn sich der Erfolg einstellt. Eine hundertprozentige Perfektion ist einfach nicht möglich.

Mit welchen KPIs lässt sich der Erfolg von Product Ownern und Product Managern messen?

Ich versuche, nicht mehr jede Frage mit „Kommt ganz darauf an“ zu beantworten. Aber … es kommt wirklich ganz darauf an. Meiner Meinung nach sollten die KPIs von Produktmanagern auf Unternehmenskennzahlen basieren: Wachstum, Umsatz, Abwanderung, Kosten … Für Product Owner zählen Lieferung, Qualität, Teamzufriedenheit.

Welche Kurse kann man belegen, um ein (besserer) Produktmanager zu werden?

Wie gesagt, das erforderliche/minimale Skillset ist extrem breit gestreut. Die gute Nachricht? Etwas Neues zu lernen macht Sie zu einem besseren Menschen und damit auch zu einem besseren Product Mitarbeiter.

Sehen Sie sich selbst zunächst als Person. Wenn Sie sich als Produkt positionieren, neigen Sie dazu, sich auf fehlende oder falsche Dinge zu konzentrieren. Wenn Sie sich als Person sehen und einen ganzheitlichen Blickwinkel einnehmen, ist jede neue Fähigkeit von Interesse.

Wir fungieren auch als Bindeglied zwischen Usern und technischen Teams, um das Beste aus minimalen (oder fortgeschrittene) technischen Kenntnissen herauszuholen, damit Sie die technischen Teams und ihre komplexen Aufgabenstellungen verstehen können.

In den letzten 15 Jahren habe ich für 17 Unternehmen gearbeitet und empfehle deshalb jedem, das Unternehmen oft zu wechseln. Sie wechseln dabei auch noch die Branche? Umso besser!

Welche Lektüre würdest du empfehlen?

Die meisten PM, PO, VP, Heads of Product legen Ihnen eine lange Liste von Bestsellern zum Thema Produktmanagement nahe. In der Regel geht es dabei um Titel wie „Lean UX“, „Lean Startup“, „Wie werde ich ein erfolgreicher Produktmanager“ usw. Ich versuche mich mit einer etwas anderen Liste.

Ich empfehle eher Klassiker, weil sie sich auf die Grundlagen konzentrieren. Selbst bei Klassikern besteht nur eine geringe Chance, dass andere Produktmanager oder Product Owner sie gelesen haben. Die Welt dreht sich immer schneller, doch die Grundlagen ändern sich nicht.

Im Product arbeiten wir für die Menschen. Unser Job ist es, die Menschen zu verstehen, damit wir ihnen helfen können. Wir versuchen, echten Problemen der Menschen mit möglichst risikoarmen Lösungen zu begegnen. Wir sind weit davon entfernt, die Komplexität der Menschheit in ihrem vollen Ausmaß zu verstehen. Einige Menschen stechen jedoch aus der Masse heraus und haben uns Meisterwerke geschenkt:

NB: Lesen ist gut. Experimentieren ist besser.

 

Abonniere
unseren Newsletter

bloc Newsletter DE

Wir verarbeiten und speichern deine persönlichen Daten, um deine Anfrage zu beantworten. Siehe dir unsere Datenschutzerklärung an.

Blogartikel

9min. Lesezeit

Verlieren Sie keine Conversions während Ihrer A/B Tests mit Dynamic Allocation

Bei einer Experimentkampagne kann es frustrierend sein, wenn Sie Ihren Besuchern eine Variante zeigen, die während der gesamten Testdauer nicht sonderlich gut konvertiert und andere Varianten bessere Ergebnisse erzielen. Wir bei AB Tasty kennen diesen Pain Point. Deshalb helfen wir unseren Kunden, „verschwendeten Traffic“ zu minimieren, der bei einem Test unweigerlich entsteht. Und das mit unserem beliebten Dynamic Traffic Allocation Feature, das auf dem Thompson Sampling-Algorithmus und dem Bayesschen Statistikmodell in Form eines Algorithmus beruht.

Die Bayessche Statistik löst das schwierige Problem des „Mehrarmigen Banditen“: Sie findet die Balance zwischen „Exploitation“ und „Exploration“ der Daten, um die Experimente fortlaufend – und schnell! – zu optimieren. Wir bieten weit mehr als nur eine Entscheidungshilfe für unsere Kunden, wie es nach einem A/B-Test weitergehen soll. Will heißen: Wir halten eine automatisierte Lösung bereit, die ideal ist, wenn fortlaufend Entscheidungen getroffen werden müssen und die Zeit knapp ist, oder wenn Sie in einer Umgebung arbeiten, die sich ständig ändert.

Stellen Sie sich vor, Sie starten während der Festtage eine einwöchige Werbekampagne. Obwohl Sie mehrere Varianten testen möchten, lautet das Ziel, den Umsatz zu optimieren, und nicht zwangsläufig statistische Relevanz zu erreichen. Angenommen, eine weltweite Pandemie wirkt sich auf Ihre Geschäftsergebnisse aus und zwingt Sie, auf neue Art zu kommunizieren. Obwohl Sie mehrere Varianten testen möchten, lautet das Ziel, möglichst schnell die Kommunikation zu optimieren und nicht zwangsläufig einen klassischen A/B-Test durchzuführen.

AB Tasty bietet schon seit längerem Dynamic Alllocation an. Vor Kurzem haben wir jedoch den gesamten Prozess gestrafft. Er wird insgesamt kohärenter und lässt sich leichter aktivieren, wenn Sie eine Kampagne erstellen.

Was ist Dynamic Traffic Allocation?

Bei der Dynamic Traffic Allocation wird mit einem Algorithmus das Trafficvolumen angepasst, das den einzelnen Live-Test-Varianten zugeteilt wird.

Der Dynamic Traffic Allocation Algorithmus ermittelt die Variante mit der höchsten Performance und teilt dieser Version mehr Traffic zu.

Warum ist es nützlich?

Dynamic Allocation hilft, den Verlust von Conversions während eines Tests (den sogenannten „Regret“) zu begrenzen. Dazu kann es kommen, wenn ein Teil Ihres Website Traffics an eine Variante gesendet wird, die letztlich nicht die Gewinnervariante ist.

Werfen wir einen Blick auf folgenden A/B-Test: ConversionRateA = 1 %, ConversionRateB = 1,5 %, der Test wurde mit einem gleichbleibenden Traffic von 10.000 Besuchern pro Variante durchgeführt.

Der „Regret“ dieses Tests: r = 10.000 * (0,015-0,01) = 50 verlorene Conversions. Während des Testzeitraums hätten wir im Idealfall 300 Conversions erzielen können (20.000*0,015), doch mit dem Test haben wir 50 Conversions verloren.  Während dieser Zeit wären also nur 250 Conversions erzielt worden.

Selbstverständlich können wir solche Berechnungen erst anstellen, wenn der Test abgeschlossen ist und wir die genauen Zahlen für die Conversion Rate kennen. Das bedeutet aber nicht, dass nichts gegen „verschwendeten“ Traffic während eines Tests unternommen werden kann …

Wie funktioniert die Dynamic Traffic Allocation?

Das oben genannte Problem lässt sich lösen, indem die Traffic Allocation des Tests geändert wird, damit weniger Besucher zu den „schlechten“ Varianten und mehr Besucher zu den „guten“ Varianten geschickt werden.

Aber Achtung: Solche Änderungen manuell vorzunehmen, ist sehr riskant, da die Ergebnisse verfälscht werden können. Es gibt jedoch Algorithmen, die den Traffic so kanalisieren, dass der Regret eines Tests auf ein Minimum reduziert werden kann während die erfolgreichste Variante identifiziert wird.

Wir haben den zuverlässigsten Algorithmus für diese Aufgabe auf folgender Basis ausgewählt: Wir verwenden die Messunsicherheiten der Conversion Rate, um einen Kompromiss zwischen „Exploration und Exploitation“ zu erzielen. Bei der Exploration senden wir Traffic an eine Variante, selbst wenn sie nach den ersten Messwerten nicht als Gewinnervariante hervorgeht – wir wissen ja, dass die ersten Schlussfolgerungen nicht zuverlässig sind. Bei der Exploitation senden wir Traffic an eine Variante, die angesichts der bereits gesammelten Zahlen als Gewinnervariante gilt. So vermeiden wir, zu viele Conversions zu verlieren (vorausgesetzt, die betreffende Variante ist tatsächlich die Gewinnervariante).

Diese beiden Ziele stehen natürlich im Widerspruch zueinander.  Exploration bedeutet, Conversions zu verlieren, Exploitation bedeutet, ein Risiko einzugehen, wenn nicht die erfolgreichste Variante ausgewählt wird! Deshalb ist es entscheidend, die Messunsicherheit genau zu modellieren und dann den richtigen Kompromiss zwischen „Exploration und Exploitation“ zu finden.

Mit der Wahrscheinlichkeitsverteilung können wir für jede Variante die Messunsicherheit der Conversion Rate berücksichtigen. Diese Grafiken zeigen, wo der wahre Conversion Rate-Wert am ehesten zu finden ist. Je höher der Wert auf der Y-Achse der Kurve, desto größer die Chance, dass der entsprechende X-Wert dem wahren Wert entspricht.

Hier ist ein Beispiel:

ne-perdez-plus-de-conversions

Variante A verzeichnet 7 Erfolge bei 600 Besuchen (schwarze Kurve), Variante B verzeichnet 27 Erfolge bei 600 Besuchen (rote Kurve). Die Situation ist eindeutig: Die Conversion Rate der Variante A liegt wahrscheinlich zwischen 0 % und 0,2 %, die der Variante B wahrscheinlich zwischen 0,25 % und 0,7 %. Da es sich um zwei getrennte Intervalle handelt, können wir mit ziemlicher Sicherheit behaupten, dass B die Gewinnervariante ist, selbst wenn wir nicht sicher sein können, dass die Messwerte stimmen. Es besteht praktisch kein Zweifel daran, dass B die Gewinnervariante ist, da sich die Kurven nicht überschneiden.

Hier ein weiteres Beispiel:

ne-perdez-plus-de-conversions

Variante A verzeichnet 7 Erfolge bei 300 Besuchen (schwarze Kurve), Variante B verzeichnet 14 Erfolge bei 400 Besuchen (rote Kurve). Die einfache Berechnung der Conversion Rate ergibt ConversionRateA = 2,39 %, ConversionRateB = 3,63 %. Augenscheinlich besteht ein Unterschied in der Conversion Rate, sodass wir versucht sind, Variante B als Gewinner zu betrachten, doch das ist falsch … Wenn wir die Wahrscheinlichkeitsverteilung näher betrachten, lässt sich die Messunsicherheit besser erkennen. Da sich die beiden Kurven überschneiden, zeigt sich, dass noch Zweifel bestehen können.

Der Kompromiss zwischen „Exploration und Exploitation“

Sehen wir uns das letzte Beispiel noch einmal genauer an. Genauso wahrscheinlich ist, dass die ConversionRateA bei 3 % und die ConversionRateB ebenfalls bei 3 % liegt (Schnittpunkt der beiden Kurven). Mit diesem Ansatz können wir die Wahrscheinlichkeit berechnen, dass A die Gewinnervariante ist, selbst wenn B im Moment besser zu sein scheint. Wir verwenden diese Art von Berechnungen, um die richtige Balance zwischen „Exploration und Exploitation“ zu finden. Mithilfe eines Algorithmus wie Thompson Sampling können wir den Nutzen der Exploration und das mit der Exploitation verbundene Risiko einschätzen.

Dieser Algorithmus:

  • findet im Laufe der Zeit mit Sicherheit die Gewinnervariante
  • verliert garantiert weniger Conversions als ein stabiler Traffic
  • findet die Gewinnervariante schneller (falls mehr als 2 Varianten getestet werden) als das bei einem stabilen Traffic der Fall wäre. Je mehr Varianten, desto größer die Wahrscheinlichkeit, dass ein paar (sehr) schlechte Varianten dabei sind. Die erfolgloseren Varianten werden schnell identifiziert und erhalten weniger Traffic als Varianten, die besser performen. Bei einer stabilen Traffic Allocation würden diese (sehr) schlecht abschneidenden Varianten auch weiterhin ein nicht unerhebliches Trafficvolumen verlieren.

Wie können Sie die Dynamic Traffic Allocation verwenden?

Mit AB Tasty ist die Dynamic Traffic Allocation besonders einfach zu bewerkstelligen: Sie müssen nur auf die Schaltfläche „Change to Dynamic allocation“ klicken und den primären KPI auswählen, der optimiert werden soll. Anfangs wird der Traffic noch gleichmäßig verteilt. Im Laufe des Tests wird er angepasst und automatisch so verteilt, dass die Gewinnervariante identifiziert und der Conversion-Gewinn maximiert werden kann.

Nach dem Teststart verläuft alles wie bei einem herkömmlichen Test (mit gleichmäßiger Traffic-Verteilung). Selbstverständlich berücksichtigen alle statistischen Messungen die Dynamic Allocation. Die Testergebnisse können deshalb genau gleich interpretiert werden.

New Dynamic Traffic Allocation interface by AB Tasty

Warum Dynamic Allocation?

Wenn die Zeit knapp ist, haben User dank der Dynamic Allocation die Möglichkeit, den Traffic direkt auf die beste Variante zu leiten, ohne in die Kampagne einzugreifen. Das sorgt für schnellere Ergebnisse und einen besseren ROI!

Dynamic Allocation kann in folgenden Fällen äußerst nützlich sein:

  • Wenn Benutzer Mikro-Conversions optimieren möchten, die in einem kurzen Zeitraum erwartet werden, nachdem der User einer Variation ausgesetzt war. Auf E-Commerce-Websites bevorzugen einige Kunden z. B. den „In den Warenkorb“-CTA gegenüber dem Transaktionsereignis als primäres Ziel.
  • Wenn User nur eine kurze Zeit zur Verfügung haben, einen Test laufen zu lassen.
  • Bei speziellen Werbeangeboten in der Weihnachtszeit mit einigen Varianten und dem Ziel, in diesem kurzen Zeitraum den Umsatz zu maximieren.
  • Während der Corona-Krise muss ein Unternehmen möglicherweise schnell mit Kunden kommunizieren. Das Unternehmen möchte möglichst rasch die Gewinnervariante verwenden.
  • Wenn die zu testende Seite ein sehr geringes Trafficvolumen verzeichnet. Bei einem niedrigen Traffic kann es schwierig sein, wahre statistische Signifikanz zu erreichen, doch das hindert Sie nicht daran, die Customer Experience zu optimieren. Die Dynamic Allocation wäre die logische Wahl.
  • Wenn viele Varianten zu testen sind, d. h. mehr als 6 Varianten, bietet die Dynamic Allocation Usern die Möglichkeit, schlecht funktionierende Varianten schnell zu identifizieren, um den Test nur für die relevantesten Varianten durchzuführen.

Sie möchten mehr über AB Tasty, Dynamic Allocation und andere KI-gestützte Funktionen wie Engagement Level und Content Interest erfahren, um Ihre Marken- und Produkterlebnisse zu optimieren? Wir zeigen sie Ihnen live in einer persönlichen Demo.