Als Praktiker sollten Sie mit einfachen Änderungen beginnen, um schnelle Ergebnisse zu erzielen. Beim Skalieren muss der Fokus jedoch von der Geschwindigkeit auf die Wirkung verlagert werden.

Einleitung

Nur 12 % der Experimente erzielen eine statistisch signifikante Verbesserung bei ihrer primären Kennzahl. Teams sehen mit ebenso hoher Wahrscheinlichkeit ein negatives Ergebnis wie ein positives.

Dies ist ein Beleg dafür, wie schwierig es ist, das Nutzerverhalten zu verändern. Wenn Experimentieren jedoch als System und nicht als isolierte Tests betrachtet wird, wandelt es Unsicherheit in kumulatives Lernen und bedeutsame Wirkung um.

Bei Optimizely-Kunden liefert jedes umsatzorientierte Experiment im Durchschnitt einen inkrementellen Anstieg von 0,4 % beim digitalen Umsatz, wenn die Ergebnisse angewendet, verfeinert und im Laufe der Zeit aufgebaut werden.

Wie kann also das Experimentieren für Sie funktionieren?

Die leistungsstärksten Experimentierteams beherrschen vier wichtige Säulen:

  • Sie verknüpfen Kennzahlen mit dem Geschäftswert
  • Erhöhen Sie die Testgeschwindigkeit ohne Qualitätseinbußen
  • Gehen Sie über A/B-Testing hinaus zu fortgeschrittenen Methoden
  • Optimieren Sie digitale Erlebnisse entlang der Customer Journey

Dieser Leitfaden erläutert, wie ein solches Programm aussieht – basierend auf unserer Analyse von über 127.000 Experimenten.

12 %

der Experimente erzielen eine statistisch signifikante Verbesserung bei ihrer primären Kennzahl.

Warum die meisten Programme ins Stocken geraten

1. Schlechte Kennzahlen

Über 90 % der Experimente zielen auf fünf gängige Kennzahlen ab: CTA-Klicks, Umsatz, Checkout, Registrierung und In-den-Warenkorb-Legen. Drei dieser fünf Kennzahlen haben die geringste erwartete geschäftliche Wirkung aller von uns erfassten Kennzahlenkategorien. Wenn primäre Kennzahlen zu weit vom getesteten Wandel entfernt sind, dauern Tests länger bis zum Abschluss, mehr Ergebnisse bleiben unschlüssig und das Programm verliert an Dynamik.

Anteil primärer Kennzahlen vs. erwartete Wirkung

Anteil primärer Kennzahlen vs. erwartete Wirkung
nameAnteil primärer KennzahlErwartete Wirkung
CTA-Klicks34%8%
Umsatz28%2%
Checkout16%2%
Registrierung9%4%
In den Warenkorb4%2%
Anzeigen / Seitenaufrufe2%5%
Scrollen / Interaktion1%4%
Menü oder Navigation1%4%
Suche1%3%
Bounce-Rate0%7%

2. Geschwindigkeit ohne Qualität

Führen Sie genug Experimente durch – oder zu viele?

Unsere Daten zeigen, dass das durchschnittliche Unternehmen nur 34 Experimente pro Jahr durchführt:

  • Durchschnittliches Unternehmen: 34 Experimente jährlich
  • Top 10 %: 200+ Experimente jährlich
  • Top 3 %: 500+ Experimente jährlich

Anzahl der Experimente

Anzahl der Experimente
nameExperimente
10. Perzentile4
25. Perzentile12
50. Perzentile34
75. Perzentile93
90. Perzentile196
95. Perzentile340
99. Perzentile1,235

Der verbreitete Mythos: Mehr Tests führen automatisch zu besseren Ergebnissen.

Die Daten erzählen eine andere Geschichte: Unsere Analyse zeigt, dass die Wirkung pro Test bei 1–10 jährlichen Tests pro Entwickler ihren Höhepunkt erreicht. Bei mehr als 30 Tests pro Entwickler sinkt die erwartete Wirkung um ganze 87 %.

Erwartete Wirkung / Test

Erwartete Wirkung / Test
Tests pro EntwicklerErwartete Wirkung
1–53
6–103
11–202
21–302
>300

3. Kein Gedächtnis

Ein Testergebnis wird im Chat geteilt, und niemand handelt danach. In einem Hypothesenmeeting taucht dieselbe Idee auf, die jemand vor acht Monaten bereits getestet hat – nur erinnert sich niemand mehr an das Ergebnis. Das passiert, wenn ein Programm kein organisatorisches Gedächtnis hat. Ohne dieses kumuliert sich nichts.

 

4. Nur A/B-Denken

Die meisten Experimente sind heute einfache A/B-Tests, und das ist eine verpasste Chance. Unsere Daten zeigen:

  • 77 % der Experimente testen nur zwei Varianten (A/B)
  • Tests mit 4+ Varianten haben eine 3,5-fach höhere erwartete Wirkung als ein typischer A/B-Test
  • Sie liefern auch 27,4 % höhere Uplift-Werte

Teams, die im reinen A/B-Modus verbleiben, begrenzen ihr Potenzial, ohne es zu merken.

Großartige Experimente verbessern die User Experience mutig und bleiben offen für verschiedene Wege.

Großartige Experimente verbessern die User Experience mutig und bleiben offen für verschiedene Wege.
nameErwartete Wirkung
1 unterschiedlicher Änderungstyp0%
2 unterschiedliche Änderungstypen0%
3 unterschiedliche Änderungstypen0%
4+ unterschiedliche Änderungstypen2%

Diese Hindernisse haben eine gemeinsame Ursache. Programme, die als Ansammlungen von Tests statt als wiederholbare Systeme aufgebaut sind, produzieren Ergebnisse, aber kein Lernen. Ohne das System kumuliert sich nichts zu etwas, auf das die Unternehmensführung reagieren kann.

Grundlagen eines effektiven Experimentierprogramms

Die meisten Teams messen, ob einzelne Experimente gewinnen oder verlieren. Das zeigt, ob ein Test funktioniert hat. Es sagt nicht, ob das Programm funktioniert.

1. Jeden Test mit dem Geschäftswert verbinden

Hochleistungsprogramme verwenden einen Zielbaum, der verknüpft, was getestet wird, mit dem, was die Unternehmensführung misst.

  1. North Star an der Spitze: Das primäre Ergebnis, auf das das Unternehmen hinarbeitet. Umsatzwachstum, Kundenbindung, Customer Lifetime Value. Es ist die Richtung, nicht die Kennzahl, gegen die man testet. Wenn jedes Experiment den North Star direkt bewegen „sollte”, wird die Kennzahl falsch eingesetzt.
  2. Strategische Kennzahlen in der Mitte: Drei bis fünf Hebel, von denen das Unternehmen glaubt, dass sie den North Star bewegen werden. Conversion Rate, durchschnittlicher Bestellwert, Churn-Reduzierung und Akquisitionseffizienz.
  3. Optimierungsziele unten: Spezifische Nutzerverhalten, die ein Test direkt verändern kann, wie die In-den-Warenkorb-Rate, Abbrüche beim Lieferschritt und Registrierungsabschluss.

Business goal tree settingBildquelle: Optimizely

Die primäre Kennzahl jedes Experiments sollte sauber von einem Optimierungsziel über eine strategische Kennzahl bis zum North Star rückverfolgbar sein. Wenn diese Verbindung vor dem Test nicht offensichtlich ist, ist der Test nicht ausgerichtet, und ein Gewinn daran wird nichts an den Entscheidungen ändern.

Neben dem Zielbaum gibt es drei Kennzahlenrollen innerhalb jedes Experiments:

  • Eine primäre Kennzahl, die den Erfolg definiert, eng mit der getesteten Änderung verknüpft
  • Zwei bis drei sekundäre Kennzahlen, die Kontext liefern und das primäre Ergebnis erklären
  • Drei bis fünf Überwachungskennzahlen, die als Leitplanken fungieren, um Schäden zu erkennen

Diese vor dem Start festlegen. Während des Tests nicht ändern. Eine einfache Regel: Wenn sich die primäre Kennzahl nicht ändert, hat das Experiment sein Ziel nicht erreicht, unabhängig davon, was sonst noch passiert.

2. Verfolgen, ob das Programm klüger wird

Die meisten Programme verfolgen nur die Gewinnrate, und die meisten interpretieren sie falsch. Eine gesunde Gewinnrate liegt zwischen 10 und 30 %. Eine gesunde Abschlussrate – Gewinne und Verluste zusammengenommen – liegt zwischen 35 und 40 %.

Das Signal, das es zu beobachten gilt, ist die Abschlussrate, nicht die Gewinnrate. Unschlüssige Tests sind die eigentliche Belastung. Experimente, die Traffic und Zeit verbrauchen, ohne zu einem klaren Ergebnis zu gelangen, vernichten die Geschwindigkeit und untergraben das Vertrauen der Stakeholder, das Programme am Leben erhält.

Goal tree

Bildquelle: Optimizely

Drei Programmkennzahlen sind relevant, sobald eine regelmäßige Kadenz etabliert ist.

  1. Geschwindigkeit: Ob das Experimentieren im richtigen Tempo Erkenntnisse generiert. Nicht nur, wie viele Tests laufen, sondern ob die Kadenz konsistent genug ist, dass einzelne Ergebnisse nicht mehr unverhältnismäßig viel Gewicht tragen.
  2. Qualität: Ob die Ansätze anspruchsvoller werden. Wenn das Volumen steigt, aber die meisten Tests immer noch A gegen B auf denselben wenigen Seiten vergleichen, wird das Programm beschäftigter, ohne besser zu werden.
  3. Umfang: Ob Experimente bedeutsame Änderungen adressieren. Experimente, die drei oder mehr Änderungstypen kombinieren, liefern die stärksten Gewinne. Schnell erreichbare Ziele erschöpfen sich. Es gibt nur so oft die Möglichkeit, Überschriften, Button-Texte oder Farben zu optimieren. Eine nachhaltige Wirkung erfordert das Testen von vollständigen Customer Journeys, Arbeitsabläufen und Erlebnissen.

3. Priorisieren, was den nächsten Testplatz verdient

Jedes Programm hat mehr Ideen als Kapazität. Ohne ein gemeinsames Priorisierungsmodell setzt sich der lauteste Stakeholder durch, und Backlogs beginnen wie das Organigramm auszusehen.

RICE gibt jeder Idee eine konsistente Bewertung, bevor sie in den Backlog aufgenommen wird

Rice prioritization framework

Bildquelle: Optimizely

Konfidenz ist die Dimension, die die meisten Teams nach Bauchgefühl bewerten. Sie sollte an Daten, vorherigen Experimenten oder Forschung geknüpft sein. Ein auf Intuition basierender Konfidenzwert ist Optimismus mit einer Zahl dahinter.

Der Experimentierlebenszyklus

Grundlagen sagen Ihnen, was zu messen ist und wie Sie den Programmzustand verfolgen. Der Lebenszyklus beschreibt, wie jedes Experiment tatsächlich abläuft. Sechs Phasen. Jede speist die nächste. Wenn eine bricht, hört das Lernen auf zu kumulieren. Wenn alle sechs halten, macht jedes Experiment das nächste klüger.

Experimentation lifecycle

Bildquelle: Optimizely

1. Mit dem richtigen Problem beginnen

Die meisten Tests scheitern, bevor jemand eine Hypothese formuliert. Hochleistungsprogramme triangulieren drei Inputs, bevor die Ideenfindung beginnt:

  1. Quantitative Daten: Wo Reibung in Trichtern, Customer Journeys und Trends auftritt
  2. Qualitative Erkenntnisse: Warum es passiert, aus Umfragen, Support-Tickets und Feedback
  3. Verhaltensanalyse: Was Nutzer tatsächlich tun, aus Session-Replays, Heatmaps und Journey-Analysen

Zusammen eingesetzt helfen sie, Symptome von Grundursachen zu unterscheiden und das Testen oberflächlicher Korrekturen zu vermeiden.

Das Ergebnis ist eine Problemformulierung, die spezifisch genug ist, um die Ideenfindung zu lenken, ohne Teams auf eine Lösung festzulegen. Nicht „Nutzer konvertieren nicht”, sondern „Nutzer verstehen die Liefergebühren erst im letzten Checkout-Schritt, und 25 % der befragten Nutzer geben an, deshalb abgebrochen zu haben.”

Das PSR-Framework hält diese Disziplin im gesamten Programm aufrecht.

PSR frameworkBildquelle: Optimizely

Sobald das Problem validiert ist, drei bis fünf testbare Lösungen generieren – nicht nur die sicherste mögliche Änderung.

Mehrere konkurrierende Lösungen zu testen erhöht die Wahrscheinlichkeit, dass mindestens eine bedeutsame Verbesserung liefert.

Es verändert auch die Arbeitsweise von Teams. Die Risikobereitschaft steigt, weil sicherere Optionen abgedeckt sind. Die Verantwortung wird breiter, weil mehr Mitwirkende sehen, wie ihre Ideen getestet werden.

2. Ein lohnenswertes Backlog aufbauen

Ein voller Backlog ist nicht dasselbe wie ein guter. RICE-Bewertungen ordnen Ideen ein. Vor der Festlegung auf etwas prüfen: gemeinsame Zielgruppen, Plattform-Timing, saisonale Zeitfenster und Experimente, bei denen ein Ergebnis das nächste informieren sollte.

Ein ausgewogener Backlog mischt bewusst:

  • Ideen mit höherer Wirkung und geringerer Konfidenz, die durch fokussierte Entdeckungstests erkundet werden
  • Experimente mit geringem Aufwand, die Annahmen validieren oder schnelles Lernen erzeugen
  • Hochkonfidente Ideen mit begrenzter Reichweite, die für bestimmte Segmente oder Customer Journeys wichtig sind

3. Planen und gestalten

Eine gute Hypothese wird zu einem schlechten Experiment, wenn die Planung übersprungen wird. Vor dem Start bestätigen:

Wird dieses Experiment innerhalb eines angemessenen Zeitrahmens abgeschlossen sein?

Wird der erwartete Traffic ausreichend sein, um zu erkennen, ob die Änderung eine Wirkung hatte?

So breit wie die Hypothese erlaubt targeten. Zu enges Targeting verlangsamt das Lernen, indem die verfügbare Zielgruppe verkleinert und Ergebnisse schwieriger auf die breitere User Experience übertragbar werden.

Segmente im Voraus definieren, wenn es eine klare Hypothese gibt, dass verschiedene Zielgruppen unterschiedlich reagieren werden. Segmentierung, die nachträglich angewendet wird, um Uplift irgendwo zu finden, erhöht das Risiko falscher Positive und führt zu Schlussfolgerungen, die schwer zu vertrauen oder zu wiederholen sind.

Den richtigen Experimenttyp wählen.

Experimenttyp Was es ist Wann man es einsetzt
A/B-Test (Einzelvariante) Vergleicht eine Variante mit einer Kontrolle Wenn eine klar definierte Änderung mit einer fokussierten Hypothese validiert werden soll, insbesondere bei begrenztem Traffic
A/B/n-Test Testet mehrere alternative Lösungen gegen dieselbe Kontrolle Wenn verschiedene Wege zur Lösung desselben Problems erkundet und die Chance auf einen Gewinner erhöht werden soll
Multivariater Test (MVT) Testet Kombinationen mehrerer Elemente gleichzeitig Wenn die Interaktion zwischen Elementen wichtig ist und das Traffic-Volumen hoch ist

Mehrarmiger Bandit

 Verteilt Traffic dynamisch auf besser abschneidende Varianten um Wenn das Ziel ist, die Performance während des Experiments zu maximieren statt reines Lernen
Kontextueller Bandit Weist Varianten basierend auf Nutzerattributen oder Kontext zu Wenn erwartet wird, dass verschiedene Zielgruppen unterschiedlich reagieren
Personalisierungsexperiment Liefert maßgeschneiderte Erlebnisse für definierte Zielgruppen und misst die Wirkung Wenn getestet werden soll, ob Personalisierung ein generisches Erlebnis übertrifft
Feature- oder Produktexperiment Testet funktionale oder logikbasierte Änderungen, oft serverseitig Wenn Produktentscheidungen, Arbeitsabläufe oder Algorithmen validiert werden sollen
Holdout-Test Verwendet eine Kontrollgruppe, die keine Änderung erhält, um kausale Wirkung zu isolieren Wenn Effekte nicht mit Standard-A/B-Tests isoliert werden können

Der richtige Experimenttyp kann dabei helfen, bessere Ergebnisse zu erzielen. Zum Beispiel generieren personalisierte Erlebnisse eine 41 % höhere Wirkung als generische.

Chart data
nameErwartete Wirkung
Ohne Targeting10%
Personalisiert12%

Jedes Experiment benötigt einen vor dem Start vereinbarten Testplan. Er enthält die Hypothese, den Experimenttyp, die Varianten, das Targeting, die primäre Kennzahl, die Entscheidungsregeln und Risiken. Ohne ihn werden Ergebnisse gegen die Frage interpretiert, die im Nachhinein am bequemsten erscheint.

4. Ausführen und überwachen

Die Ausführung ist der Punkt, an dem gut konzipierte Experimente scheitern.

Die ersten Stunden sollten sich auf Korrektheit konzentrieren, nicht auf Performance:

  • Kontrolle und alle Varianten werden korrekt gerendert
  • Traffic wird gemäß der geplanten Zuteilung aufgeteilt
  • Primäre Kennzahl wird für alle Varianten erfasst
  • Keine Tracking-Lücken, Doppelzählungen oder unerwartete Spitzen
  • Interne Nutzer, Bots und QA-Traffic sind ausgeschlossen

Frühe Volatilität ist zu erwarten. In diesem Zeitfenster die Performance nicht bewerten. Das Ziel ist Validierung, nicht Interpretation.

Sobald die Startvalidierung abgeschlossen ist, verlagert sich die Überwachung auf den Schutz der Integrität. Auf unerklärliche Verschiebungen in der Zielgruppenzusammensetzung, Traffic-Inkonsistenzen oder Konflikte mit anderen Experimenten achten, die für dieselbe Zielgruppe laufen.

Sobald ein Experiment live ist, das Design als unveränderlich behandeln. Jede Änderung an Varianten, Targeting oder Kennzahlen führt zu Verzerrungen und macht das Ergebnis unzuverlässig. Nur zum Schutz von Nutzern oder des Unternehmens pausieren. Nur basierend auf vordefinierten Kriterien beenden. Externe Ereignisse während der Laufzeit dokumentieren.

Stoppen, wenn die primäre Kennzahl statistische Signifikanz erreicht und der Test mindestens zwei Wochen gelaufen ist, um normale Nutzerverhaltensmuster zu erfassen. Außerdem stoppen, wenn der Test seine geplante Laufzeit absolviert hat, erheblichen Traffic angesammelt hat und die Ergebnisse weit von der Signifikanz entfernt bleiben – als unschlüssig klassifizieren und fortfahren.

5. Analysieren und entscheiden

Das häufigste Versagen bei der Analyse passiert, bevor jemand die Daten betrachtet.

  1. Denken: Die Absicht neu formulieren. Welches Problem das Experiment lösen sollte, was die Hypothese war, was die primäre Kennzahl ist und welche Richtung Erfolg darstellt. Dies verhindert, dass die Frage nach Bekanntwerden der Antwort geändert wird.
  2. Beobachten: Primäres Kennzahlergebnis für jede Variante. Sekundäre Kennzahlen für Kontext. Überwachungskennzahlen, um zu zeigen, ob etwas kaputtgegangen ist. Nur vordefinierte Segmente.
  3. Interpretieren: Ausliefern, iterieren, ausweiten oder stoppen. Dokumentieren, warum die Entscheidung getroffen wurde, nicht nur was entschieden wurde. Statistische Signifikanz ist ein Schwellenwert, keine Garantie.

Experimente mit dem Warehouse zu verbinden bedeutet, gegen Customer Lifetime Value, Rücklaufquoten und Kundenbindung statt gegen Klicks und Conversions zu analysieren. Da KI-Suche die Entdeckung übernimmt, werden Klicks immer weniger als Indikator für den Geschäftswert geeignet. Die Kennzahlen, die künftig wichtig sein werden, leben im Warehouse.

6. Ausliefern, iterieren und kumulieren

Einen Gewinner auszuliefern ist nicht dasselbe wie eine Erkenntnis zu kumulieren.

Die Entscheidung bestätigen, dass sie noch gilt. Genau das ausliefern, was getestet wurde. Last-Minute-Anpassungen verändern den Mechanismus, der das Ergebnis erzeugt hat. Jede Produktionsanpassung wird dokumentiert.

Dieselbe primäre Kennzahl und Leitplanken nach dem Launch überwachen. Dann iterieren:

  • Verfeinern: Das Verhalten targeten, das sich bewegt hat oder nicht bewegt hat
  • Angrenzend erkunden: Einen anderen Ansatz für dasselbe Problem testen
  • Ausweiten: Denselben Mechanismus auf neue Kontexte oder Zielgruppen anwenden
  • Stoppen: Die Erkenntnis dokumentieren und weitermachen

Kumulieren funktioniert nur, wenn Ergebnisse ändern, was als Nächstes passiert. Die meisten Teams kennen das Gefühl, wenn das bricht. Ein Testergebnis, das in Slack geteilt wird, auf das niemand reagiert. Ein Hypothesenmeeting, bei dem dieselbe Idee auftaucht, die jemand vor acht Monaten getestet hatte, nur erinnert sich niemand mehr an das Ergebnis. Das ist, was passiert, wenn ein Programm kein Gedächtnis hat.

Struktur schlägt Improvisation. Schriftliches schlägt Mündliches. Breiter Input schlägt kleine Gruppen. Die Programme, die kumulieren, sind jene, bei denen jeder finden kann, was getestet wurde, was gelernt wurde und was als Nächstes kommt.

Wie KI im gesamten Experimentierlebenszyklus wirkt

Optimizely AI usage for experimentationBildquelle: Optimizely

Aber für die meisten Teams bedeutet das immer noch, Ideen einzugeben, eine Antwort zu bekommen und weiterzumachen.

Es gibt einen Unterschied zwischen einem Chatbot und einem Workflow-Agenten. Ein Chatbot antwortet, wenn Sie ihn etwas fragen. Ein Workflow-Agent führt aus, ob Sie fragen oder nicht. Wenn ein Test abgeschlossen ist, sieht der Agent es. Fasst das Ergebnis zusammen. Generiert Folge-Ideen aus Ihrer tatsächlichen Programmhistorie. Entwirft Pläne in Ihrem Format und stellt sie zur Überprüfung in die Warteschlange. Sie haben nicht gefragt. Es lief einfach.

Diese Unterscheidung ist, wo die Daten sich trennen. Teams, die Agenten im gesamten Zyklus einsetzen – nicht nur am Anfang – führen 78 % mehr Experimente durch und sehen eine 9 % höhere Gewinnrate. Erstellung steigt zuerst. Abschlussraten und Gewinnraten folgen, wenn Agenten in die Ausführung und Analyse einziehen.

Wo Agenten heute eingesetzt werden

10,95 % der Experimente starten mit agentengenerierten Ideen. Nur 6,8 % werden von Agenten zusammengefasst. Die zweite Hälfte des Zyklus ist, wo die Dinge sich aufstauen. Ein Test, der reale Kennzahlen bewegt, benötigt in der Regel benutzerdefinierten Code. Das bedeutet ein Entwickler-Ticket, eine Warteschlange, einen Sprint und Tage, nur um priorisiert zu werden.

Der Variation Development Agent wurde entwickelt, um diesen Engpass zu lösen. Die meisten KI-Experimentiertools generieren rohen Code. CSS-Dumps. JavaScript, das auf Ihre Seite injiziert wird. Das klingt hilfreich, bis Sie das resultierende Snippet-Chaos und die Debugging-Sessions erben. Der Variation Development Agent arbeitet mit den nativen Tools des visuellen Editors. Die Ausgabe ist sauber. Änderungen sind reversibel. Der Mensch behält die Kontrolle.

19,54 % der Folgetests werden jetzt durch Agentenempfehlungen geleitet, die in vorherigen Ergebnissen verankert sind. Das ist die zweite Hälfte des Zyklus, die läuft, ohne dass jemand es steuern muss.

Agents in the workflowBildquelle: Optimizely

Der Maßstab ist, ob KI weniger Arbeit nachgelagert erzeugt als es einspart.

Damit KI auf Programmebene und nicht nur für Einzelpersonen funktioniert, müssen drei Dinge vorhanden sein. Rollen müssen definiert sein, damit Agenten wissen, für wen sie arbeiten. Ausgaben benötigen Checkpoints, damit Menschen überprüfen, was wichtig ist. Die Unternehmensführung benötigt Transparenz darüber, was läuft, damit Teams nicht unwissentlich widersprüchliche Tests für dieselbe Zielgruppe durchführen.

Agenten ohne diese Struktur auf ein Programm anzusetzen beschleunigt die Aktivität statt das Lernen.

58,74 %

der gesamten Nutzung von Optimizely-Agenten entfällt auf das Experimentieren.

Alles zusammenführen

Jedes umsatzorientierte Experiment liefert im Durchschnitt 0,4 % inkrementellen Anstieg beim digitalen Umsatz, wenn Ergebnisse angewendet und aufgebaut werden. Ein einzelner Test bewegt diese Zahl nicht. Das System zu betreiben, schon.

Möchten Sie tiefer eintauchen?