> ## 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.

# SDKs plattformuebergreifend koordinieren

> Bewahren Sie eine einheitliche Besucher-Identitaet und eine konsistente Experiment-Behandlung, wenn Sie Kameleoon SDKs gleichzeitig auf Web-, Mobil- und Backend-Plattformen einsetzen.

Koordinieren Sie Kameleoon SDKs ueber Websites, mobile Apps und Backend-Server hinweg, um eine einheitliche Besucher-Identitaet beizubehalten. Diese Koordination gewaehrleistet eine konsistente Experiment-Behandlung und einen einheitlichen Datenfluss ueber alle Plattformen hinweg.

Verwenden Sie diese Anleitung, wenn ein Projekt mehrere Kameleoon SDKs implementiert:

* Das JavaScript SDK oder `engine.js` fuer Web-Umgebungen.
* Das mobile SDK fuer Android- oder iOS-Apps.
* Serverseitige SDKs fuer Backend-Integrationen und Entscheidungslogik.

## Architekturuebersicht

Eine typische Multi-Umgebungs-Einrichtung umfasst die folgenden Komponenten:

* **Website**: Verwendet das JavaScript SDK oder `engine.js`, um clientseitige Experimente und Personalisierungskampagnen auszufuehren.
* **Mobile App**: Verwendet ein mobiles SDK, um Variationen anzuzeigen und Conversions zu verfolgen.
* **Backend-Server**: Verwendet ein serverseitiges SDK, um zentrale Variationsentscheidungen zu treffen oder Besucherdaten zu synchronisieren.

## Daten- und Visitor-Code-Fluss

* Der **Visitor-Code** identifiziert Benutzer konsistent ueber alle Umgebungen hinweg.
* Das **serverseitige SDK** koordiniert bei Bedarf die Variationsentscheidungen.
* Jedes SDK sendet Analyse- und Tracking-Daten direkt an die Kameleoon-Plattform.

## Visitor-Code und geraeteuebergreifende Verwaltung

### Visitor-Codes generieren und teilen

Jeder eindeutige Besucher muss einen konsistenten Visitor-Code auf allen Plattformen haben. Dieser Code ermoeglicht es Kameleoon, Experiment-Entscheidungen und Tracking zu vereinheitlichen.

Folgen Sie diesem plattformuebergreifenden Ablauf:

1. Die Engine, das Web-SDK, das serverseitige SDK oder die mobile Anwendung generiert den Visitor-Code.
2. Das Backend ruft den bestehenden Visitor-Code ab, wenn sich der Benutzer auf einer neuen Plattform anmeldet.
3. Das System uebergibt den Visitor-Code an die mobilen, serverseitigen und Web-SDKs. Dies stellt sicher, dass alle Plattformen denselben Benutzer konsistent bewerten.

### Visitor-Codes synchronisieren

* Speichern Sie den Visitor-Code sicher im Backend oder in der Benutzerdatenbank und verknuepfen Sie ihn mit der Benutzer-ID.
* Folgen Sie diesen Schritten, wenn eine Benutzeranmeldung auf einer anderen Plattform erfolgt:
  * **Mobile App**: Fordern Sie den Visitor-Code beim Backend an.
  * **Serverseitiges SDK**: Verwenden Sie denselben Visitor-Code fuer alle Variations- und Tracking-Aufrufe.
  * **Web-SDK**: Setzen Sie den Visitor-Code mit der JavaScript-API:

```javascript theme={null}
kameleoon.API.Visitor.setVisitorCode(visitorCode);
```

<Note>
  Das Web-SDK und das serverseitige SDK kommunizieren automatisch ueber das Cookie `kameleoonVisitorCode`. Sie muessen keine zusaetzlichen Schritte ausfuehren, um diese beiden zu verknuepfen.
</Note>

### Best Practices

* Ordnen Sie die bestehende Benutzerkennung (z. B. `userId`) einem einzigen Kameleoon Visitor-Code auf allen Plattformen zu.
* Behalten Sie das Backend als verlaessliche Quelle fuer Visitor-Codes bei.
* Verhindern Sie, dass SDKs vorhandene Visitor-Codes bekannter Benutzer ueberschreiben.

Eine einheitliche Identifikation stellt sicher, dass jede Benutzeraktion, jede Conversion und jede Variationsentscheidung mit demselben Besucher in Kameleoon verknuepft wird.

## Experiment-Behandlung in verschiedenen Umgebungen

Koordinieren Sie Entscheidungen und Variationsanzeigen fuer Experimente, die mehrere Umgebungen umfassen, etwa Mobile und Backend.

### Beispielszenario

In diesem Szenario:

* Die **mobile App** zeigt die Variation an.
* Der **Backend-Server** bestimmt die zugewiesene Variation.

#### Implementierungsoptionen

**Option 1: Serverseitige Entscheidungslogik**

1. Die **mobile App** sendet den Visitor-Code an das Backend.
2. Das **serverseitige SDK** ruft `getVariation()` (oder das Aequivalent) auf, um die zugewiesene Variation abzurufen.
3. Das Backend gibt die Variations-ID oder den Namen an die mobile App zurueck.
4. Die **mobile App** zeigt die Variation an und verfolgt die Exposition.
5. Sowohl das **mobile** als auch das **Server-SDK** verwenden denselben Visitor-Code fuer das Event-Tracking.

**Vorteile:**

* Zentralisiert die Variationslogik und gewaehrleistet konsistente Entscheidungen.
* Unterstuetzt Experimente, die sowohl die Backend-Logik als auch UI-Elemente beeinflussen.

**Option 2: Clientseitige (mobile) Entscheidungslogik**

1. Das **mobile SDK** ruft die Variationszuweisung mithilfe des Visitor-Codes ab.
2. Die mobile App wendet die Variation lokal an und verfolgt die Exposition direkt.
3. (*Optional*) Wenn das Backend ebenfalls am Tracking oder an der Validierung beteiligt ist, verwendet das **serverseitige SDK** denselben Visitor-Code, um eine konsistente Berichterstattung sicherzustellen.

**Vorteile:**

* Liefert eine synchrone Entscheidung ohne Latenz.
* Reduziert die Latenz, indem ein Server-Roundtrip vermieden wird.
* Optimiert UI-fokussierte Experimente, die nicht von der Backend-Logik abhaengen.

## Die richtige Einrichtung waehlen

| Anwendungsfall                       | Entscheidungsebene | Quelle des Visitor-Codes | Hinweise                              |
| :----------------------------------- | :----------------- | :----------------------- | :------------------------------------ |
| **Mobiles UI-Experiment**            | Mobile SDK         | Backend                  | Variation wird lokal behandelt        |
| **Backend- oder API-gesteuert**      | Serverseitiges SDK | App oder Website         | Zentrale Entscheidungslogik           |
| **Geraeteuebergreifende Konsistenz** | Beliebig           | Backend                  | Gewaehrleistet einheitliches Tracking |

## Codebeispiele: Visitor-Code zwischen den Ebenen weitergeben

<CodeGroup>
  ```javascript Web (JS) theme={null}
  const visitorCode = kameleoon.API.Visitor.code;
  fetch("/api/syncVisitor", {
    method: "POST",
    body: JSON.stringify({ visitorCode }),
  });
  ```

  ```swift Mobile (iOS) theme={null}
  let kameleoonClient = try KameleoonClientFactory.create(
      siteCode: siteCode, 
      visitorCode: visitorCodeFromBackend
  )
  let variation = try kameleoonClient.getVariation(featureKey: featureKey)
  ```

  ```python Server (Python) theme={null}
  client = KameleoonClientFactory.create(SITE_CODE, config)
  variation = client.get_variation(visitor_code, feature_key)
  ```
</CodeGroup>

***

Um die SDK-Implementierung ueber verschiedene Ebenen hinweg zu handhaben:

* Weisen Sie jedem Benutzer auf allen Plattformen einen einzigen Visitor-Code zu.
* Verwalten und verteilen Sie Visitor-Codes vom Backend aus.
* Waehlen Sie die Variationslogikebene basierend auf dem Experimenttyp aus (Server fuer zentrale Logik, clientseitig fuer App-gesteuerte UI).
* Behalten Sie konsistente, geraeteuebergreifende Daten bei, indem Sie die gesamte Benutzeraktivitaet mit demselben Visitor-Code verfolgen.