> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Tools für Experimente

> MCP-Tools zum Erstellen, Konfigurieren, Starten und Auswerten von Web Experiments.

Die Tools für Experimente decken den gesamten Lebenszyklus eines Web Experiments ab. Ihr KI-Assistent kann einen Test erstellen, den Code für jede Variation schreiben, die Traffic-Verteilung und die Ziele festlegen, den Test starten und seinen Zustand sowie seine Ergebnisse prüfen.

## Tools

| Tool | Beschreibung | Beispielprompt |
| - | - | - |
| `experiment_list` | Experimente nach Name oder ID finden oder nur die Experimente mit einem bestimmten Status auflisten, etwa die Experimente im Status running. Gibt paginierte Zusammenfassungen zurück (ID, Name, Status und Tags). | "List running experiments on site `d1alzzxd7k`." |
| `experiment_get` | Die vollständige Konfiguration eines Experiments abrufen: Variationen, Traffic-Verteilung, Ziele und Targeting. | "Show the configuration for experiment `149640`." |
| `experiment_code_get` | Den rohen JavaScript-, CSS- und benutzerdefinierten JSON-Code einer Variation abrufen, dazu den gemeinsamen JavaScript- und CSS-Code des Experiments. | "Pull the code for variation 1 of experiment `149640`." |
| `experiment_results_get` | Statistische Ergebnisse für jedes angehängte Ziel abrufen: Conversion-Raten je Variation, Signifikanz, Konfidenzintervalle und den Gewinner. Optional lassen sich die Ergebnisse mit `breakdown` aufteilen und mit `filters`, `dateFrom` und `dateTo` eingrenzen. Außerdem wählen Sie die `statisticalMethod`, den `conversionType` und die `referenceVariationId`. | "Summarize results for experiment `149640`." |
| `experiment_create` | Ein Draft-Experiment erstellen (Typ, Basis-URL, Ziele, optional gemeinsamer Code). Es enthält eine erste Variation und eine Targeting-Regel. | "Create a CLASSIC experiment `Homepage hero` on site `d1alzzxd7k`." |
| `experiment_variation_create` | Einem bestehenden Experiment eine Variation mit eigenem JavaScript, CSS, benutzerdefiniertem JSON oder eigenen Weiterleitungseinstellungen hinzufügen. Draft-Experimente verteilen den Traffic gleichmäßig. Ein Experiment im Status running startet die neue Variation mit 0 %. | "On experiment `149640`, add a variation that makes the `#buy-now` button green." |
| `experiment_variation_update` | Den Code, den Namen oder die Weiterleitung einer Variation ändern. Es ändern sich nur die übergebenen Felder, und ein wiederholter Aufruf mit denselben Werten ändert nichts. | "In variation 1 of experiment `149640`, make the `#buy-now` button red." |
| `experiment_update` | Die Einstellungen eines bestehenden Experiments ändern: Name, Beschreibung, Basis-URL, Tags, Ziele und Hauptziel, gemeinsames JavaScript und CSS, globales Skript, Datenerfassung, ob gemeinsamer Code auch auf der Originalseite läuft, die Korrektur für multiples Testen und die Methode der Traffic-Verteilung. Verwenden Sie das Tool, um das Ziel anzuhängen, das ein Experiment für den Start benötigt. Es ändern sich nur die übergebenen Felder. Eine Bestätigung ist erforderlich, wenn das Experiment kein Draft ist. | "On experiment `149640`, set goal `271552` as the main goal." |
| `experiment_traffic_allocation_set` | Die Traffic-Verteilung der Originalseite und jeder Variation festlegen. Draft-Experimente ändern sich sofort. Experimente im Status scheduled oder paused benötigen eine Bestätigung, und die neue Verteilung gilt, sobald sie starten oder fortgesetzt werden. Die Verteilung von Experimenten im Status running, deviated und stopped ändern Sie in der Kameleoon-App. | "On experiment `149640`, split traffic 50/50 between the original and variation 1." |
| `experiment_duplicate` | Ein Experiment als neues Draft-Experiment klonen, wobei Variationen, Code, Abweichungen und Targeting kopiert werden. | "Duplicate experiment `149640`." |
| `experiment_health_check_get` | Die Prüfungen des Health-Tabs für ein Experiment ausführen: Visit- und Conversion-Tracking je Ziel, Sample Ratio Mismatch und überlappende Exposition. Gibt einen Gesamtstatus zurück, mit einem Befund und einem nächsten Schritt für jede Prüfung. | "Is experiment `149640` healthy? Are its results reliable?" |
| `experiment_lifecycle_update` | Den Lebenszyklus steuern: starten, pausieren, fortsetzen, stoppen oder löschen (Stoppen und Löschen erfordern eine Bestätigung). Zum Starten braucht ein Experiment ein Ziel, Variationen und eine Traffic-Verteilung. Sie können Experimente im Status running oder scheduled pausieren und Experimente im Status running, scheduled oder paused stoppen. Gelöscht werden können nur Draft-Experimente oder Experimente im Status stopped. | "Start experiment `149640`." |
| `transpose_winning_experiment` | Ein Tool mit einem einzigen Einstiegspunkt: Es ruft den Code einer gewinnenden (oder manuell ausgewählten) Variation ab, wendet die Logik zur Gewinnerentscheidung an und gibt Anweisungen für den aufrufenden Agenten zurück, die Variation neu umzusetzen und hinter einem neuen Feature Flag zu schalten. Ein einziger Aufruf ersetzt den früheren mehrstufigen manuellen Prompt-Workflow. | "Implement the winning variant of experiment `373001` as a feature flag." |

> [!NOTE]
>
> `experiment_create` akzeptiert `MVT` und `SDK_HYBRID` als gültige `type`-Werte, dieses Tool kann jedoch keines der beiden erstellen. `MVT` schlägt immer fehl, weil die API bei der Erstellung `mvtVariations` (Sections und Variationen) erwartet und kein MCP-Tool dieses Feld bereitstellt. `SDK_HYBRID` schlägt immer mit dem Fehler „Incorrect Experiments type“ fehl, unabhängig vom Payload. `AI`, `CLASSIC`, `DEVELOPER` und `PROMPT` lassen sich erfolgreich erstellen. Um ein MVT-Experiment zu erstellen, rufen Sie die Automation API direkt auf und folgen Sie den Schritten unter [Ein Multivariate Test-Experiment erstellen](https://docs.kameleoon.com/de/developer-docs/apis/automation-api-rest/tutorials/experiments/creation/create-a-multivariate-experiment.md).

> [!NOTE]
>
> Die Tools für Variationen unterstützen keine Experimente im Status stopped, keine MVT-Experimente und keine Feature-Flag-Experimente. Für Feature-Flag-Variationen verwenden Sie `feature_flag_variation_create`. Die Traffic-Verteilung eines Experiments im Status running oder eines Experiments mit einer Bandit-Methode für die Traffic-Verteilung können Sie über den MCP-Server nicht ändern.

## Experimentzustand prüfen

Bitten Sie Ihren KI-Assistenten, die Prüfungen des Health-Tabs auszuführen, bevor Sie auf die Ergebnisse eines Tests reagieren.

* **Ist der Test in Ordnung?** `experiment_health_check_get` führt die Prüfungen des Health-Tabs aus: Visit- und Conversion-Tracking, Sample Ratio Mismatch und überlappende Exposition.

## Parameter

Verwenden Sie die exakten Parameternamen, die `tools/list` zurückgibt.

| Tool | Pflichtparameter | Optionale Parameter |
| - | - | - |
| `experiment_list` | Keine | `siteCode`, `filterQuery`, `status` (einer oder mehrere der Werte `active`, `deviated`, `draft`, `paused`, `scheduled`, `stopped`, `used_as_personalization`; Experimente im Status running entsprechen `active` und `deviated`), `page`, `perPage`, `sortField`, `sortOrder` |
| `experiment_get` | `experimentId` | Keine |
| `experiment_code_get` | `experimentId`, `variationId` | Keine |
| `experiment_results_get` | `experimentId` | `goalIds`, `audienceBasis` (standardmäßig `VISITORS`, oder `VISITS`), `includeRawReport`, `breakdown` (`DAY`, `WEEK`, `MONTH`, `HOUR`, `DEVICE_TYPE`, `BROWSER`, `OS` oder `NEW_VISITOR`), `filters` (eine Liste von Strings oder ein einzelner, durch `;` getrennter String im Format `DIMENSION=V1,V2` oder `DIMENSION!=V1,V2`), `dateFrom` und `dateTo` (`YYYY-MM-DD`), `statisticalMethod` (standardmäßig `FREQUENTIST`, sonst `SEQUENTIAL`, `BAYESIAN` oder `CUPED`), `conversionType` (standardmäßig `CONVERTED`, oder `ALL`), `referenceVariationId` (eine Variation-ID oder `0` für das Original) |
| `experiment_create` | `payload` (`siteCode`, `name`, `type`, `baseURL`) | `payload`: `mainGoalId`, `goals`, `tags`, `description`, `commonJavaScriptCode`, `commonCssCode`, `trafficAllocationMethod`, `collectingDataEnabled`, `multipleTestingCorrection`, `executeCodeForReference` |
| `experiment_variation_create` | `experimentId`, `name` | `jsCode`, `cssCode`, `customJson` (ein JSON-String), `isJsCodeAfterDomReady`, `shadowDom`, `redirection` (`type` ist erforderlich; `url` für `GLOBAL_REDIRECTION`; `parameters` für `PARAMETER_REDIRECTION`; `includeQueryParameters`, Standard `false`), `confirm` (erforderlich, wenn das Experiment kein Draft ist) |
| `experiment_variation_update` | `variationId` | `experimentId` (das Tool lehnt den Aufruf ab, wenn er nicht zum Experiment der Variation passt), `name`, `jsCode`, `cssCode` (ein leerer String leert das Feld), `customJson` (ein JSON-String), `isJsCodeAfterDomReady`, `shadowDom`, `redirection` (ersetzt die bestehenden Weiterleitungseinstellungen; `type` ist erforderlich), `confirm` (erforderlich, wenn das Experiment kein Draft ist) |
| `experiment_update` | `experimentId` | `name`, `description` (ein leerer Wert behält die aktuelle Beschreibung bei), `baseURL` (eine absolute `http`- oder `https`-URL), `tags` und `goals` (jeweils ersetzt die gesamte Liste), `mainGoalId`, `commonJavaScriptCode`, `commonCssCode`, `globalScript` (ein leerer String leert das Feld), `collectingDataEnabled`, `executeCodeForReference`, `multipleTestingCorrection`, `trafficAllocationMethod` (nicht, während das Experiment Traffic ausliefert, und nicht nach dem Stoppen), `confirm` (erforderlich, wenn das Experiment kein Draft ist) |
| `experiment_traffic_allocation_set` | `experimentId`, `originPercentage` (0 bis 100), `variationAllocations` (ein Eintrag für jede Variation, jeweils mit `variationId` und `percentage`; die Summe mit `originPercentage` darf 100 nicht überschreiten) | `respool` (Standard `false`), `confirm` (erforderlich für Experimente im Status scheduled und paused) |
| `experiment_duplicate` | `experimentId` | Keine |
| `experiment_health_check_get` | `experimentId` (bei einem Feature-Flag-Experiment die Experiment-ID der Regel) | Keine |
| `experiment_lifecycle_update` | `experimentId`, `status` | `confirm` (erforderlich für `stopped` und `deleted`), `reason` |
| `transpose_winning_experiment` | `experimentId` | `mode` (standardmäßig `strict_winner_only`, oder `manual_variation_conversion`), `fallbackVariationId` (erforderlich, wenn `mode` `manual_variation_conversion` ist), `targetFeatureKey` (standardmäßig `pbx-winning-experiment-<experimentId>`) |

**Zulässige Enum-Werte:** `experiment_lifecycle_update.status` ist `started`, `resumed`, `paused`, `stopped` oder `deleted`. Der Experiment-`type` ist `AI`, `CLASSIC`, `DEVELOPER`, `MVT`, `PROMPT` oder `SDK_HYBRID`. `trafficAllocationMethod` ist `MANUAL` (Standard), `MULTI_ARMED_BANDIT` oder `CONTEXTUAL_BANDIT`. `audienceBasis` ist `VISITORS` (Standard) oder `VISITS`.

### Einstellungen für Ergebnisse

Lesen Sie die Ergebnisse eines Experiments mit `experiment_results_get` aus.

Bei `experiment_results_get`, `feature_flag_experiment_results_get` und `transpose_winning_experiment` umfasst das Array `goalResults` jedes Ziel des Experiments, also primäre und sekundäre Ziele. Kameleoon ermittelt ein Gewinnerurteil nur für das primäre Ziel. Sekundäre Ziele liefern dieselben statistischen Kennzahlen wie Guardrail-Metriken, aber kein Urteil.

`experiment_results_get` und `feature_flag_experiment_results_get` akzeptieren die folgenden optionalen Einstellungen:

* `breakdown`: teilt die Ergebnisse auf. `DAY`, `WEEK` und `MONTH` zeigen einen Trend über die Zeit. `HOUR` zeigt einen Trend über ein Zeitfenster von `dateFrom` bis `dateTo` mit höchstens 2 Tagen. `DEVICE_TYPE`, `BROWSER`, `OS` und `NEW_VISITOR` liefern je Wert einen Eintrag. Die Einträge je Zeitraum enthalten nur Audience, Conversions und Conversion-Rate. Verbesserung und Zuverlässigkeit bleiben für den gesamten Lauf im Überblick.
* `filters`: eine Liste von Strings oder ein einzelner String mit `;` zwischen den Filtern. Kameleoon verknüpft die Filter mit UND. Jeder Filter hat das Format `DIMENSION=V1,V2` oder `DIMENSION!=V1,V2`. Die Dimensionen und Werte sind `DEVICE_TYPE` (`DESKTOP`, `TABLET`, `PHONE`), `BROWSER` (`CHROME`, `EDGE`, `FIREFOX`, `SAFARI`, `OPERA`, `OTHERS`), `OS` (`WINDOWS`, `MAC_OS`, `I_OS`, `LINUX`, `ANDROID`, `WINDOWS_PHONE`, `OTHERS`) sowie `NEW_VISITOR` (`NEW`, `RETURNING`). Eine Aufteilung nach `DEVICE_TYPE` kann einen Eintrag `OTHERS` zeigen, Sie können aber nicht nach `DEVICE_TYPE=OTHERS` filtern.
* `dateFrom` und `dateTo`: ein bestimmter Zeitraum als Datum im Format `YYYY-MM-DD` in der Zeitzone des Kontos. `dateTo` ist inklusive. Legen Sie diese Werte nur fest, wenn Sie einen bestimmten Zeitraum benötigen. Ein engeres Zeitfenster liefert ungenauere Zahlen, deshalb sollten Sie aus einem kurzen Zeitfenster keinen Gewinner ableiten.
* `statisticalMethod`: `FREQUENTIST` (Standard), `SEQUENTIAL`, `BAYESIAN` oder `CUPED`. Bei `BAYESIAN` wird `reliabilityRate` zur Wahrscheinlichkeit, die Referenz zu übertreffen. `CUPED` gilt nur für die Werte des gesamten Laufs, und die Einträge der Aufteilung bleiben frequentistisch. Das Tool lehnt eine Methode ab, die Ihr Kameleoon-Tarif nicht enthält.
* `conversionType`: `CONVERTED` (Standard) zählt jeden konvertierenden Besucher einmal. `ALL` zählt jede Conversion, sodass die Rate 100 % übersteigen kann. Verbesserung und Zuverlässigkeit folgen dieser Einstellung: Mit `ALL` vergleichen sie die Conversions pro Besucher.
* `referenceVariationId`: die Variation, mit der die anderen verglichen werden. Übergeben Sie eine Variation-ID oder `0` für das Original. Bei Feature Flags übergeben Sie eine Variation-ID oder einen Key oder `0` bzw. `off` für die Off-Variation. Standard ist die im Experiment gespeicherte Referenz oder das Original, falls das Experiment keine hat.

Die Antwort nennt die angewendeten Einstellungen in `appliedOptions` und ergänzt Hinweise, wo eine Zahl Kontext braucht. Die Antwort lässt Zahlen weg, die die Engine nicht berechnet hat, etwa wegen zu weniger Daten oder einer Referenz ohne Conversions, und ergänzt für jede dieser Zahlen einen Hinweis.

Die Ergebnisse vergleichen mit der im Experiment gespeicherten Referenz, wie es auch der Ergebnisbildschirm tut. Experimente, die Kameleoon aus einem Prompt erstellt, und Feature-Flag-Experimente, deren Off-Variation 0 % des Traffics erhält, liefern keine Verbesserung und keine Zuverlässigkeit.

## Anleitungen

* [Varianten mit benutzerdefiniertem Code erstellen](https://docs.kameleoon.com/de/mcp/create-variations-with-code.md): Erstellen Sie einen Test mit mehreren Variationen, die jeweils eigenen Code haben.
* [Ein Draft-Experiment vorbereiten](https://docs.kameleoon.com/de/mcp/prepare-draft-experiment.md): Legen Sie Ziel, Traffic-Verteilung und Targeting fest, bevor Sie starten.
* [Eine gewinnende Variante in die Produktion überführen](https://docs.kameleoon.com/de/mcp/ship-winning-variation.md): Verwandeln Sie eine gewinnende Variation in ein abgesichertes Feature Flag.
