PIE, ICE & PXL – Priorisierung von Conversion Tests

Torsten Tromm Growth Marketing Jetzt kommentieren

Lesezeit: ca. 14 Min.

Die Grundsituation vieler Conversion-Optimierer und Growth Marketer in Unternehmen sieht ungefähr so aus:

  • Das Backlog ist prall gefüllt. Ideen für Tests gibt es mehr als genug. Insbesondere wenn sich eine gute Testing-Kultur im Unternehmen entwickelt hat und Produktmanager, Marketing, Developer, Sales etc. ihre Testideen beisteuern.
  • Ressourcen für Entwicklung, Design, Content etc. sind knapp. Die einzelnen Abteilungen konkurrieren um die Ressourcen. Auch das Budget für Outsourcing ist begrenzt.
  • Traffic ist zwar da, allerdings nicht so viel, dass man eine große Anzahl Conversion Tests gleichzeitig mit klar abgegrenzten Segmenten laufen lassen könnte.
  • Es gibt großen Druck von oben. Die Erwartungen der Business-Stakeholder an das (teure) Conversion Team sind hoch. Vielleicht sind sie auch noch nicht ganz davon überzeugt, dass CRO wirklich funktioniert, was noch größeren Druck auf die Conversion-Optimierer erzeugt und das schnelle Abliefern guter Ergebnisse erzwingt.

Zeitdruck, begrenzte Ressourcen und Ergebnisdruck erfordern die strikte Priorisierung der Conversion Tests bzw. Growth Experiments. Nur mit einer sinnvollen und konsequenten Priorisierung können die zur Verfügung stehenden Ressourcen optimal genutzt werden, um konstant gute Ergebnisse zu erhalten und gleichzeitig die Anzahl der erfolgreichen Tests und Experimente zu steigern.

PIE, ICE & PXL – Conversion Rate Optimierung Frameworks

CRO Frameworks, wie PIE, ICE und PXL, werden in professionellen CRO Teams standardmäßig eingesetzt.

Ein Framework ist in diesem Zusammenhang als ein System oder eine Methode, die die Priorisierung von Ideen erlaubt, zu verstehen. Das CRO Framework erweitert den eher abstrakten, qualitativen Charakter einer Idee oder Hypothese um eine quantitative Dimension, indem eine Bewertung relevanter Faktoren vorgenommen wird. Das Ziel ist Bauchgefühl und Emotion im Priosierungsprozess möglichst stark zu dämpfen und so objektivere Entscheidungen zu ermöglichen.

Natürlich kann kein CRO Priorisierungs-Framework den Erfolg von Conversion-Experimenten vorhersagen. Die Bewertung von Ideen wird immer von der Subjektivität des Bewerters beeinflusst sein. Allerdings hilft ein gut aufgesetzter Priorisierungsprozess Tests in eine sinnvolle Reihenfolge zu bringen und die zur Verfügung stehenden Ressourcen vornehmlich für Tests mit einer höher eingeschätzten Erfolgswahrscheinlichkeit einzusetzen.
Der Einsatz eines CRO Frameworks kann auch positiv auf die Qualität der Hypothesen wirken. Die Bewertung erfordert eine intensive inhaltliche Auseinandersetzung mit der Hypothese, was häufig zu einer Präzisierung und/oder Untermauerung der Hypothese mit weiteren Daten führt.

 

Welches CRO Priorisierungs-Framework ist das richtige für mein Unternehmen?

Das Conversion Framework muss zum Unternehmen, seinen Zielen, seiner Struktur und den etablierten Workflows und Prozessen passen. Eine eindeutige und einfache Antwort auf die Frage, welches Framework das Beste ist oder welches zu einem spezifischen Unternehmen passt, gibt es nicht. Wenn man noch gar keine Priorisierungsmethode einsetzt, läuft es in der Regel auf eine Trial-and-Error-Phase hinaus. Häufig entwickelt sich aus einer anfänglich implementierten Lehrbuchmethode schnell ein individuelles System, das auf die individuellen Anforderungen angepasst ist.

Als Startpunkt können die nachfolgenden Beschreibungen von CRO Frameworks dienen.

 

PIE Framework

Das PIE Framework ist wahrscheinlich das unter CRO Professionals verbreitetste Priotization Framework. Es sieht die Bewertung von Hypothesen nach drei Kriterien vor:

Potential

Wie groß ist das Uplift-Potential? An wie vielen Stellen greift die Verbesserung? Ist zu erwarten, dass die Verbesserung nachhaltig wirkt? Stützen Daten aus Web Analytics, heuristischer Analyse, CRM etc. die Hypothese?

Importance

Wie stark zahlt die mögliche Verbesserung auf definierte Ziele des Unternehmens ein? Eine Verbesserung, die nicht positiv auf Ziele wirkt, hat keine nachhaltige Bedeutung für das Business. Selbst, wenn sie leicht umsetzbar wären, sollten solche Ideen niedrig priorisiert werden.

Ease

Wie einfach oder schwierig wird die Entwicklung und Implementierung des Experiments sein?
Hier werden sowohl die technische Schwierigkeit und die Verfügbarkeit von Ressourcen, als auch interne „politische“ Hürden, wie der Produktmanager, der unbedingt ein bestimmtes Homepage-Layout braucht, bewertet.

 

Der eigentliche Bewertungsvorgang ist relativ simpel: Jedes Kriterium wird mit 1-10 Punkten bewertet. Bei Potential und Importance ist es eindeutig, bei Ease sollte man bedenken, dass Ease mit Einfachheit zu übersetzen ist. Eine hohe Bewertung für Ease bedeutet also, dass die Realisierung leicht ist.
Aus den Bewertungen der drei Kriterien wird der Durchschnitt berechnet ((P+I+E)/3), der so genannte PIE Score. Nun müssen lediglich alle Ideen nach ihrem PIE Score sortiert werden und schon hat man eine priorisierte „Warteschlange“ für seine Conversion Experimente.

 

 

ICE Framework

Das ICE Framework ist eine Variante des PIE Frameworks. Auch hier werden die Ideen nach drei Kriterien bewertet:

Impact

Welche Auswirkungen hätte ein erfolgreicher Test auf das Unternehmen und seine Ziele? Welche Auswirkungen haben die Ergebnisse des Tests auf zukünftige Tests? Können Erkenntnisse gewonnen werden, die über den Weg weiterer Tests zum Erfolg im Sinne der definierten Ziele führen?

Confidence

Wie groß ist das Vertrauen in die Richtigkeit der Hypothese? Welche Daten, Studien, Erkenntnisse und Analysen stützen die Hypothese?

Ease

Analog zu PIE. Werden externe Ressourcen benötigt? Müssen im Vorfeld aufwändige Arbeiten erledigt werden? Gibt es Hindernisse technischer oder politischer Art?
Die Bewertung und Auswertung erfolgt analog zum PIE Framework: Bewertung 1-10, Bildung des Durchschnitts (ICE Score) und Sortierung.

 

Die Auswertung erfolgt nach der gleichen Methode wie im PIE Framework: Der Durchschnitt der Bewertung der drei Kriterien ergibt den „ICE Score“.

 

 

Unterschiede zwischen PIE und ICE

Grundsätzlich ähneln sich die beiden CRO Frameworks recht stark. „Ease“ ist bei beiden identisch. Potential und Impact unterscheiden sich in der generellen Stoßrichtung.

Potential bewertet stärker die Verbesserung spezifischer Metriken, während bei Impact ein stärkerer Fokus auf die dahinterliegenden strategischen Ziele gesetzt wird.

Diese Komponente findet sich bei PIE im Kriterium Importance, während an dieser Stelle im ICE Framework eher die Qualität der Hypothese („Confidence“) bewertet wird.

 

Nachteile der PIE und ICE Frameworks

Beide Frameworks sind auf den ersten Blick recht schwammig. Die Definition der Kriterien ist nicht sonderlich präzise. Die Bewertungen sind sehr anfällig für Subjektivität. Leicht passiert es, dass unbewusste Faktoren und persönliche Präferenzen auf die Bewertung wirken.

Die Bewertungen an sich sind ebenfalls wenig präzise. Unterschiedliche Bewerter kommen bei beiden Frameworks mit hoher Wahrscheinlichkeit zu unterschiedlichen Ergebnissen, da keine Referenzen für die Höhe der Bewertungen vorgegeben werden. Ob ein Kriterium mit einer 6 oder einer 7 bewertet wird, ist reines Bauchgefühl.

Sinnvoll ist es, die Bewertungen in mehreren Instanzen d.h. von mehreren Personen vorzunehmen zu lassen und dann die Durchschnitte der einzelnen Kriterien zu berechnen, um daraus den Score zu errechnen. Noch besser ist es die Bewertung im Rahmen einer Gruppenarbeit mit relevanten Beteiligten vorzunehmen und die Bewertungen der einzelnen Kriterien in einer inhaltlichen Diskussion zu erarbeiten.

 

Vorteile der PIE und ICE Frameworks

Eine mit Schwächen behaftete Priorisierungsmethode ist besser, als gar keine Priorisierungsmethode. Dies gilt zumindest dann, wenn man sich der Schwächen bewusst ist und Maßnahmen ergreift, um die Schwächen zu kompensieren.

Für die Verwendung von PIE oder ICE spricht, dass die Methoden leicht von jedem verstanden und nachvollzogen werden können. Der Implementierungsaufwand ist in der Regel relativ gering.

Beide Frameworks unterstützen die Prozessualisierung von Testing/Experimentation, was eine Voraussetzung für den langfristigen Optimierungserfolg ist. Beide Frameworks fördern die inhaltliche Auseinandersetzung mit den Hypothesen, was häufig auch zu einer Präzisierung der Hypothesen führt.

Die in PIE und ICE gemachten Bewertungen können und sollten langfristig gesammelt und analysierbar gemacht werden. Eine in regelmäßigen Intervallen durchgeführte Retrospektive, in der die Bewertung in der Priorisierung mit dem tatsächlichen Ergebnis der Tests verglichen werden, hilft dabei systematische Fehlbewertungen zu erkennen (Bsp.: „Ease wurde in 80% der Customer Acquisition Tests überbewertet“). Diese Erkenntnisse werden dazu genutzt die Bewertungsqualität künftig zu erhöhen.

Trotz der offensichtlichen Schwächen sind PIE und ICE gut dazu geeignet eine Basis für ein prozessualisiertes und priorisiertes Testing zu schaffen. Wenn konsequent an der Kompensation der methodischen Schwächen und an der Verbesserung der Bewertungsperformance gearbeitet wird, können beide Frameworks auch als langfristige Lösung vollkommen ausreichend sein.

 

Kompensation der Schwächen von PIE und ICE

  • Mehrere Bewertungsinstanzen und Bildung von Durchschnitten
  • Alternativ: Gemeinsame Bewertung auf Basis einer inhaltlichen Gruppen-Diskussion
  • Kompression/Spezifizierung der Bewertungsskala

Zu den ersten beiden Punkten wurde weiter oben schon einiges gesagt. Eine interessante Möglichkeit der Modifikation bietet die Kompression und Spezifikation der Bewertungsskala. Wie oben beschrieben, ist die Bewertungsskala unspezifiziert und erlaubt großen Spielraum für Bauchgefühl und alle möglichen Biases.

Eine beispielhafte Modifikation könnte so aussehen:

  • „Impact“ wird mit der Definition von ICE übernommen. Diese enthält die Komponente der übergeordneten Ziele und erscheint damit aussagekräftiger als „Potential“ in PIE.
  • „Importance“ und „Confidence“ werden durch „Cost“ ersetzt. Die Ziel-Komponente von „Importance“ ist in „Impact“ bereits enthalten. In unserem Beispielszenario sind Kosten und Ressourcenbedarf die am stärksten limitierenden Faktoren für das Testing und „Confidence“ wird nicht bewertet, da solide Hypothesen-Prozesse für eine allgemein hohe Confidence der eingereichten Hypothesen sorgen.
  • „Ease“ wird wie in PIE und klassischem ICE gewertet.
  • Die Bewertungsskala wird von zehn Bewertungsstufen (1-10) auf zwei Bewertungsstufen komprimiert. Die Bewertungsstufen werden klar spezifiziert.
  • Die Gewichtung von „Impact“ wird erhöht.

Es gibt also pro Kriterium nur noch zwei Optionen: Entweder hoch oder niedrig. Impact kann dabei doppelt so viele Punkte erhalten, wie Cost oder Ease.

 

Impact 0 Punkte:
kein oder geringer zu erwartender Uplift, zahlt nicht oder gering auf strategische, definierte Ziele ein

Impact 2 Punkte:
signifikanter Uplift möglich, zahlt auf strategische Ziele ein

 

Cost 0 Punkte:
zu teuer. Kein Budget und/oder keine Ressourcen vorhanden.

Cost 1 Punkte:
Ausreichendes Budget/Ressourcen zur Umsetzung stehen zur Verfügung.

 

Ease 0 Punkte:
Umsetzung/Durchführung ist unmöglich, sehr umfangreich oder fachlich sehr schwierig.

Ease 1 Punkte:
Umsetzung/Durchführung ist möglich, ausreichende Entwicklungsressourcen und Knowledge vorhanden

 

Der „Score“ wird nun nicht mehr als Durchschnitt der Kriterien gerechnet, sondern addiert.

Eine einfache Matrix spezifiziert die Bedeutung des Scores:

Score 4: Außergewöhnlich starke Optimierungschance. Sollte mit höchster Priorität verfolgt werden.

Score 3: Starke Optimierungschance. Sollte so bald wie möglich getestet werden.

Score 2: Optimierungschance. Sollte getestet werden, sobald Ressourcen frei sind.

Score 1: Geringe Optimierungschance. Wird zurückgestellt und evtl. in „Leerlaufphasen“ getestet.

Score 0: Keine Optimierungschance. Sollte nicht weiterverfolgt werden.

 

 

Diese Modifikation verbessert die ursprünglichen Methoden, durch eine Simplifizierung und durch eine Adaption an individuelle Gegebenheiten. Allerdings entsteht hier gleichzeitig ein neuer Nachteil, denn die Granularität der Scores nimmt ebenfalls ab. Bei einem umfangreichen Idea-Backlog, werden so viele Ideen die gleiche Punktzahl erreichen und müssten eigentlich nach weiteren Kriterien priorisiert werden.

Genau hier setzt das PXL Framework an.

 

PXL Framework

Das PXL Framework verwendet ebenfalls eine binäre Bewertungsmatrix, die pro Kriterium nur zwei Bewertungsoptionen vorsieht. Ebenso werden die Kriterien unterschiedlich stark gewichtet. Ein wesentlicher Unterschied zu PIE und ICE ist die höhere Anzahl der bewertenden Kriterien und die deutlich spezifischere Definition der einzelnen Kriterien.

Den Mangel an Präzision in den Kriterien von ICE und PIE eliminiert PXL durch das Einbringen von Erfahrungswerten in die Kriterien. Statt diffuse Kriterien wie „Potential“ oder „Confidence“ zu bewerten, werden konkrete, etablierte Erfolgsfaktoren wie „Above the fold“ oder die Untermauerung durch Daten bewertet.

Auch in „Ease“ werden konkrete Vorgaben für die Bewertung gemacht, wodurch das Kriterium eine wesentlich höhere Aussagekraft erhält.

 

 

Folgende Kriterien werden im PXL Framework bewertet:

 

Impact Kriterien

Above the fold – Wird der Test im primär sichtbaren Bereich ausgespielt? (0=nein, 1=ja)
Tests above the fold haben eine höhere Wahrscheinlichkeit von vielen Menschen wahrgenommen zu werden und somit eine höhere Wahrscheinlichkeit eine signifikante Auswirkung zu haben.

Erfassbar in 5 Sekunden – Kann die Testvariante innerhalb von fünf Sekunden wahrgenommen werden? (0=nein, 2=ja)
Hier wird im Vorfeld ggf. ein „5-Sekunden-Test“ mit einer kleinen Test-Gruppe durchgeführt. Kann die Variante innerhalb von fünf Sekunden wahrgenommen werden, ist die Wahrscheinlichkeit höher, dass der Test eine signifikante Auswirkung hat. Dies erhöht zwar den Aufwand in der Priorisierung, kann aber in Umfeldern in denen viele erfolgversprechende Hypothesen getestet werden sollen, eine sinnvolle Methode der Vorauswahl sein.

Element weg/hinzu – Wird ein Element hinzugefügt oder entfernt? (0=nein, 2=ja)
Die Wahrscheinlichkeit einer signifikanten Auswirkung steigt mit der Intensität der Änderung. Wird z.B. ein Reibungspunkt entfernt oder eine wichtige Information hinzugefügt, kann das signifikant positiv auf die Conversion Rate wirken.

Soll User Motivation erhöhen – Zielt die Test-Variante darauf ab, den User zu einem bestimmten gewünschten Verhalten zu motivieren? (0=nein, 1=ja)
Optimierungen, die die Zielerreichung in den einzelnen Funnel-Stages des Conversion Funnels fördern, haben mit höherer Wahrscheinlichkeit „Impact“.

Ausspielung auf High Traffic Pages – Wird die Test-Variante auf Seiten mit hohem Traffic ausgespielt? (0=nein, 1=ja)
Eine Verbesserung der Conversion Rate auf High Traffic Pages hätte einen größeren „Impact“.

 

Confidence Kriterien

User Testing Thema – Bezieht sich der Test auf eine Erkenntnis, die in User Testing Prozessen gewonnen wurde? (0=nein, 1=ja)
Mit User Testing Methoden lassen sich aufschlussreiche Erkenntnisse gewinnen und daraus starke Hypothesen entwickeln. Mit guten Daten und Erkenntnissen untermauerte Hypothesen haben eine höhere Chance auf ein signifikantes Ergebnis.

Feedback Thema – Bezieht sich der Test auf eine Erkenntnis, die mit qualitativen Feedback-Methoden, wie Umfragen oder Interviews, gewonnen wurden? (0=nein, 1=ja)
Analog zum vorherigen Kriterium bieten qualitative User Research Methoden eine einzigartige Perspektive auf Produkt und Marketing. Die Chance auf dieser Basis Verbesserungen zu erreichen ist hoch.

Basiert auf Analytics Daten – Gibt es Daten aus Digital Analytics Tools, die die Hypothese stützen? (0=nein, 1=ja)
Hypothesen, die sich auf eine solide Datenbasis stützen können, haben eine höhere Wahrscheinlichkeit zutreffend zu sein.

Mouse Tracking, Eye Tracking, Heatmaps – Gibt es Daten aus Analysen des Nutzerverhaltens, die mit entsprechenden Tools erhoben wurden, die die Hypothese untermauern? (0=nein, 1=ja)
Diese Methoden sind dazu geeignet eine weitere Perspektive auf das Verhalten von Nutzern und Kunden zu eröffnen und erlauben beispielsweise Reibungspunkte zu eliminieren oder die Wahrnehmung von Key Elements zu verbessern.

 

Ease of Implementation

Die Einfachheit der Umsetzung und Implementierung wird nach folgendem Punkteschema auf Basis der geschätzten benötigten Arbeitszeit bewertet:

Weniger als 4 Stunden = 3 Punkte
Bis zu 8 Stunden = 2 Punkte
Bis zu 2 Tage = 1 Punkt
Mehr als 2 Tage = 0 Punkte

 

Auswertung der Priorisierung im PXL Framework

Die Auswertung erfolgt bei PXL wieder durch Addition aller Bewertungen zum „PXL Score“ und anschließende Sortierung nach der Höhe des „PXL Scores“.
Durch die höhere Anzahl an Bewertungskriterien kommt es trotz der starken Reduktion der Bewertungsskala zu einem sehr heterogenen Bewertungsgefüge und somit zu einer klaren Reihenfolge der durchzuführenden Tests und Experimente.

 

Modifikation des PXL Framework

Das PXL Framework bietet sich für Modifikation an. Weitere Kriterien können hinzugefügt werden und die Gewichtung der Kriterien kann an die eigenen Bedürfnisse angepasst werden.

Beispiele
Test im Checkout-Prozess (hohe Gewichtung, da es bekannte Probleme in diesem Bereich gibt, die schnell gelöst werden sollen)
Test für Mobile-Devices (für Unternehmen mit Mobile-First-Strategie, mit hoher Gewichtung)
Bedient strategische Ziele (hohe Gewichtung, wenn viele Ideen eingereicht werden, die nicht auf die strategischen Ziele einzahlen)

 

Fazit – PIE, ICE oder PXL?

Wer viele Test-Ideen in seinem Backlog hat, sollte diese unbedingt priorisieren. Die Gefahr in ein last-in-first-out-Schema zu verfallen oder die Queue wasserfallartig abzuarbeiten und so Zeit, Budget, Ressourcen zu verschwenden und Marktchancen zu verpassen, ist ohne einen soliden Priorisierungsprozess zu hoch. Wenn man noch keine Methode einsetzt und gar nicht oder aus dem Bauch heraus priorisiert, wird jede der hier beschriebenen Methoden eine Verbesserung bewirken.
Starten sollte man mit einer Methode, die von allen an Test- und Experiment-Prozessen beteiligten Mitarbeitern leicht verstanden und akzeptiert werden kann, da die Implementierung zunächst die größte Hürde darstellt.

Dringend empfehlenswert ist die Durchführung von Retrospektiven des Priorisierungsprozesses in regelmäßigen Intervallen. Bei der Analyse der durch die Bewertung ausgedrückten Erwartungen im Vorfeld im Vergleich mit den tatsächlichen erzielten Ergebnissen fallen oft systematische Fehlbewertungen und vorher nicht bedachte Faktoren auf. Diese Erkenntnisse sollten genutzt werden, um das eingesetzte Priorisierungs-Framework zu modifizieren und so künftig genauere Prognosen zu ermöglichen.

Nicht zu unterschätzen ist auch der Rückkopplungseffekt auf die Qualität der Hypothesen. Wenn Qualitäts- bzw. Confidence-Kriterien zum Bestandteil der Priorisierung werden, steigert dies die Motivation der beitragenden Mitarbeiter tragfähige Test-Hypothesen zu erarbeiten. Dünne Hypothesen landen zwangsläufig im unteren Drittel der Warteschlange und haben in der Regel schlechte Chancen jemals getestet zu werden.

 

Implementierung eines Priorisierungs-Frameworks in den Growth-Experimentation-Prozess

Conversion Rate Optimierung ist in der Regel nur einer von mehreren Bestandteilen eines übergeordneten Prozesses der alle Experimente und Tests des Growth Marketings regelt.
Die Priorisierung stellt dabei eine Phase eines Growth Experiments Workflows dar. Ein solcher definierter Workflow und dessen Abbildung in einem smarten Growth Experiments Management System erlaubt eine hohe Testfrequenz bei hoher Qualität der Testhypothesen.

Wie man ein solches System aufsetzen und Priorisierung einbinden kann, habe ich in meinem Artikel Growth Experimente Velocity erhöhen mit System beschrieben.

Wenn Du Fragen zum Artikel hast oder von Deiner Priorisierungsmethode berichten möchtest, schreib doch unten einen Kommentar.

Founder & CEO von Brainpath, Online-Marketer seit 1999, leidenschaftlicher Growth Nerd, Speaker auf zahlreichen Fachevents, Data-Junkie, Best-Practices-Slayer.

Schreibe einen Kommentar

You have to agree to the comment policy.