Probleme mit der Designausgabe beheben

Beheben Sie Probleme mit Ihren Designergebnissen, indem Sie die MDE-Anforderungen besser verstehen. In diesem Leitfaden erfahren Sie, wie Sie Ihre Designmesswerte anhand von Verlaufsdaten überprüfen und Ihre Testparameter anpassen, wenn die Ergebnisse nicht Ihren Messzielen entsprechen.

Details zum minimalen nachweisbaren Effekt (Minimum Detectable Effect, MDE)

Die Ausgabe jedes Designs enthält einen minimalen nachweisbaren Effekt (Minimum Detectable Effect, MDE). Der MDE ist der kleinste Steigerungsprozentsatz, den Ihr Test statistisch messen kann. Damit Ihr Test ausreichend aussagekräftig ist, sollte der MDE kleiner sein als die tatsächliche Steigerung, die Sie mit Ihrer Kampagne erwarten. Ein häufiger Fehler in der Praxis ist das Entwerfen und Ausführen eines Meridian GeoX-Tests mit einem zu großen MDE. Wenn Sie sich nicht sicher sind, welche Leistung Sie von Ihrer Kampagne erwarten können, sollten Sie einen kleineren MDE wählen. So wird sichergestellt, dass der Test empfindlich genug ist, um auch geringfügige Änderungen zu erkennen.

Wenn Sie Ihre vorhandenen Kampagnen mit den Testoptionen Go-dark oder Heavy-up testen und Ihre bisherigen Studien zur Steigerung ähnliche Setups haben oder ein Marketing Mix Modeling (MMM) für Ihre Marketingsegmente verfügbar ist, können Sie prüfen, ob der ausgewählte MDE realistisch ist. Dazu können Sie den „designimplizierten CpIC“ mit dem „geschätzten CpIC“ vergleichen.

Um diesen Vergleich zu vereinfachen, können Sie die folgenden drei Hauptmesswerte heranziehen (auch im folgenden Diagramm dargestellt). Sie zeigen, dass Ihre Media-Ausgaben und die Reaktion einer konkaven Kurve für die ROAS (Return on Advertising Spend) folgen:

• Cost-per-Action (CPA): Ihre Standardkosten pro Conversion, entspricht den Ausgaben ($S$) / Conversions ($C$). Die Gesamtzahl der Conversions umfasst hier sowohl zusätzliche als auch nicht zusätzliche Conversions. Beispiel: Organische Conversion-Ereignisse ohne bezahlte Medien.
• Elastizität: Entspricht \(\frac{\Delta C / C}{\Delta S / S}\) im Diagramm. Sie ist ein Maß dafür, wie empfindlich Ihre Conversions auf Änderungen der Ausgaben reagieren, und kann aus früheren Tests oder MMM abgeleitet werden.
  • Bei Go-dark-Tests, bei denen $\Delta S = -100\% * S$ ist, wird die Elastizität im Wesentlichen zu $-\Delta C / C$, der erwarteten relativen Steigerung Ihrer Studie.
• Kosten pro zusätzlicher Conversion (CpIC): Entspricht $\Delta S / \Delta C$. Das sind die tatsächlichen Kosten für jede zusätzliche Conversion, die durch die Änderung der zusätzlichen Ausgaben aufgrund Ihrer Marketingmaßnahme generiert wurde.

Ein gut konzipierter Test sorgt dafür, dass der designimplizierte CpIC, der als Budget geteilt durch die mindestens erforderlichen zusätzlichen Conversions berechnet wird, mit dem theoretischen CpIC übereinstimmt, der als CPA geteilt durch die Elastizität berechnet wird. Idealerweise sollte der designimplizierte CpIC nicht niedriger als der geschätzte CpIC sein, damit der Test ausreichend aussagekräftig ist.

Extrahieren Sie den aus dem Design abgeleiteten CpIC für das ausgewählte Design des Tests mit einer einzelnen Zelle:

select_design = single_cell_design_set.designs[single_cell_selected_design_id]
select_design.designs['cell_1'].design_implied_cpic

Zusammenhang zwischen Budget, MDE und designimplizierten CpIC verstehen

Häufig herrscht Unklarheit darüber, wie sich eine Anpassung des Budgets auf die Empfindlichkeit des Tests auswirkt.

• Der MDE ist unabhängig vom Budget: Der statistische MDE (die minimale prozentuale Änderung der Conversions, die im Test erkannt werden kann) wird ausschließlich durch die historische Volatilität und den geografischen Abgleich bestimmt. Wenn Sie das Budget nur in Constraints ändern, wird dieses statistische Limit nicht geändert.
• Budget bestimmt den designimplizierten CpIC: Während der MDE (die erforderliche prozentuale Steigerung) konstant bleibt, ändert sich der designimplizierte CpIC proportional zum Budget:
  • Höheres Budget: Führt zu einem höheren (weniger effizienten) designimplizierten CpIC. So erhöht sich die Wahrscheinlichkeit eines aussagekräftigen Tests für Kampagnen mit mäßiger Leistung.
  • Niedrigeres Budget: Das Design wird auf einen sehr niedrigen (hocheffizienten) designimplizierten CpIC beschränkt. Wenn die tatsächliche Kampagnenleistung mäßig statt hocheffizient ist, ist der Test möglicherweise nicht aussagekräftig.

Wenn kein Design-Output zu Ihrem Messziel passt

Es ist möglich, dass selbst nach unserer Designoptimierung der niedrigste MDE der besten Designvarianten für Ihr Szenario noch zu hoch ist. In der Regel bedeutet das, dass Ihre Testkampagnen nicht mit einem ausreichenden Budget ausgeführt werden, um GeoX zu unterstützen. Dies basiert auf den von Ihnen angegebenen Testeinstellungen und dem inhärenten Rauschen in Ihren KPI-Daten. Zuerst sollten Sie das Parameterbudget in geox.Constraints() explizit erhöhen. Möglicherweise müssen Sie die Testkonfigurationen anpassen, nachdem Sie das Testbudget mit einer der folgenden beiden Optionen erhöht haben:

• Sie können die Dauer der Studie verlängern, indem Sie experiment_duration in geox.DesignConfig() ändern.
• Sie können die bestehende Dauer beibehalten, aber den Parameter max_conversions_percent in geox.Constraints() erhöhen. Das bedeutet, dass ein höherer Prozentsatz der geografischen Einheiten von Ihrer Intervention betroffen ist.

Bei beiden Ansätzen können Sie versuchen, durch Aktualisieren der Testkonfigurationen ein höheres Volumen an zusätzlichen Conversions zu erzielen. Sie können den Test auch so gestalten, dass andere Conversion-Ziele im oberen Trichterbereich berücksichtigt werden, z. B. Seitenaufrufe oder das Hinzufügen von Artikeln zum Einkaufswagen, sofern diese Conversions im oberen Trichterbereich auch von Ihren Kampagnen beeinflusst werden. Dadurch kann ein größeres Datenvolumen bereitgestellt werden, was zu einem niedrigeren MDE führen kann.

Eine weitere Möglichkeit besteht darin, das tägliche Kampagnenbudget direkt zu erhöhen. Es wird jedoch nicht empfohlen, das Budget direkt während des Tests heraufzusetzen, da dies der Annahme widerspricht, dass Kontrollregionen stets unter BAU-Bedingungen (Business as usual) verbleiben sollten. Falls Sie das Kampagnenbudget erhöhen müssen, empfiehlt es sich, zuerst das Budget heraufzusetzen und dann zu warten, bis genügend Daten für das Pre-Test-Design unter dem neuen BAU vorliegen. Erst danach sollten Sie ein neues Studiendesign erstellen und mit dem eigentlichen GeoX-Test fortfahren.

Tests für saisonale Spitzenzeiten optimieren

Wenn Sie GeoX während saisonaler Spitzenzeiten wie den Feiertagen im 4. Quartal oder großen Verkaufsaktionen ausführen, kann das zu Problemen wie hoher Volatilität und kommerziellen Einschränkungen führen (z. B. „unantastbare“ Zeiträume, in denen Medien nicht deaktiviert werden können). Hier finden Sie Richtlinien dazu, wie Sie Ihre Tests in diesen Zeiträumen strukturieren sollten.

Umgang mit „unantastbaren“ Spitzenzeiten oder kommerziellen Einschränkungen

Wenn Ihr Unternehmen es sich nicht leisten kann, die Werbung in wichtigen Märkten während einer Hauptverkaufszeit zu deaktivieren:

• Heavy-up-Strategie statt Go-dark-Strategie verwenden:
  • Testen Sie nicht den Wert von Ausgaben im Vergleich zu Null-Ausgaben (Go-dark), sondern die marginalen Auswirkungen zusätzlicher Ausgaben.
  • Behalten Sie das geplante Basisbudget (BAU) in den Kontrollregionen bei und erhöhen Sie die Ausgaben in den Testregionen weiter (z. B. um +20 % bis +50 %). So können Sie die Spitzennachfrage in allen Märkten abdecken und gleichzeitig die inkrementelle Steigerung der zusätzlichen Investition messen.
• Partielles Go-dark verwenden, um das Risiko zu minimieren:
  • Ein partielles Go-dark, manchmal auch als Go-dim bezeichnet, testet die Grenzeffizienz – also den ROI Ihres letzten oder obersten Budgetteils durch eine teilweise Reduzierung (z. B. Senkung der Ausgaben um 20 % in den Testregionen). So wird das Umsatzrisiko in Spitzenzeiten minimiert, während die Steigerung dieses bestimmten Budgetteils weiterhin gemessen wird. Beachten Sie, dass hierbei nicht die gesamte Referenz-Effizienz gemessen wird. Diese vergleicht die BAU-Ausgaben mit Null-Ausgaben und setzt einen vollständigen Go-dark-Test voraus.

Zeitfenster für Tests vor und nach saisonalen Spitzenzeiten verwalten

Die Übergangsphasen zu Beginn und am Ende saisonaler Spitzenzeiten sind häufig durch schnelle Veränderungen im Nutzerverhalten und in der Gebotsdynamik der Plattform geprägt. So sorgen Sie für Modellstabilität:

• Testübergänge während Spitzenzeiten vermeiden: Achten Sie darauf, dass Start- und Enddatum des Tests nicht direkt in eine Phase mit starken Veränderungen fallen (beispielsweise sollte ein Test nicht am Tag vor dem Black Friday beginnen). Das Modell ist am stabilsten, wenn die Beziehung zwischen Test- und Kontrollregionen konsistent ist.
  • Test frühzeitig starten: Implementieren Sie die Budgetaufteilungen (Go-dark oder Heavy-up) einige Wochen vor Beginn des saisonalen Übergangs. So hat der Gebotsalgorithmus der Werbeplattform Zeit, sich mit den neuen geografischen Budgets zu stabilisieren, bevor das Spitzenvolumen erreicht wird.
  • Test spät beenden: Führen Sie den Test über die gesamte Spitzenzeit hinweg fort und kehren Sie erst dann zum Normalbetrieb (BAU) zurück, wenn sich das Volumen wieder auf normalem Niveau stabilisiert hat.
• Pre-Test-Daten für die Validierung erweitern: Bei stark saisonalen Unternehmen reichen die mindestens erforderlichen \( 3N \) Pre-Test-Daten in der Regel nicht aus. Bereiten Sie Verlaufsdaten für mindestens ein Jahr vor, um Ihr Design zu validieren.
• Design anhand historischer Spitzen validieren (Placebo-Tests):
  • Führen Sie vor dem eigentlichen Test die Designsuche durch und nutzen Sie dabei Verlaufsdaten aus demselben saisonalen Höhepunkt des Vorjahres als Validierungszeitraum.
  • Stellen Sie sicher, dass die Designvariante A/A-Placebo-Tests (p-Wert\( \ge \alpha \)) besteht und während dieses historischen Höhepunkts eine gute Anpassungsgüte (\( R^2 \ge 0.8 \)) aufweist. Falls dieser Test fehlschlägt, ist die Korrelation zwischen Ihren Regionen in Phasen mit hohem Datenaufkommen instabil – in diesem Fall sollten Sie keine Tests während der Spitzenzeiten durchführen.