Zum Hauptinhalt springen
Der Hybridmodus ermoeglicht es Ihnen, die Kameleoon-Web-Engine und ein serverseitiges SDK zu kombinieren, sodass jede Aufgabe die am besten geeignete Integration verwendet.
  • Implementieren und stellen Sie Variationen einfacher auf der Serverseite bereit, waehrend das Tracking zu Drittanbieter-Analysetools effektiver mit der Kameleoon-Engine ueber die Anwendungsdatei engine.js (frueher kameleoon.js genannt) durchgefuehrt werden kann, da viele Drittanbieter-Webanalyseloesungen nur im Frontend funktionieren.
  • Zielen Sie auf Benutzer ab, indem Sie clientseitig gesammelte Daten verwenden, wie z. B. Zielkonversionen oder benutzerdefinierte Daten basierend auf Variablen der Datenschicht, innerhalb von Segmenten.
  • Filtern und gliedern Sie Daten in Kameleoon-Berichten anhand von mehr als 25 Datenpunkten, die clientseitig von der Frontend-Anwendungs-Engine erfasst werden.
  • Schliessen Sie Benutzer von einem Feature Flag aus, wenn sie einem Web-Experiment oder einer Personalisierung ausgesetzt waren.
Dieser Artikel beschreibt, wie die optimale Integration zwischen dem Kameleoon Web-SDK und der Kameleoon Frontend-Anwendungsdatei implementiert wird, sodass beide Seiten miteinander kommunizieren. Verwenden Sie das Kameleoon Asynchronous Tag ohne Anti-Flicker.
Bei Web Experimentation muessen Sie normalerweise das JavaScript-Installations-Tag entweder im <head>-Tag oder am Anfang des <body>-Tags einfuegen, um Flickering zu verhindern. Wenn Sie den Hybridmodus verwenden, in dem Flickering kein Problem ist, koennen Sie das Skript an beliebiger Stelle vor dem schliessenden </body>-Tag einfuegen, da das Tag nur fuer Tracking-Zwecke verwendet wird.
Hybride Experimentation ist derzeit nur mit den Web-SDKs kompatibel. Waehrend die Mobile-SDKs den Hybridmodus mit Drittanbieter-Webanalysetools noch nicht unterstuetzen, koennen auf der Website gesammelte Datenpunkte dennoch genutzt werden, wenn sowohl eine Website als auch eine mobile App angeboten werden. Das bedeutet, dass Daten, die von einem identifizierten Benutzer auf der Website gesammelt wurden, auch in der mobilen Anwendung verwendet werden koennen, sofern der Besucher auf beiden Plattformen konsistent identifiziert wird.

​
Benutzer-IDs zwischen Back-End und Front-End synchronisieren​

Eine der Herausforderungen des Hybridmodus besteht darin, sicherzustellen, dass Kameleoon jeden Besucher auf beiden Seiten korrekt als dieselbe Person identifizieren kann. In Kameleoon bedeutet diese Anforderung, dass der visitorCode, der eine eindeutige ID fuer jeden Besucher ist, auf beiden Seiten identisch sein muss. Beispielsweise muss ein Besucher, der mit dem visitorCode 10ctbql0zpf4rwjy fuer eine Experimentvariation im Backend registriert ist, mit dem Visitor-Code 10ctbql0zpf4rwjy verknuepft sein, wenn im Frontend eine Conversion ausgeloest wird. Die Verwendung derselben ID gewaehrleistet ein korrektes Tracking der Aktionen des Besuchers, was zu korrekten Daten und Statistiken fuehrt. Um die Benutzer-IDs zu synchronisieren, muss Ihre Hybrid-App die Methode getVisitorCode() aufrufen, bevor andere SDK-Methoden aufgerufen werden. Da Namenskonventionen zwischen Sprachen variieren, variieren die Methodennamen je nach SDK leicht, aber jede Sprache verfuegt ueber eine aehnlich benannte Aequivalentmethode. Kameleoon verwendet den folgenden Ansatz:
  1. Im Frontend generiert die Kameleoon-JavaScript-Engine fuer jeden neuen Besucher zufaellig einen visitorCode. Die Engine betrachtet einen Besucher als neu, wenn sie keinen vorherigen Visitor-Code im Browser des Benutzers finden kann (z. B. in einem Cookie oder Local Storage). Dies geschieht normalerweise, wenn die Kameleoon-Engine zum ersten Mal im Browser des Besuchers ausgefuehrt wird. Die Kameleoon-Engine kann den Bezeichner auch aus einem Cookie beziehen, das ihr vom Backend uebergeben wird. Diese Option ermoeglicht es Ihnen, den Bezeichner auf dem Server festzulegen, anstatt im Frontend. Verwenden Sie diese Option beispielsweise, wenn Sie Ihren eigenen eindeutigen Visitor-Code fuer jeden Besucher angeben moechten.
Wenn Sie Sitzungsdaten subdomainuebergreifend vereinheitlichen, sucht Kameleoon nach einem Schluessel kameleoonVisitorCode im Local Storage. Wenn der Schluessel vorhanden ist, wird sein Wert als Bezeichner fuer den Visitor-Code verwendet. Die Local-Storage-Version dieses Schluessels hat immer Vorrang, auch wenn ein kameleoonVisitorCode-Cookie mit einem anderen Wert existiert. Beachten Sie, dass Kameleoon das JavaScript-Cookie nicht zuruecksetzt, wenn die Local-Storage- und Cookie-Werte uebereinstimmen. Aus ITP-Gruenden ist es wichtig, Cookies, die moeglicherweise serverseitig gesetzt wurden, unveraendert zu lassen.
  1. Im Backend muessen Sie die Methode getVisitorCode() oder die entsprechende Methode in Ihrem SDK aufrufen. Stellen Sie sicher, dass Sie diese Methode aufrufen, bevor Sie einen Besucherbezeichner an eine andere SDK-Methode uebergeben. getVisitorCode() akzeptiert ein optionales String-Argument, mit dem Sie Ihren eigenen Bezeichner uebergeben koennen, anstatt sich auf eine zufaellig generierte Kameleoon-ID zu verlassen. Wenn die Methode aufgerufen wird, sucht Kameleoon zuerst nach einem kameleoonVisitorCode-Cookie oder Query-Parameter, der der aktuellen HTTP-Anfrage zugeordnet ist. Wird er gefunden, verwendet das SDK diesen Wert als Besucherbezeichner.
Wenn kein Cookie oder Parameter gefunden wird, verwendet Kameleoon das Argument der Methode getVisitorCode(), sofern Sie eines angegeben haben, als Bezeichner. Wenn Sie kein Argument angeben, generiert Kameleoon die ID zufaellig. In beiden Faellen setzt Kameleoon auch das serverseitige kameleoonVisitorCode-Cookie mit dem Wert (ueber einen HTTP-Header). Durch diesen Ansatz wird der visitorCode gespeichert und zwischen Frontend und Backend geteilt. Wenn ein Experiment auf der ersten Seite der Reise eines Besuchers auf Ihrer Website implementiert ist, generiert das SDK den Bezeichner und uebergibt ihn an die JavaScript-Engine. Wenn die Reise auf einer Seite beginnt, auf der getVisitorCode() nicht aufgerufen wird (oder das Synchronisations-Snippet im Backend nicht ausgefuehrt wird), generiert die JavaScript-Engine den Bezeichner zuerst und uebergibt ihn an das SDK. Das SDK liest ihn und schreibt ihn dann als serverseitiges Cookie um, um ITP-Beschraenkungen zu umgehen.

​
Feature-Experimente mit Frontend-Tracking-Code verknuepfen​

Es ist oft sinnvoll, Experimentvariationen mit einem SDK einzurichten, das Tracking jedoch im Frontend mit der JavaScript-Engine zu implementieren. Dies ist aus folgenden Gruenden ein haeufiges Szenario:
  • Webanalyseplattformen (wie Mixpanel oder Google Analytics 4) werden tendenziell im Frontend implementiert.
  • Ein standardmaessiger clientseitiger Tagging-Plan fuer Kameleoon mit Web Experimentation ist moeglicherweise bereits in Gebrauch.
  • Das Tracking von Ereignissen und Datenpunkten auf der Frontend-Seite zu Analysezwecken mit Reporting ist oft bequemer.
  • Es gibt Datenpunkte, die fuer den Einsatz in Feature-Experimenten geeignet sind und im Frontend leichter zu erfassen sind.

​
Expositions-Events an Drittanbieter-Analytics senden​

Kameleoon bietet native Integrationen mit Analyse- und CDP-Plattformen. Im Hybridmodus koennen Sie jede dieser Integrationen in Kombination mit Feature-Experimenten verwenden, ohne zusaetzlichen Code schreiben zu muessen. Die Frontend-Engine muss wissen, wann ein Experiment im Backend stattgefunden hat, d. h. wann ein Besucher in ein Experiment eingebucht wurde. Dadurch wird sichergestellt, dass nur Besucher gezaehlt werden, die das Experiment tatsaechlich ausgeloest und gesehen haben. Um dieses Ziel zu erreichen, verwenden Sie die Methode getEngineTrackingCode() (der Name variiert je nach SDK leicht), die in allen serverseitigen SDKs verfuegbar ist. Diese Methode gibt den JavaScript-Code zurueck, der in die Seite eingefuegt werden soll, um die Expositions-Events automatisch vom Frontend an die verwendete Analyseloesung zu senden. Er kann in die zurueckgegebene HTML-Seite eingebettet werden. Zum Beispiel: 
<!DOCTYPE html>
<html lang="en">
  <body>
    <script>
      const engineTrackingCode = `
        window.kameleoonQueue = window.kameleoonQueue || [];
        window.kameleoonQueue.push(['Experiments.assignVariation', 123456, 7890]);
        window.kameleoonQueue.push(['Experiments.trigger', 123456, true]);
      `;
      const script = document.createElement('script');

      script.textContent = engineTrackingCode;
      document.body.appendChild(script);
    </script>
  </body>
</html>
Sie muessen auch Ihre gewaehlte Integration (z. B. Google Analytics 4 oder Mixpanel) bei der Konfiguration Ihres Feature-Experiments aktivieren. Die relevanten Daten (z. B. Experiment-ID, Experimentname, Variations-ID, Variationsname) werden automatisch von der Kameleoon-JavaScript-Engine an die Drittanbieterplattform gesendet.

​
Frontend-Datenpunkte und -Ereignisse in Feature-Experimenten verwenden​

Wenn Sie Kameleoon im Hybridmodus implementiert haben, werden Ziele und Datenpunkte automatisch im Frontend verfolgt und erscheinen in Kameleoon-Berichten als Filter- und Aufschluesselungskriterien. Darueber hinaus stehen im Kameleoon-SDK mehrere Targeting-Bedingungen zur Verfuegung, die fuer Targeting-Zwecke verwendet werden koennen.

​
Einwilligungsverwaltung im Hybridmodus​

Wenn Sie Kameleoon im Hybridmodus verwenden und die Einwilligung auf “Required” gesetzt ist, stellen Sie sicher, dass sowohl die JavaScript-Aktivierungs-API als auch SDK-Methoden bei der Erfassung der Einwilligung aufgerufen werden, damit Kameleoon Benutzerereignisse sowohl aus der Kameleoon-Anwendungsdatei als auch aus dem SDK sammeln kann. Da Kameleoon zudem daran gehindert ist, den visitorCode-Schluessel in einem Cookie zu speichern, stellen Sie sicher, dass der vom SDK fuer alle ersten Anfragen generierte visitorCode-Schluessel mit der clientseitig laufenden Kameleoon-Engine geteilt wird. Lesen Sie die technischen Ueberlegungen.
Einwilligungsinformationen werden zwischen der Kameleoon-Engine (engine.js) und dem JavaScript-SDK nur synchronisiert, wenn eine der beiden Komponenten neu initialisiert wird (z. B. beim Neuladen der Seite oder beim Aufruf von API.Core.load). Daher empfehlen wir dringend, die Einwilligung mit den dedizierten Methoden, die von der Engine und dem SDK bereitgestellt werden, explizit zu verwalten, anstatt sich auf diesen Synchronisationsmechanismus zu verlassen.