Zum Hauptinhalt springen
Verwenden Sie das Kameleoon-Anwendungsskript fuer Web-Experimente, die mit dem grafischen oder Code-Editor erstellt wurden. Verwenden Sie das Web-SDK fuer Feature Flags und Feature-Experimente.Beachten Sie, dass Kameleoon im Hybridmodus laufen kann. Der Hybridmodus verwendet sowohl Web-SDKs als auch die Kameleoon-JavaScript-Anwendungsdatei. Der Hybridmodus ermoeglicht es Ihnen, fuer einzelne Aufgaben den optimalen Ansatz zu verwenden. Beispielsweise koennen Sie Variationen einfacher auf der Serverseite implementieren und bereitstellen, waehrend das Tracking effektiver mit der JavaScript-Datei durchgefuehrt werden kann.
Kameleoon verwendet waehrend der Initialisierung CDN-Server. Sobald die Konfiguration empfangen und gecacht ist, erfolgen Abruf und Aktualisierung schnell (50-70 ms je nach Latenz des Servers vom naechstgelegenen CDN).
Es gibt zwei Methoden, um die Konfiguration zu erhalten: Polling und Streaming.
Das Protokoll Server Side Events (SSE oder EventSource) wird verwendet.
Das CDN wird jedes Mal bereinigt, wenn Sie eine Feature-Flag-Konfiguration aktualisieren (z. B. Variationen, Traffic-Expositionen und Targeting) oder alle 24 Stunden.
Wenn Sie ein clientseitiges SDK verwenden und die Website das Laden von Ressourcen (Skripte, Bilder, Medien, CSS) ueber den standardmaessigen Content-Security-Policy-HTTP-Header (CSP) einschraenkt, aktualisieren Sie die CSP der Site, um das Laden von Kameleoon-Ressourcen zuzulassen:
script-src https://[your-site-code].kameleoon.io https://[your-site-code].kameleoon.eu https://client-config.kameleoon.com https://sdk-config.kameleoon.eu https://*.experimentation.dev 'unsafe-eval';
connect-src https://[your-site-code].kameleoon.io https://[your-site-code].kameleoon.eu https://eu-data.kameleoon.eu https://eu-data.kameleoon.io https://na-data.kameleoon.eu https://na-data.kameleoon.io https://editor.kameleoon.com https://api.kameleoon.com https://customers.kameleoon.com https://logger.kameleoon.io https://client-config.kameleoon.com https://sdk-config.kameleoon.eu https://*.experimentation.dev;
Wenn Sie Kameleoon im Hybridmodus verwenden, kann die Domain fuer Ihre Kameleoon-Skripte https://[your-site-code].kameleoon.xx von Projekt zu Projekt variieren. Ihre Projekte koennen je nach Erstellungsdatum entweder auf kameleoon.eu oder kameleoon.io gehostet sein. Stellen Sie sicher, dass Sie die in Ihrem Projekt in der Kameleoon-App angezeigte Domain verwenden. Ersetzen Sie [your-site-code] durch Ihren Kameleoon-Site-Code in jeder Zeile, in der er erscheint, und fuegen Sie dies Ihrer Konfiguration hinzu.
Da jede Serverinstanz ueber einen eigenen Speicher verfuegt, werden alle gesammelten Besucherdaten auf einer bestimmten Instanz gespeichert. Sie muessen ein Framework verwenden, in dem Anfragen desselben Besuchers von derselben Serverinstanz verarbeitet werden. Andernfalls muessen die Besucherdaten vor jeder Tracking-Anfrage vollstaendig hinzugefuegt oder mit der Methode getRemoteVisitorData geladen werden.Wenn das Problem im Unterschied der SDK-Konfiguration liegt, verwenden Sie die Streaming-Option.
Alle Auswertungen erfolgen lokal, um Latenz zu eliminieren. Tracking-Anfragen werden anschliessend asynchron an die Kameleoon Data API-Server gesendet.
Um einen Besucher einer Experiment-Variation zuzuweisen, erstellt Kameleoon zunaechst einen Bezeichner mithilfe des Visitor-Codes, der Experiment-ID und eines potenziell zusaetzlichen Elements im Falle eines Respoolings. Anschliessend berechnet eine synchrone Implementierung der Hash-Funktion SHA-256 einen Hash dieses Bezeichners. Die durch Hashing erhaltene Ganzzahl wird dann auf eine Gleitkommazahl zwischen null und eins abgebildet, um sie einer Experiment-Variation zuzuweisen. Die SHA-256-Funktion ist deterministisch, sodass derselbe Benutzer (mit demselben Visitor-Code) bei einem Experiment immer derselben Variation zugewiesen wird, sofern nicht ausdruecklich eine Neuberechnung der Zuweisung angefordert wird.
Folgen Sie der hier detailliert beschriebenen Methodik.
Alle moeglichen Faelle werden in diesem Artikel erlaeutert.
Es gibt mehrere Gruende, warum keine Daten auf der Ergebnisseite angezeigt werden:
  • Warten Sie 30-60 Minuten, bis der Kameleoon-Server einen Besuch bestaetigt. Jedes Mal, wenn derselbe Besucher auf der Website landet, erstellt Kameleoon einen neuen Besuch. Der Besuch endet, sobald Kameleoon in den letzten 30 Minuten keine neuen Aktivitaetsereignisse mehr empfaengt (z. B. Aussetzung einer Kampagne, Seitenaufruf, Scrollen, Klicks). Nach 30 Minuten Inaktivitaet erstellt Kameleoon einen neuen Besuch.
  • Wenn Sie die Bot-Filterung in den Projekteinstellungen aktiviert haben, koennte ein Fehler beim im SDK gesetzten user-agent-Wert vorliegen. Weitere Details finden Sie in diesem Artikel.
  • Die rechtliche Einwilligung ist in den Projekteinstellungen auf Required gesetzt, aber die SDK-Methode setLegalConsent wurde nicht aufgerufen. Weitere Details finden Sie in dieser Dokumentation.
  • Keine der SDK-Methoden, die eine Tracking-Anfrage an die Kameleoon-Server senden, wurde verwendet.
Der folgende Artikel bietet zusaetzliche Hilfe bei der Fehlerbehebung.
Wenn Sie eine grosse Anzahl von Besuchen von Besuchern sehen, koennten es Bots sein. Um zu verhindern, dass Bots Ihr Experiment beeinflussen, aktivieren Sie die Option Bot-Filterung in Ihren Projekteinstellungen. Um anzuzeigen, dass ein Besucher kein Bot ist, muessen Sie die Kameleoon-UserAgent-Daten ueber die SDK-Methode uebergeben. Der Aufruf der Methode verhindert, dass Kameleoon den Benutzer filtert.
Wenn Ihre Berichte eine unerwartete Zuweisung anzeigen (z. B. 10/90 statt 50/50) oder Besucher fehlen, kann dies einer der folgenden Gruende sein:
  • Einschraenkung des Besucherpools fuer bestimmte Variationen: Wenn Sie zuerst getVariations(onlyActive: true, track: false) aufrufen, gibt das SDK nur Besucher zurueck, die aktiven (ON)-Variationen zugewiesen sind. Wenn Sie dann nur Experimentseiten anzeigen und getVariation(track: true) fuer diese spezifischen Besucher aufrufen, verfolgt Kameleoon nur die ON-Variation, was zu einem Bericht fuehrt, der nur eine Variation anzeigt.
  • Unzureichende Zeit fuer Tracking-Anfragen: Kameleoon sendet Daten in einem bestimmten Intervall. Wenn ein Besucher auf einer Seite mit einem integrierten Kameleoon-Client fuer die ON-Variation bleibt, aber zu einer Seite ohne ihn fuer die OFF-Variation wechselt, hat der Client moeglicherweise nicht genug Zeit, um die Tracking-Anfrage fuer die OFF-Variation zu senden.
  • Fehlende Konfiguration fuer bestimmte Variationen: Moeglicherweise haben Sie UserAgent oder setLegalConsent fuer einige Variationen weggelassen. Wenn Sie beispielsweise die Einwilligung nur auf der Seite fuer die ON-Variation erteilen, kann Kameleoon Besucher in der OFF-Variation nicht verfolgen.
  • Fehlende Besucherdaten: Das SDK sammelt keine Besucherdaten automatisch; Sie muessen sie explizit hinzufuegen, damit Targeting und Tracking korrekt funktionieren.

​
Pruefen Sie Ihre Targeting-Einrichtung

Wenn Sie Targeting-Probleme vermuten, fuehren Sie diese Schritte aus:
  1. Erstellen Sie eine Nicht-Targeting-Regel mit 100 % Exposition und weisen Sie die gewuenschte Variation zu.
  2. Fuegen Sie Targeting hinzu und stellen Sie sicher, dass der Benutzer die Variation nicht mehr erhaelt.
  3. Fuegen Sie die erforderlichen Kameleoon-Daten hinzu.
Der Benutzer sollte die Variation erneut erhalten. Wenn dies fehlschlaegt, versuchen Sie, einfachere Targeting-Bedingungen zu verwenden, um das Problem einzugrenzen.
Ja, die Daten sind sofort fuer das Targeting verfuegbar. Bei serverbasierten SDKs sind die Daten waehrend der Besuchersitzung verfuegbar, bei clientbasierten SDKs (Mobil und Web) waehrend der eingestellten Lebensdauer.
Es haengt vom Typ des SDKs ab.In Server-SDKs werden die Daten des Besuchers waehrend der Besuchersitzung im Arbeitsspeicher gespeichert. Die Dauer der Sitzung kann eingestellt werden, der Standardwert betraegt jedoch 30 Minuten.
Je laenger die Sitzungsdauer mit dem Parameter sessionDuration ist, desto mehr Daten haelt das SDK im Speicher. Mehr Daten bedeuten erhoehten Verbrauch. Die Sitzung wird jedes Mal um weitere 30 Minuten verlaengert, wenn ein Besucher kontaktiert wird. So garantiert das SDK, dass Daten ab der letzten Anfrage mindestens 30 Minuten lang nicht geloescht werden.
In Client-SDKs (Mobil und Web) werden Daten in lokalen Speichern gespeichert (im Web LocalStorage). Daten koennen unbegrenzt gespeichert werden; mit dem Parameter dataExpirationInterval oder targetingDataCleanupInterval koennen Sie jedoch das Ablaufdatum der Daten festlegen, nach dem die Daten geloescht werden.
Im Allgemeinen muss die Methode “flush” nicht manuell aufgerufen werden: Daten werden zusammen mit anderen Aufrufen von SDK-Methoden gesendet. Wenn Sie jedoch Daten an die Data API senden muessen, ohne das Feature Flag des Besuchers auszuloesen, verwenden Sie die Methode “flush”.
Wenn Sie ein serverbasiertes SDK haben, werden die Daten waehrend der Sitzung eines Besuchers gespeichert. Sie muessen die Daten nicht bei jeder Anfrage laden, wenn die Sitzung des Benutzers noch nicht abgelaufen ist. In mobilen SDKs werden Daten unbegrenzt gespeichert (oder gemaess Ihren Einstellungen).Wenn die Benutzersitzung nicht mehr aktiv ist oder wenn der Besucher im Client-SDK zwischen Geraeten wechselt, rufen Sie die Methode getRemoteVisitorData mit den entsprechenden Parametern auf, um Daten an die Data API senden zu lassen. Nach dem Laden werden die Daten in das Besucher-Targeting einbezogen.
Wenn die rechtliche Einwilligung aktiviert ist, koennen Daten nur mit der Einwilligung der Besucher gesammelt werden.
Wenn Sie die Experiment-Regel verwenden und keine Besucherstatistiken erhalten, stellen Sie sicher, dass:
  • In der Kameleoon-App
    • Die Regel wurde fuer die richtige Umgebung erstellt (production, staging oder development).
    • Die Regel ist aktiviert (auf on geschaltet).
    • Die Regel spricht Traffic an, der tatsaechlich ausgesetzt werden kann.
    • Wenn die Bot-Filterung in Ihrem Projekt aktiviert ist, fuegen Sie den User Agent dem Filter hinzu.
  • Im SDK
    • Der KameleoonClient wurde mit der korrekten Konfiguration erstellt (siteCode, environment-Variable und gegebenenfalls networkDomain).
    • getVisitorCode wird nur einmal aufgerufen, und sein Wert wird ueberall wiederverwendet, wo der visitorCode benoetigt wird.
    • Bei Verwendung des Hybridmodus (engine.js im Frontend) ist der visitorCode korrekt mit dem Frontend synchronisiert.
    • Fuer Experimentregeln wird setLegalConsent(true) aufgerufen, um sicherzustellen, dass die Datenerfassung zulaessig ist.
    • Fuer Delivery-Regeln wird isFeatureActive() (oder getVariation()) aufgerufen und gibt true (oder die erwartete Variation) zurueck.
    • Fuer Experimentregeln wird getVariation() aufgerufen und gibt die erwartete Variation zurueck.
  • Debugging-Tipps
    • Protokollieren Sie in der Konsole: den Einwilligungswert, den visitorCode und die Variationswerte, und pruefen Sie, ob sie mit dem uebereinstimmen, was Sie im Browser sehen.
    • Aktivieren Sie SDK-Logging und pruefen Sie auf Fehler.
Gemaess DSGVO-Regeln verwendet Kameleoon ohne Einwilligung des Besuchers nur die technischen Informationen, die fuer den korrekten Betrieb der Produktfunktionen erforderlich sind.Ohne Einwilligung sendet Kameleoon Variationen fuer Targeted-Delivery-Regeln (aber nicht fuer Experiment-Regeln). Alle anderen Informationen (z. B. CustomData, Page Views und Geolocation) werden nur mit der Einwilligung des Besuchers gesendet (wenn die Erlaubnis erteilt wurde).Weitere Details zur Einwilligungsverwaltung finden Sie hier.
Standardmaessig fasst das SDK mehrere Ereignisse zusammen und sendet zu Analysezwecken in einem konfigurierbaren Intervall eine Tracking-Anfrage an die Kameleoon-Server. Dieser Ansatz verbessert die Effizienz und reduziert die Serverlast.Eine Tracking-Anfrage wird gesendet:
  • Periodisch: Standardmaessig wird alle 1000 Millisekunden (1 Sekunde) eine Anfrage gesendet. Sie koennen dieses Intervall aendern, indem Sie den Wert tracking interval setzen.
  • Auf Anforderung: Sofort, wenn eine Methode wie flush(instant=true) in Ihrem Code aufgerufen wird.
Insbesondere wird eine Tracking-Anfrage ausgeloest, wenn eine der folgenden Methoden vor Ablauf des Intervalls aufgerufen wird:
  • getVariation (wenn track auf true gesetzt ist).
  • getVariations (wenn track auf true gesetzt ist).
  • isFeatureActive (wenn track auf true gesetzt ist).
  • trackConversion
  • flush (mit oder ohne instant=true)
Zusaetzlich zu den oben genannten Methodenaufrufen senden clientseitige SDKs alle 15 Sekunden eine Tracking-Anfrage, wenn keine andere Aktivitaet stattgefunden hat. Diese Anfrage hilft, die Besuchersitzung aufrechtzuerhalten. Das Aktivitaets-Tracking-Intervall kann mit den SDKs fuer Android und iOS konfiguriert werden.Bei serverseitigen SDKs ist das Event-Batching besonders nuetzlich, da jede Tracking-Anfrage Daten mehrerer Besucher in einer einzigen Anfrage konsolidieren kann. Dieser Ansatz aggregiert Informationen zu allen betroffenen Besuchern und sendet sie einmal pro Intervall, wodurch die Effizienz verbessert und die Serverlast reduziert wird.
Tracking-Anfragen unterliegen den Data-API-Ratenlimits.Bei clientseitigen SDKs koennen in Umgebungen, in denen mehrere Besucher dasselbe Netzwerk teilen (z. B. in einem Buero), Anfragen so aussehen, als kaemen sie von derselben IP-Adresse, was das Ratenlimit ueberschreiten und einen Fehler 429 - Too Many Requests verursachen kann.
In verschiedenen SDKs koennen die Methoden aufgrund sprachlicher Besonderheiten unterschiedlich benannt sein.
Im Folgenden finden Sie eine Liste der SDK-Methoden, die HTTP-Anfragen stellen:
  • isFeatureActive / getFeatureVariationKey / getFeatureVariable / trackConversion / flush
    • Diese Methoden stellen asynchrone Anfragen an die Data API, um alle Informationen ueber den Besucher (einschliesslich der vom Benutzer erhaltenen Variationen) zu speichern, die zur Anzeige von Statistiken in app.kameleoon.com verwendet werden
  • getRemoteData / getRemoteVisitorData / getWarehouseAudience
    • Diese Methoden stellen synchrone Anfragen an die Data API, um Informationen ueber den Besucher zu erhalten
  • Zusaetzlich stellt das SDK asynchrone Anfragen, um die fuer die interne Arbeit erforderliche Konfiguration zu erhalten.
isFeatureActive kann aufgerufen werden, wenn Sie wissen muessen, ob das Flag aktiv ist, aber nicht wissen muessen, welche genaue Variation der Besucher erhalten hat. Wenn Sie Experiment-Regeln verwenden, ist es besser, getFeatureVariationKey aufzurufen, wenn Sie zwei oder mehr Variationen ausser “off” haben.
Ja, Sie koennen eine hybride Integration sowohl mit einem clientseitigen SDK (wie dem Kameleoon-JavaScript-SDK oder der engine.js-Anwendungsdatei) als auch mit einem serverseitigen SDK implementieren. In dieser Konfiguration ist es unerlaesslich, die Methode getVisitorCode aufzurufen. Dies gewaehrleistet eine konsistente Besuchererkennung zwischen Browser und Server und garantiert eine konsistente Variationszuweisung bei der Ausfuehrung von clientseitigem Code (z. B. Event-Tracking) und serverseitigem Code (z. B. Funktionsausfuehrung) fuer ein bestimmtes Feature Flag.
Sie sollten getVisitorCode in Faellen verwenden, in denen Sie eine hybride Integration nutzen (Website <-> server sdk, js sdk <-> server, engine <-> server sdk). Beim Aufruf von getVisitorCode wird der Visitor-Code ermittelt und ueber ein Cookie uebertragen. Wenn Sie keine hybride Integration verwenden, muessen Sie getVisitorCode nicht aufrufen; Sie koennen es jedoch trotzdem aufrufen, um einen zufaelligen Visitor-Code zu generieren.
Die Domain-Installation ist fuer getVisitorCode erforderlich. Andernfalls erhalten Sie moeglicherweise unterschiedliche Variationen fuer einen Besucher, da er auf verschiedenen Subdomains Ihrer Site unterschiedliche Visitor-Codes haben wird.
Wenn Sie Server- und Client-SDKs gleichzeitig verwenden, muessen Sie die Einwilligung fuer beide SDKs setzen.Weitere Details finden Sie in diesem Artikel.
Kameleoon kann wie viele Loesungen zur Optimierung der Benutzererfahrung von bestimmten Ad-Blockern blockiert werden. Diese betreffen hauptsaechlich die Web Experimentation-Anwendungsdatei (engine.js) und clientseitige SDKs, die auf JavaScript-Code basieren, der auf Ihrer Website geladen wird. Serverseitige SDKs hingegen arbeiten auf Ihren Servern und sind von Ad-Blockern nicht betroffen.Wenn Sie moechten, dass Benutzer mit Ad-Blockern in Ihre Experimente einbezogen werden, bietet Kameleoon eine Premium-Option, mit der Sie eine benutzerdefinierte Domain anstelle der Standard-Domain von Kameleoon verwenden koennen. Benutzerdefinierte Domains verhindern, dass Ad-Blocker Kameleoon erkennen und blockieren. Sobald konfiguriert, verwendet Kameleoon Ihre benutzerdefinierte Domain fuer alle ausgehenden Netzwerkanfragen an unsere Server, sei es zu Tracking-Zwecken oder zum Abrufen von SDK-Konfigurationsaktualisierungen.Die Verwendung einer benutzerdefinierten Domain ist nicht dasselbe wie Self-Hosting. Wenn Sie eine benutzerdefinierte Domain verwenden, hostet und liefert die Infrastruktur von Kameleoon weiterhin alle Inhalte (z. B. engine.js, SDK-Konfiguration, Tracking-Aufrufe). Der Unterschied besteht darin, dass diese Anfragen ueber eine Domain weitergeleitet werden, die Sie kontrollieren, wie experiments.mydomain.com.Um diese Option zu aktivieren, wenden Sie sich an Ihren Technical Account Manager. Sie muessen eine vollstaendige Domain angeben (z. B. experiments-mydomain.com), nicht eine Subdomain (z. B. experiments.mydomain.com). Der Domainname darf nicht den Teilstring kameleoon enthalten.
  • Ersetzen Sie fuer Web Experimentation Verweise auf die Standard-Kameleoon-Domain (kameleoon.) durch Ihre benutzerdefinierte Domain.
    • Beispiel: //SITE_CODE.{your-domain}/engine.js
  • Verwenden Sie fuer clientseitige SDKs den Parameter networkDomain bei der SDK-Initialisierung.
Wenn Sie statt einer benutzerdefinierten Domain Self-Hosting verwenden moechten, folgen Sie diesem Leitfaden.