Mit dem Kameleoon iOS (Swift) SDK können Experimente ausgeführt und feature flags in nativen mobilen iOS-Anwendungen aktiviert werden. Die Integration des SDK in Swift-Apps ist einfach, und der Ressourcenbedarf (Speicher- und Netzwerknutzung) ist gering.
Erste Schritte: Hilfe für den Einstieg finden Sie im Entwicklerhandbuch.
Changelog: Aktuelle Version des Swift SDK: 4.25.0 Changelog.
SDK-Methoden: Die vollständige Referenzdokumentation der iOS SDK-Methoden finden Sie im Abschnitt Referenz.
Entwicklerhandbuch
Befolgen Sie diese Schritte, um das Kameleoon iOS SDK zum ersten Mal in Ihrer Anwendung zu installieren und zu konfigurieren.
Erste Schritte
Starter-Kit
Um den Einstieg zu erleichtern, stellt Kameleoon ein Starter-Kit und eine Demo-Anwendung zum Testen des SDK bereit. Das Starter-Kit enthält eine vollständig konfigurierte App mit Beispielen, die zeigen, wie SDK-Methoden in einer App verwendet werden können. Das Starter-Kit, die Demo-Anwendung und detaillierte Anweisungen sind verfügbar unter Starter kit for iOS
Voraussetzungen
- Verwenden Sie Swift Version 5.0 oder höher auf der iOS-Plattform. Die Unterstützung für ältere iOS-Anwendungen (einschließlich älterer Swift-Versionen und Objective-C-Apps) ist nicht geplant. Eine Universal-Framework-Version ist verfügbar, die sowohl mit x86_64 (für den iOS-Simulator) als auch mit ARM (für den Produktivbetrieb im App Store) kompatibel ist.
Installation
Sie können das iOS SDK mit CocoaPods oder Swift Package Manager installieren:
CocoaPods
Swift Package Manager
Fügen Sie mit CocoaPods den folgenden Code in Ihr Podfile ein und ersetzen Sie YOUR_TARGET_NAME durch den Wert für Ihre App:# Podfile
use_frameworks!
target 'YOUR_TARGET_NAME' do
pod 'kameleoonClient'
end
Führen Sie dann in einer Eingabeaufforderung im Verzeichnis des Podfile den Installationsbefehl aus: Fügen Sie mit Swift Package Manager eine Paketabhängigkeit zu Ihrem Xcode-Projekt hinzu. Wählen Sie File > Swift Packages > Add Package Dependency und geben Sie die Repository-URL ein: https://github.com/Kameleoon/client-swift.Alternativ können Sie Ihre Package.swift-Datei direkt bearbeiten:dependencies: [
.package(url: "https://github.com/Kameleoon/client-swift.git", from("3.0.3"))
]
Zusätzliche Konfiguration
Um das Verhalten des SDK anzupassen, erstellen Sie eine Konfigurationsdatei kameleoon-client-swift.plist im Stammverzeichnis Ihres Xcode-Projekts. Sie können auch eine Beispielkonfiguration herunterladen.
Dies sind die Schlüssel, die Sie festlegen können:
| Schlüssel | Beschreibung | Standardwert |
|---|
refreshIntervalMinute / refresh_interval_minute (optional) | Gibt das Aktualisierungsintervall in Minuten an, in dem das SDK die Konfiguration für die aktiven Experimente und feature flags abruft. Der Wert bestimmt die maximale Zeit, die für die Verbreitung von Änderungen benötigt wird, z. B. das Aktivieren oder Deaktivieren von feature flags oder das Starten von Experimenten. Wenn nicht angegeben, beträgt das Standardintervall 60 Minuten. Zusätzlich ist ein Streaming-Modus verfügbar, der Server-Sent Events (SSE) verwendet, um neue Konfigurationen automatisch an das SDK zu übertragen und in Echtzeit anzuwenden. | 60 Minuten |
dataExpirationIntervalMinute / data_expiration_interval_minute (optional) | Bezeichnet den vordefinierten Zeitraum in Minuten, in dem das SDK den Besucher und die zugehörigen Daten speichert. Jede Dateninstanz wird einzeln ausgewertet, sodass Sie festlegen können, wie lange das SDK Daten speichert, bevor sie automatisch gelöscht werden. Wenn kein Intervall angegeben ist, löscht das SDK die Daten nicht automatisch vom Gerät. | Date.distantFuture |
defaultTimeoutMillisecond / default_timeout_millisecond (optional) | Gibt das Zeitintervall in Millisekunden an, nach dem Netzwerkanfragen vom SDK ablaufen. Setzen Sie den Wert auf 30000 Millisekunden (30 Sekunden) oder mehr, wenn Sie keine stabile Verbindung haben. Einige Methoden haben zusätzliche Parameter für methodenspezifische Timeouts, aber wenn Sie diese nicht explizit angeben, wird der Standardwert verwendet. | 10000 ms |
trackingIntervalMillisecond / tracking_interval_millisecond (optional) | Gibt das Intervall für Tracking-Anfragen in Millisekunden an. Alle Besucher, die für einen feature flag ausgewertet wurden oder deren Daten geflusht wurden, werden in diese Tracking-Anfrage einbezogen, die einmal pro Intervall ausgeführt wird. Der Mindestwert beträgt 1000 ms und der Höchstwert 5000 ms. | 1000 ms |
environment / environment (optional) | Für Kunden, die mehrere Umgebungen für Experimente und feature flagging nutzen, gibt diese Option an, welche feature flag-Konfiguration verwendet werden soll. Standardmäßig hat jeder feature flag die Optionen production, staging und development. Wenn nicht angegeben, ist der Standardwert production. Weitere Informationen. | nil |
isUniqueIdentifier / is_unique_identifier (optional) | Gibt an, dass der angegebene visitorCode eine eindeutige Kennung ist. | false |
networkDomain / network_domain (optional) | Benutzerdefinierte Domain, die von SDKs für ausgehende Anfragen verwendet wird, häufig zur Proxy-Nutzung. Muss eine gültige Domain sein (z. B. example.com oder sub.example.com). Ungültige Formate werden durch den Standardwert von Kameleoon ersetzt. | nil |
defaultDataFile / default_datafile (optional) | Die Funktion default_datafile stellt sicher, dass das Kameleoon SDK immer READY ist, indem es eine Fallback-Konfiguration bereitstellt, wenn keine zwischengespeicherte Datendatei existiert. Entwickler können eine gültige Konfiguration vorladen, indem sie sie von https://sdk-config.kameleoon.eu/v3/<sitecode> abrufen und bei der Initialisierung als default_datafile übergeben. Wenn ein Zeitstempel dateModified (in Millisekunden) angegeben wird und neuer ist als die zwischengespeicherte Version, verwendet das SDK das Standard-Datafile anstelle der zwischengespeicherten Version. Wenn dateModified weggelassen wird, wird das Standard-Datafile nur angewendet, wenn keine zwischengespeicherte Version existiert. Dies stellt sicher, dass das SDK immer über eine gültige Konfiguration verfügt, sei es standardmäßig, zwischengespeichert oder aktualisiert. | nil |
activityTrackingIntervalMillisecond / activity_tracking_interval_millisecond (optional) | Definiert das Intervall, in dem Aktivitätsereignisse gesendet werden. Das Ändern dieses Parameters kann Nebenwirkungen haben. Lesen Sie diesen Abschnitt, bevor Sie ihn verwenden. Der Mindest- und Standardwert beträgt 15 000 ms. Das Setzen dieses Werts auf 0 deaktiviert das periodische Aktivitäts-Tracking; in diesem Fall wird beim Start der Anwendung nur ein einziges Aktivitätsereignis gesendet. | 15 000 ms |
Wenn Sie einen visitorCode angeben und den Parameter isUniqueIdentifier auf true setzen, verwenden die SDK-Methoden den Wert von visitorCode als eindeutige Besucherkennung, was für Cross-Device-Experimente nützlich ist. Das SDK verknüpft die geflushten Daten mit dem Besucher, der mit der angegebenen Kennung verbunden ist.Der isUniqueIdentifier kann in anderen Sonderfällen nützlich sein, beispielsweise wenn Sie nicht auf den anonymen visitorCode zugreifen können, der ursprünglich dem Besucher zugewiesen wurde, aber Zugriff auf eine interne ID haben, die über Session-Merging mit dem anonymen Besucher verknüpft ist.
Verwendung von activityTrackingIntervalMillisecond
Der Parameter activityTrackingIntervalMillisecond soll dazu beitragen, den Akkuverbrauch und die Netzwerkauslastung zu reduzieren. Das Ändern seines Wertes kann jedoch erhebliche Nebenwirkungen haben, die Sie sorgfältig berücksichtigen sollten.
Prüfen Sie seine Auswirkungen auf die folgenden Funktionen:
-
Trigger für vergangene Zeit
- Wenn die konfigurierte vergangene Zeit kürzer ist als das Tracking-Intervall, wird der Trigger nicht wie erwartet ausgelöst.
-
Segmente für vergangene Zeit
- Wenn die vergangene Zeit kürzer ist als das Tracking-Intervall, werden Benutzer möglicherweise nicht wie beabsichtigt in das Segment aufgenommen.
-
Ziele für verbrachte Zeit
- Wenn die vergangene Zeit kürzer ist als das Tracking-Intervall, wird das Ziel möglicherweise nie erreicht.
-
Vergangene Zeit seit dem letzten Besuch in der Ergebnisseite
- Messungen für „vergangene Zeit seit dem letzten Besuch“ werden weniger präzise, wenn die vergangene Zeit nahe am oder unter dem Tracking-Intervall liegt.
-
Besuchsanzahl
- Nach 30 Minuten Inaktivität wird ein neuer Besuch erstellt. Wenn das Tracking-Intervall länger als 30 Minuten ist, wird bei jedem Tracking-Intervall ein neuer Besuch erstellt.
Das Setzen von activityTrackingIntervalMillisecond auf 0 deaktiviert das periodische Aktivitäts-Tracking vollständig. In dieser Konfiguration wird beim Start der Anwendung nur ein einziges Aktivitätsereignis gesendet, wodurch alle oben aufgeführten Funktionen unbrauchbar werden.
Initialisierung des Kameleoon-Clients
Nachdem Sie das SDK in Ihrer Anwendung eingerichtet haben, müssen Sie den Kameleoon-Client erstellen. Ein Client ist ein Singleton-Objekt, das als Brücke zwischen Ihrer Anwendung und der Kameleoon-Plattform fungiert. Er enthält alle Methoden und Eigenschaften, die Sie zur Durchführung eines Experiments benötigen.
import kameleoonClient
let visitorCode = "visitorCode"
let siteCode = "a8st4f59bj"
do {
// pass client configuration as an argument
let config = try KameleoonClientConfig(
clientId: "clientId", // optional
clientSecret: "clientSecret", // optional
refreshIntervalMinute: 15, // optional, 60 minutes by default
dataExpirationIntervalMinute: 60*24*365, // optional, `Data.distantFuture` by default
defaultTimeoutMillisecond: 10_000, // optional, 10_000 milliseconds by default
trackingIntervalMillisecond: 500, // optional, 1000 milliseconds by default
environment: "production", // optional
isUniqueIdentifier: false, // optional, false by default. Set to true if the visitorCode corresponds to your customer's unique userId.
networkDomain: "example.com", // optional, nil by default
defaultDataFile: "{...}", // optional, nil by default
activityTrackingIntervalMillisecond: 20_000 // optional, 15_000 milliseconds by default
)
let kameleoonClient = try KameleoonClientFactory.create(
siteCode: siteCode,
visitorCode: visitorCode, // optional
config: config // optional
)
} catch KameleoonError.visitorCodeInvalid {
// Provided visitor code is invalid
} catch KameleoonError.siteCodeIsEmpty {
// Indicates that provided site code is empty
} catch {
// Unexpected error occurred
}
do {
// read client configuration from a file 'kameleoon-client-swift.plist'
// visitor code isn't provided, so SDK generates a random visitor code which it will use in the future
let kameleoonClient = try KameleoonClientFactory.create(siteCode: siteCode)
} catch KameleoonError.visitorCodeInvalid {
// Provided visitor code is invalid
} catch {
// Unexpected error occurred
}
Die Methode KameleoonClientFactory.create() initialisiert den Client, der Client ist jedoch nicht sofort einsatzbereit. Der Client muss die aktuelle Konfiguration von Experimenten und feature flags (zusammen mit ihrer Traffic-Verteilung) von einem Kameleoon-Remote-Server abrufen. Dieser Abruf erfordert, dass der Client Netzwerkzugriff hat, was nicht immer verfügbar ist. Solange der Kameleoon-Client nicht vollständig bereit ist, sollten Sie nicht versuchen, andere Methoden im Kameleoon iOS SDK auszuführen. Nachdem der Client die erste Konfiguration der feature flags abgerufen hat, aktualisiert er die Konfiguration regelmäßig. Wenn die Aktualisierung aus irgendeinem Grund fehlschlägt, funktioniert der Kameleoon-Client weiterhin mit der vorherigen Konfiguration.
Sie können den öffentlichen Getter .ready verwenden, um zu prüfen, ob die Initialisierung des Kameleoon-Clients abgeschlossen ist.
Alternativ kann ein Helper-Callback die Logik zum Auslösen von Experimenten und zur Implementierung von Variationen kapseln. Der beste Ansatz (.ready oder Callback) hängt von den Präferenzen und dem Anwendungsfall ab. Die Verwendung von .ready wird empfohlen, wenn erwartet wird, dass das SDK bald einsatzbereit ist. Beispielsweise ist .ready geeignet, wenn ein Experiment in einem Dialog ausgeführt wird, der erst nach einigen Sekunden oder Minuten der Navigation in der App zugänglich wäre. Ein Callback wird empfohlen, wenn eine hohe Wahrscheinlichkeit besteht, dass das SDK noch initialisiert wird, wenn das Experiment erreicht wird. Beispielsweise sollte ein Experiment, das beim Start der App sichtbar ist, einen Callback verwenden, der die Anwendung warten lässt, bis entweder das SDK bereit ist oder ein angegebener Timeout abgelaufen ist.
Es liegt in Ihrer Verantwortung als App-Entwickler, sicherzustellen, dass der Client bereit ist, bevor Sie Methoden aufrufen. Eine gute Praxis ist es, immer davon auszugehen, dass der App-Benutzer aus dem Experiment ausgeschlossen werden sollte, wenn der Kameleoon-Client noch nicht bereit ist. Dieser Ausschluss ist leicht umzusetzen, da er der Implementierung der standardmäßigen Referenz-Variationslogik entspricht, wie im obigen Codebeispiel gezeigt.
Sie sind jetzt bereit, Feature-Management und feature flags zu implementieren. Weitere Informationen zu zusätzlichen Methoden finden Sie im Abschnitt Referenz.
Best Practices für Initialisierung und Nutzung
- Es wird empfohlen,
KameleoonClient als Singleton so früh wie möglich nach dem Start der Anwendung zu initialisieren, da die Initialisierung einige Zeit in Anspruch nehmen kann. Da die Initialisierung asynchron erfolgt, blockiert oder verzögert sie den Startvorgang der Anwendung nicht.
- Bevor Sie
KameleoonClient verwenden, vergewissern Sie sich, dass er initialisiert ist, indem Sie die Methode runWhenReady aufrufen. Andernfalls führen Versuche, den Client vor seiner Bereitschaft zu verwenden, zu Fehlern.
- ⚠️ Die meisten wichtigen Methoden können Fehler auslösen, daher ist eine ordnungsgemäße Ausnahmebehandlung erforderlich. Lesen Sie unbedingt die Dokumentation für jede verwendete Methode, um deren potenzielle Fehler zu verstehen.
// Initialize `KameleoonClient` on application startup and use it as a singleton later
do {
let kameleoonClient = try KameleoonClientFactory.create(siteCode: "<siteCode>");
} catch {}
// Example: Apply a discount percentage based on an feature flag variable's value
func applyDiscountIfApplicable() {
client.runWhenReady(timeoutMilliseconds: 1000) { ready in
guard ready else { return }
if let variation = try? client.getVariation(featureKey: "discount"),
let discount = variation.variables["discount_value"]?.value as? Double {
applyDiscount(value: discount)
}
}
}
// Initialize `KameleoonClient` on application startup and use it as a singleton later
do {
let kameleoonClient = try KameleoonClientFactory.create(siteCode: "<siteCode>");
} catch {}
// Example: Apply a discount percentage based on an feature flag variable's value
func applyDiscountIfApplicable() async throws {
try await client.runWhenReady(timeoutMilliseconds: 1000)
if let variation = try client.getVariation(featureKey: "discount"),
let discount = variation.variables["discount_value"]?.value as? Double {
applyDiscount(value: discount)
}
}
Aktivieren eines feature flag
Abrufen einer flag-Konfiguration
Um einen feature flag in Ihrem Code zu implementieren, müssen Sie den feature flag zunächst in Ihrem Kameleoon-Konto erstellen.
Um den Status oder die Variation eines feature flag für einen bestimmten Benutzer zu ermitteln, sollten Sie die Methode getVariation() oder isFeatureActive() verwenden, um die Konfiguration anhand des featureKey abzurufen.
Die Methode getVariation() verarbeitet sowohl einfache feature flags mit ON/OFF-Zuständen als auch komplexere flags mit mehreren Variationen. Die Methode ruft die passende Variation für den Benutzer ab, indem sie die Regeln des Features prüft, die Variation zuweist und sie basierend auf featureKey und visitorCode zurückgibt.
Die Methode isFeatureActive() kann verwendet werden, wenn Sie die Konfiguration eines einfachen feature flag abrufen möchten, der nur einen ON- oder OFF-Zustand hat, im Gegensatz zu komplexeren feature flags mit mehreren Variationen oder Targeting-Optionen.
Wenn Ihr feature flag zugehörige Variablen hat (z. B. spezifische Verhaltensweisen, die an jede Variation gebunden sind), ermöglicht Ihnen getVariation() auch den Zugriff auf das Variation-Objekt, das Details über die zugewiesene Variation und das zugehörige Experiment bereitstellt. Diese Methode prüft, ob der Benutzer angesprochen wird, findet die dem Besucher zugewiesene Variation und speichert sie. Wenn track=true, sendet das SDK das Expositionsereignis an das angegebene Experiment bei der nächsten Tracking-Anfrage, die automatisch basierend auf dem tracking_interval_millisecond des SDK ausgelöst wird. Standardmäßig ist dieses Intervall auf 1000 Millisekunden (1 Sekunde) eingestellt.
Die Methode getVariation() ermöglicht es Ihnen zu steuern, ob das Tracking durchgeführt wird. Wenn track=false, werden vom SDK keine Expositionsereignisse gesendet. Dies ist nützlich, wenn Sie Daten lieber nicht über das SDK verfolgen und sich stattdessen beispielsweise auf das vom Kameleoon-Engine verwaltete clientseitige Tracking verlassen möchten. Darüber hinaus ist das Setzen von track=false hilfreich, wenn Sie die Methode getVariations() verwenden, bei der Sie möglicherweise nur die Variationen für alle flags benötigen, ohne Tracking-Ereignisse auszulösen. Wenn Sie mehr darüber erfahren möchten, wie das Tracking funktioniert, lesen Sie diesen Artikel
Hinzufügen von Datenpunkten zum Targeting eines Benutzers oder zum Filtern / Aufschlüsseln von Besuchen in Berichten
Um einen Benutzer anzusprechen, stellen Sie sicher, dass Sie relevante Datenpunkte zu seinem Profil hinzugefügt haben, bevor Sie die Feature-Variation abrufen oder prüfen, ob der flag aktiv ist. Verwenden Sie die Methode addData(), um diese Datenpunkte zum Profil des Benutzers hinzuzufügen.
Um auf anderen Geräten erfasste Datenpunkte abzurufen, verwenden Sie die Methode getRemoteVisitorData(). Diese Methode ruft Daten asynchron von den Servern ab. Es ist wichtig, getRemoteVisitorData() vor dem Abrufen der Variation oder dem Prüfen, ob der feature flag aktiv ist, aufzurufen, da diese Daten erforderlich sein können, um einem Benutzer eine bestimmte Variation zuzuweisen.
Weitere Informationen zu den verfügbaren Targeting-Bedingungen finden Sie im ausführlichen Artikel zu diesem Thema.
Darüber hinaus stehen die zum Besucherprofil hinzugefügten Datenpunkte bei der Analyse Ihrer Experimente zur Verfügung, sodass Sie Ihre Ergebnisse nach Faktoren wie dem Gerät filtern und aufschlüsseln können. Die vollständige Liste finden Sie hier.
Wenn Sie zusätzliche Datenpunkte über das hinaus verfolgen müssen, was automatisch erfasst wird, können Sie die Custom Data-Funktion von Kameleoon verwenden. Mit Custom Data können Sie spezifische Informationen erfassen und analysieren, die für Ihre Experimente relevant sind. Vergessen Sie nicht, die Methode flush() aufzurufen, um die erfassten Daten zur Analyse an die Kameleoon-Server zu senden.
Tracking von Ziel-Conversions
Wenn ein Benutzer eine gewünschte Aktion abschließt (z. B. einen Kauf), wird dies als Conversion erfasst. Um Conversions zu verfolgen, verwenden Sie die Methode trackConversion() und geben Sie den erforderlichen Parameter goalId an.
Die Conversion-Tracking-Anfrage wird zusammen mit der nächsten geplanten Tracking-Anfrage gesendet, die das SDK in regelmäßigen Abständen sendet (definiert durch tracking_interval_millisecond). Wenn Sie die Anfrage sofort senden möchten, verwenden Sie die Methode flush() mit dem Parameter instant=true.
Cross-Device-Experimente
Um Besucher zu unterstützen, die von mehreren Geräten aus auf eine App zugreifen, ermöglicht Kameleoon die Synchronisierung zuvor erfasster Besucherdaten über alle Geräte des Besuchers hinweg und die Abstimmung des Besuchsverlaufs über Geräte hinweg durch Cross-Device-Experimente. Fallstudien und detaillierte Informationen darüber, wie Kameleoon Daten geräteübergreifend verarbeitet, finden Sie im Artikel über Cross-Device-Experimente.
Synchronisieren von custom data über Geräte hinweg
Obwohl die Synchronisierung von benutzerdefiniertem Mapping verwendet wird, um Besucherdaten geräteübergreifend abzugleichen, ist sie nicht immer notwendig. Nachfolgend werden zwei Szenarien beschrieben, in denen keine benutzerdefinierte Mapping-Synchronisierung erforderlich ist:
Gleiche Benutzer-ID auf allen Geräten
Wenn auf allen Geräten konsistent dieselbe Benutzer-ID verwendet wird, wird die Synchronisierung automatisch ohne benutzerdefinierte Mapping-Synchronisierung gehandhabt. Es genügt, die Methode getRemoteVisitorData() aufzurufen, wenn Sie die zwischen mehreren Geräten erfassten Daten synchronisieren möchten.
Multi-Server-Instanzen mit konsistenten IDs
In komplexen Setups mit mehreren Servern (z. B. verteilten Serverinstanzen), in denen dieselbe Benutzer-ID auf allen Servern verfügbar ist, ist die Synchronisierung zwischen Servern (mit getRemoteVisitorData()) ohne zusätzliche benutzerdefinierte Mapping-Synchronisierung ausreichend.
Kunden, die zusätzliche Daten benötigen, können in der Beschreibung der Methode getRemoteVisitorData() weitere Hinweise finden. Im folgenden Code wird davon ausgegangen, dass dieselbe eindeutige Kennung (in diesem Fall der visitorCode, der auch als userId bezeichnet werden kann) zwischen den beiden Geräten konsistent verwendet wird, um eine genaue Datenabfrage zu gewährleisten.
Wenn Sie erfasste Daten in Echtzeit synchronisieren möchten, müssen Sie für Ihre custom data den Scope Visitor auswählen.
// In this example, Custom data with index `90` was set to "Visitor" scope in Kameleoon.
let visitorScopeCustomDataIndex = 90
kameleoonClient.addData(CustomData(id: visitorScopeCustomDataIndex, values: "your data"))
kameleoonClient.flush()
// Before working with the data, call `getRemoteVisitorData`.
kameleoonClient.getRemoteVisitorData { result in
// After calling, the SDK on Device B will have access to CustomData of Visitor scope defined on Device A.
// So, "your data" will be available to target and track the visitor.
}
// In this example, Custom data with index `90` was set to "Visitor" scope in Kameleoon.
let visitorScopeCustomDataIndex = 90
kameleoonClient.addData(CustomData(id: visitorScopeCustomDataIndex, values: "your data"))
kameleoonClient.flush()
// Before working with the data, call `getRemoteVisitorData`.
try await kameleoonClient.getRemoteVisitorData()
// After calling, the SDK on Device B will have access to CustomData of Visitor scope defined on Device A.
// So, "your data" will be available to target and track the visitor.
Verwenden von custom data für das Zusammenführen von Sitzungen
Cross-Device-Experimente ermöglichen das Kombinieren des Verlaufs eines Besuchers über all seine Geräte hinweg (Verlaufsabgleich). Der Verlaufsabgleich ermöglicht das Zusammenführen verschiedener Besuchersitzungen zu einer einzigen. Um den Besuchsverlauf abzugleichen, verwenden Sie CustomData, um eine eindeutige Kennung für den Besucher bereitzustellen. Weitere Informationen finden Sie in der dedizierten Dokumentation.
Nachdem der Cross-Device-Abgleich aktiviert wurde, ruft der Aufruf von getRemoteVisitorData() mit dem Parameter userId alle bekannten Daten für einen bestimmten Benutzer ab.
Sitzungen mit derselben Kennung werden in einem Experiment immer dieselbe Variation angezeigt bekommen. In der Besucheransicht der Ergebnisseiten Ihres Experiments erscheinen diese Sitzungen als ein einziger Besucher.
Die SDK-Konfiguration stellt sicher, dass zugehörige Sitzungen immer dieselbe Variation des Experiments sehen. Es gibt jedoch einige Einschränkungen hinsichtlich der geräteübergreifenden Variationszuweisung. Diese Einschränkungen sind hier beschrieben.
Folgen Sie dem Leitfaden Aktivieren des Cross-Device-Verlaufsabgleichs, um Ihre custom data auf der Kameleoon-Plattform einzurichten.
Anschließend können Sie das SDK normal verwenden. Die folgenden Methoden können im Kontext des Zusammenführens von Sitzungen hilfreich sein:
getRemoteVisitorData() mit übergebenem isUniqueIdentifier=true an KameleoonClientConfig - um Daten für alle verknüpften Besucher abzurufen.
trackConversion() oder flush() mit übergebenem isUniqueIdentifier=true an KameleoonClientConfig - um bestimmte Daten für einen spezifischen Besucher zu verfolgen, der mit einem anderen Besucher verknüpft ist.
Hier ist ein Beispiel für die Verwendung von custom data zum Zusammenführen von Sitzungen.
// In this example, `91` represents the Custom Data's index,
// configured as a unique identifier in Kameleoon.
let mappingIndex = 91;
let featureKey = "ff123";
// 0. Initializing anonymous KameleoonClient
// Assume `anonymousVisitorCode` is the randomly generated ID for the visitor.
let anonymousKameleoonClient = KameleoonClientFactory.create(
siteCode: siteCode,
visitorCode: anonymousVisitorCode
)
anonymousKameleoonClient.runWhenReady { result in
// ...
}
// 1. Before the visitor is authenticated
// Retrieve the variation for an unauthenticated visitor.
let anonymousVariation = anonymousKameleoonClient.getVariation(featureKey)
// 2. After the visitor is authenticated
// Assume `userId` is the visitor code of the authenticated visitor.
anonymousKameleoonClient.addData(CustomData(id: mappingIndex, values: userId))
anonymousKameleoonClient.flush(instant: true)
KameleoonClient userKameleoonClient = KameleoonClientFactory.create(
siteCode: siteCode,
visitorCode: userId,
config: KameleoonClientConfig(
isUniqueIdentifier: true // Indicate that `userId` is a unique identifier
)
)
userKameleoonClient.runWhenReady { result in
// ...
}
// 3. After the visitor has been authenticated
// Retrieve the variation for the `userId`, which will match the anonymous visitor code's variation.
let userVariation = userKameleoonClient.getVariation(featureKey: featureKey)
let isSameVariation = userVariation.key == anonymousVariation.key // true
// The `userId` and `anonymousVisitorCode` are now linked and tracked as a single visitor.
userKameleoonClient.trackConversion(goalId: 123, revenue: 10.0);
// Additionally, the linked visitors will share all fetched remote visitor data.
userKameleoonClient.getRemoteVisitorData { result in
// ...
}
// In this example, `91` represents the Custom Data's index,
// configured as a unique identifier in Kameleoon.
let mappingIndex = 91;
let featureKey = "ff123";
// 0. Initializing anonymous KameleoonClient
// Assume `anonymousVisitorCode` is the randomly generated ID for the visitor.
let anonymousKameleoonClient = KameleoonClientFactory.create(
siteCode: siteCode,
visitorCode: anonymousVisitorCode
)
try await anonymousKameleoonClient.runWhenReady()
// 1. Before the visitor is authenticated
// Retrieve the variation for an unauthenticated visitor.
let anonymousVariation = anonymousKameleoonClient.getVariation(featureKey)
// 2. After the visitor is authenticated
// Assume `userId` is the visitor code of the authenticated visitor.
anonymousKameleoonClient.addData(CustomData(id: mappingIndex, values: userId))
anonymousKameleoonClient.flush(instant: true)
KameleoonClient userKameleoonClient = KameleoonClientFactory.create(
siteCode: siteCode,
visitorCode: userId,
config: KameleoonClientConfig(
isUniqueIdentifier: true // Indicate that `userId` is a unique identifier
)
)
try await userKameleoonClient.runWhenReady()
// 3. After the visitor has been authenticated
// Retrieve the variation for the `userId`, which will match the anonymous visitor code's variation.
let userVariation = userKameleoonClient.getVariation(featureKey: featureKey)
let isSameVariation = userVariation.key == anonymousVariation.key // true
// The `userId` and `anonymousVisitorCode` are now linked and tracked as a single visitor.
userKameleoonClient.trackConversion(goalId: 123, revenue: 10.0);
// Additionally, the linked visitors will share all fetched remote visitor data.
try await userKameleoonClient.getRemoteVisitorData()
In diesem Beispiel verfügt die Anwendung über eine Anmeldeseite. Da die Benutzer-ID zum Zeitpunkt der Anmeldung unbekannt ist, wird ein anonymer Besucher verwendet, der vom SDK automatisch generiert wird. Der Visitor Code kann mit der Methode getVisitorCode() abgerufen werden. Nach der Anmeldung des Benutzers wird der anonyme Besucher mit der Benutzer-ID verknüpft und als eindeutige Kennung für den Besucher verwendet.
Verwendung eines benutzerdefinierten Bucketing-Schlüssels
Standardmäßig verwendet Kameleoon eine eindeutige, anonyme Besucher-ID (visitorCode), um Benutzer feature flag-Variationen zuzuweisen. Diese ID wird normalerweise auf dem Gerät des Benutzers generiert und gespeichert (in einem Browser-Cookie für client- und serverseitige SDKs – im persistenten Speicher für mobile SDKs). In bestimmten Szenarien müssen Sie jedoch möglicherweise sicherstellen, dass alle Benutzer derselben Organisation dieselbe Variante eines feature flag sehen.
Die Option Custom Bucketing Key ermöglicht es Ihnen, dieses Standardverhalten zu überschreiben, indem Sie Ihre eigene benutzerdefinierte Kennung für das Bucketing bereitstellen. Diese Überschreibung stellt sicher, dass die Zuweisungslogik von Kameleoon Ihren angegebenen Schlüssel anstelle des standardmäßigen visitorCode verwendet.
Anwendungsfälle
Die Verwendung eines benutzerdefinierten Bucketing-Schlüssels ist wesentlich für die Konsistenz und Genauigkeit Ihrer feature flag-Zuweisungen, insbesondere in diesen Situationen:
- Experimente auf Konto- oder Organisationsebene: Für B2B-Produkte oder Szenarien, in denen Sie alle Benutzer derselben Organisation derselben Variation zuweisen möchten, können Sie eine Kennung wie eine
accountId verwenden. Benutzerdefinierte Bucketing-Schlüssel sind entscheidend für A/B test-Funktionen, die ein gesamtes Team oder Unternehmen betreffen.
Durch die Implementierung eines benutzerdefinierten Bucketing-Schlüssels gewährleisten Sie eine höhere Konsistenz und Genauigkeit in Ihren Experimenten, was zu zuverlässigeren Ergebnissen und einer besseren Benutzererfahrung führt.
Technische Details
Wenn Sie einen benutzerdefinierten Bucketing-Schlüssel für einen feature flag konfigurieren, stellen Sie Kameleoon eine bestimmte Kennung aus den Daten Ihrer Anwendung zur Verfügung:
try? kameleoonClient.addData(CustomData(id: index, values: "newVisitorCode"))
- Bereitstellung des benutzerdefinierten Schlüssels: Sie stellen Ihre benutzerdefinierte Kennung dem Kameleoon SDK mit der Methode
addData() zur Verfügung. In dieser Methode übergeben Sie Ihren gewählten benutzerdefinierten Bucketing-Schlüssel als CustomData-Objekt. Hier bezieht sich newVisitorCode auf die Kennung, die Sie für Ihr Bucketing verwenden möchten (z. B. die neue userId oder accountId).
Damit der benutzerdefinierte Bucketing-Schlüssel korrekt funktioniert, muss er auch für den feature flag während des Flag-Erstellungs- oder -Bearbeitungsprozesses definiert und konfiguriert werden. Ohne diese entsprechende Konfiguration wird das Bucketing des SDK Ihren benutzerdefinierten Schlüssel nicht anwenden. Detaillierte Anweisungen zur Einrichtung in Kameleoon finden Sie in diesem Artikel.
- Bucketing-Logik: Sobald ein benutzerdefinierter Bucketing-Schlüssel über die Methode
addData() bereitgestellt wird, verwenden alle Hash-Berechnungen zur Zuweisung von Benutzern zu Variationen diesen newVisitorCode (Ihren benutzerdefinierten Schlüssel) anstelle des standardmäßigen visitorCode. Die Verwendung des newVisitorCode bedeutet, dass die Bucketing-Entscheidung an Ihre benutzerdefinierte Kennung gebunden ist, was konsistente Zuweisungen in verschiedenen Kontexten gewährleistet, in denen diese Kennung vorhanden ist.
- Daten-Tracking und Analytics: Es ist wichtig zu beachten, dass, obwohl der
newVisitorCode (Ihr benutzerdefinierter Schlüssel) für Bucketing-Entscheidungen verwendet wird, alle nachfolgenden Daten (z. B. Tracking-Ereignisse und Conversions) gesendet und mit dem ursprünglichen visitorCode verknüpft werden. Diese Trennung stellt sicher, dass Ihre Analytics individuelle Benutzerreisen und Interaktionen im breiteren Kontext Ihres Experiments genau wiedergeben, auch wenn das Bucketing auf einer höheren Ebene (wie einem Konto) oder über mehrere Geräte/Sitzungen hinweg erfolgt. Ihre ursprünglichen Besucherdaten bleiben für ein umfassendes Reporting intakt.
Technische Anforderungen
Um einen benutzerdefinierten Bucketing-Schlüssel effektiv zu verwenden:
- Der Schlüssel muss ein
String sein.
- Er muss für die Entität, die Sie bucketen möchten, eindeutig sein (z. B. wenn Sie eine
userId verwenden, sollte die ID jedes Benutzers eindeutig sein).
- Der Schlüssel muss dem SDK genau in dem Moment zur Verfügung stehen, in dem die feature flag-Entscheidung für diesen Benutzer oder diese Anfrage ausgewertet wird.
Targeting-Bedingungen
Die Kameleoon SDKs unterstützen eine Vielzahl vordefinierter Targeting-Bedingungen, mit denen Sie Benutzer in Ihren Kampagnen ansprechen können. Die Liste der von diesem SDK unterstützten Bedingungen finden Sie unter Besuchsverlauf zum Ansprechen von Benutzern verwenden.
Sie können auch Ihre eigenen externen Daten zum Ansprechen von Benutzern verwenden.
Logging
Das SDK generiert Logs, um verschiedene interne Prozesse und Probleme widerzuspiegeln.
Log-Level
Das SDK unterstützt die Konfiguration der Begrenzung des Loggings durch einen Log-Level.
// The `none` log level does not allow logging.
KameleoonLogger.logLevel = .none
// The `ERROR` log level only allows logging issues that may affect the SDK's main behaviour.
KameleoonLogger.logLevel = .error
// The `WARNING` log level allows logging issues which may require additional attention.
// It extends the `ERROR` log level.
// The `WARNING` log level is a default log level.
KameleoonLogger.logLevel = .warning
// The `INFO` log level allows logging general information on the SDK's internal processes.
// It extends the `WARNING` log level.
KameleoonLogger.logLevel = .info
// The `DEBUG` level logs additional details about the SDK’s internal processes and extends the `INFO` level
// with more granular. diagnostic output.
// This information is not intended for end-user interpretation but can be sent to support
// to assist with internal troubleshooting.
KameleoonLogger.logLevel = .debug
Benutzerdefinierte Behandlung von Logs
Das SDK schreibt seine Logs standardmäßig in die Konsolenausgabe. Dieses Verhalten kann überschrieben werden.
Die Begrenzung des Loggings durch einen Log-Level wird unabhängig von der Logging-Handhabungslogik durchgeführt.
public struct CustomLogger: Logging {
let customLogger = Logger(subsystem: "com.yourcompany.app", category: "app")
public func log(level: LogLevel, message: String) {
switch level {
case .error:
customLogger.error("\(message)")
case .warning:
customLogger.warning("\(message)")
case .info:
customLogger.info("\(message)")
case .debug:
customLogger.debug("\(message)")
default:
break
}
}
}
// Log level filtering is applied separately from log handling logic.
// The custom logger will only accept logs that meet or exceed the specified log level.
// Ensure the log level is set correctly.
KameleoonLogger.logLevel = .debug // Optional, defaults to `LogLevel.WARNING`.
KameleoonLogger.logger = CustomLogger()
Übergabe des Visitor Codes an eine WebView
In einigen Fällen müssen Sie möglicherweise den Visitor Code von der nativen Anwendung an eine WebView übergeben, die Engine.js oder die Web-SDKs JavaScript oder React verwendet. Das folgende Beispiel zeigt die empfohlene Vorgehensweise dafür:
SwiftUI
SwiftUI (iOS 26+)
struct WebView: UIViewRepresentable {
let url: URL
let kameleoonClient: KameleoonClient
private let kameleoonCookieName = "kameleoonVisitorCode"
func makeUIView(context: Context) -> WKWebView {
let config = WKWebViewConfiguration()
let webView = WKWebView(frame: .zero, configuration: config)
let cookieStore = webView.configuration.websiteDataStore.httpCookieStore
let cookie = makeVisitorCookie()
cookieStore.setCookie(cookie) {
webView.load(URLRequest(url: url))
}
return webView
}
func updateUIView(_ webView: WKWebView, context: Context) {}
private func makeVisitorCookie() -> HTTPCookie {
let properties: [HTTPCookiePropertyKey: Any] = [
.domain: ".example.com",
.path: "/",
.name: kameleoonCookieName,
.value: kameleoonClient.visitorCode,
.secure: true,
.expires: Date(timeIntervalSinceNow: 60 * 60 * 24 * 365)
]
return HTTPCookie(properties: properties)!
}
}
struct WebView: View {
let url: URL
let kameleoonClient: KameleoonClient
private let websiteDataStore: WKWebsiteDataStore
private let kameleoonCookieName = "kameleoonVisitorCode"
@State private var page: WebPage
init(url: URL, kameleoonClient: KameleoonClient) {
self.url = url
self.kameleoonClient = kameleoonClient
let websiteDataStore = WKWebsiteDataStore.default()
var configuration = WebPage.Configuration()
configuration.websiteDataStore = websiteDataStore
self.websiteDataStore = websiteDataStore
_page = State(initialValue: WebPage(configuration: configuration))
}
var body: some View {
WebView(page)
.webViewBackForwardNavigationGestures(.enabled)
.task(id: url) {
let cookieStore = websiteDataStore.httpCookieStore
let properties: [HTTPCookiePropertyKey: Any] = [
.domain: ".example.com",
.path: "/",
.name: kameleoonCookieName,
.value: kameleoonClient.visitorCode,
.secure: true
]
if let cookie = HTTPCookie(properties: properties) {
await cookieStore.setCookie(cookie)
}
page.load(URLRequest(url: url))
}
}
}
Ab dem 1. Mai 2024 verlangt Apple, dass Apps, die ein Drittanbieter-SDK enthalten, wie z. B. das Kameleoon iOS SDK, eine Datenschutz-Manifest-Datei enthalten. Die neueste Version des SDK ist code-signiert, konform und enthält eine gültige Manifest-Datei mit dem SDK. Es ist keine Aktion erforderlich, wenn Sie die Kameleoon iOS SDK-Version 4.2 oder höher verwenden.
Referenz
Dies ist die vollständige Referenzdokumentation für das Kameleoon iOS (Swift) SDK.
Initialisierung
Nachdem Sie das SDK installiert haben, müssen Sie Kameleoon initialisieren. Alle Interaktionen Ihrer Anwendung mit dem SDK, wie das Auslösen eines Experiments, werden über dieses Kameleoon-Client-Objekt durchgeführt.
create()
Rufen Sie diese Methode vor allen anderen auf, um das SDK zu initialisieren. Diese Methode befindet sich in KameleoonClientFactory. create() erstellt eine Instanz von KameleoonClient, um alle Interaktionen zwischen dem SDK und Ihrer App zu verwalten.
Sie können das Verhalten des SDK anpassen (z. B. die Umgebung, die Anmeldedaten), indem Sie ein Konfigurationsobjekt bereitstellen. Andernfalls versucht das SDK, Ihre Konfigurationsdatei zu finden und stattdessen zu verwenden.
let visitorCode = "visitorCode"
let siteCode = "a8st4f59bj"
do {
// pass client configuration as an argument
let config = try KameleoonClientConfig(
clientId: "clientId", // optional
clientSecret: "clientSecret", // optional
refreshIntervalMinute: 15, // optional, 60 minutes by default
dataExpirationIntervalMinute: 60*24*365, // optional, `Data.distantFuture` by default
defaultTimeoutMillisecond: 10_000, // optional, 10_000 milliseconds by default
trackingIntervalMillisecond: 500, // optional, 1000 milliseconds by default
environment: "production", // optional
isUniqueIdentifier: false, // optional, false by default. Set to true if the visitorCode corresponds to your customer's unique userId.
networkDomain: "example.com", // optional, nil by default
defaultDataFile: "{...}", // optional, nil by default
activityTrackingIntervalMillisecond: 20_000 // optional, 15_000 milliseconds by default
)
let kameleoonClient = try KameleoonClientFactory.create(
siteCode: siteCode,
visitorCode: visitorCode, // optional
config: config // optional
)
} catch KameleoonError.visitorCodeInvalid {
// Provided visitor code is invalid
} catch KameleoonError.siteCodeIsEmpty {
// Indicates that provided site code is empty
} catch {
// Unexpected error occurred
}
do {
// read client configuration from a file 'kameleoon-client-swift.plist'
// visitor code isn't provided, so SDK generates a random visitor code which will be used in the future
let kameleoonClient = KameleoonClientFactory.create(siteCode: siteCode)
} catch KameleoonError.visitorCodeInvalid {
// Provided visitor code is invalid
} catch KameleoonError.siteCodeIsEmpty {
// Indicates that provided site code is empty
} catch {
// Unexpected error occurred
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| siteCode (erforderlich) | String | Ein eindeutiger Schlüssel, der das mit dem SDK verwendete Kameleoon-Projekt identifiziert. | |
| visitorCode (optional) | String? | Eine optionale Besucherkennung. Falls verfügbar, verwenden Sie Ihre interne Benutzer-ID; andernfalls generiert das SDK automatisch eine. | nil |
| config (optional) | KameleoonClientConfig? | Optionale SDK-Konfiguration. Wenn angegeben, wird sie anstelle des Lesens aus einer externen Konfigurationsdatei verwendet. Wenn nicht angegeben, versucht das SDK, die Datei zu lesen, aber falls die Datei fehlt, greift es auf das Standardverhalten zurück. | nil |
Rückgabewert
| Typ | Beschreibung |
|---|
KameleoonClient | Eine Instanz der Klasse KameleoonClient, die Ihre App dann verwenden kann, um Ihre Experimente und feature flags zu verwalten. |
Ausgelöste Ausnahmen
| Typ | Beschreibung |
|---|
KameleoonError.visitorCodeInvalid | Ausnahme, die anzeigt, dass der bereitgestellte Visitor Code nicht gültig ist. Er ist entweder leer oder länger als 255 Zeichen. |
KameleoonError.siteCodeIsEmpty | Ausnahme, die anzeigt, dass der angegebene Site Code eine leere Zeichenfolge ist, was ein ungültiger Wert ist. |
ready
Bei mobilen SDKs erfolgt die Initialisierung des Kameleoon-Clients nicht sofort. Das SDK muss einen Serveraufruf durchführen, um die aktuelle Konfiguration für alle aktiven Experimente abzurufen. Prüfen Sie, ob das SDK bereit ist, indem Sie diese Methode aufrufen, bevor Sie ein Experiment auslösen. Alternativ können Sie die Methode runWhenReady() mit einem Callback verwenden.
let ready = kameleoonClient.ready
Rückgabewert
| Name | Typ | Beschreibung |
|---|
| ready | Bool | Boolean, der den Status des SDK darstellt (true, wenn vollständig initialisiert, false, wenn nicht einsatzbereit). |
runWhenReady()
- 🔄 Führt eine asynchrone Anfrage durch (wenn die Konfiguration veraltet oder fehlt)
Bei mobilen SDKs kann der KameleoonClient nicht sofort initialisiert werden, da er einen Serveraufruf durchführen muss, um die aktuelle Konfiguration für alle feature flags abzurufen. Verwenden Sie die Methode runWhenReady(), um zu warten, bis der Client einsatzbereit ist. Zusätzlich können Sie einen maximalen Timeout-Zeitraum festlegen, um zu steuern, wie lange der Client wartet, bevor er bereit ist.
Wenn ready=true, ist der KameleoonClient vollständig initialisiert, und feature flags werden ausgewertet und ihren jeweiligen Variationen zugewiesen. Wenn das Ergebnis false ist oder ein Timeout auftritt, wird die Initialisierung nicht abgeschlossen.
Der Callback oder der asynchrone Code sollte die Anwendung der Referenz-Variation behandeln, da ein Timeout den Benutzer vom feature flag ausschließt.
Da die Initialkonfiguration möglicherweise einen Serveraufruf erfordert, ist dieser Mechanismus asynchron. Daher sollten Sie entweder:
- Einen
completion-Callback als Argument an die Methode übergeben, um sicherzustellen, dass Sie benachrichtigt werden, wenn der KameleoonClient vollständig initialisiert und einsatzbereit ist.
- Asynchrone Operationen verwenden.
func applyRecommendedProductsVariation() {
let defaultValue = 5 // Default control number for recommended products
kameleoonClient.runWhenReady(timeoutMilliseconds: 1000) { ready in
guard ready else {
applyVariation(recommendedProductsNumber: defaultValue)
return
}
let variation = try? kameleoonClient.getVariation(featureKey: "featureKey")
let recommendedProductsNumber = variation.variables["recommendedProductsNumber"]?.value as? Int ?? defaultValue
applyVariation(recommendedProductsNumber: recommendedProductsNumber)
}
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| timeoutMilliseconds (optional) | Int | Timeout für den Initialisierungsprozess | defaultTimeoutMillisecond oder default_timeout_millisecond |
| callback (erforderlich) | (Bool) -> Void | Callback-Objekt. Es handelt sich um einen Lambda-Ausdruck, der ein Bool-Argument erhält, das angibt, ob der KameleoonClient bereit wurde, bevor das Timeout erreicht wurde. | |
Ein häufiger Fehler ist der Aufruf von async-Funktionen mit try? oder innerhalb eines verschachtelten do-catch-Blocks ohne CancellationError erneut auszulösen. Dies kann die Aufgabenstornierung beeinträchtigen und zu unerwartetem Verhalten führen.
Um eine korrekte Aufgabenstornierung zu gewährleisten, vermeiden Sie die Verwendung von try? oder do-catch um async-Funktionen, es sei denn, Sie lösen CancellationError explizit erneut aus.
func applyRecommendedProductsVariation() async throws {
let defaultValue = 5 // Default control number for recommended products
try await kameleoonClient.runWhenReady(timeoutMilliseconds: 1000)
let variation = try kameleoonClient.getVariation(featureKey: "featureKey")
let recommendedProductsNumber = variation.variables["recommendedProductsNumber"]?.value as? Int ?? defaultValue
applyVariation(recommendedProductsNumber: recommendedProductsNumber)
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| timeoutMilliseconds (optional) | Int | Timeout für den Initialisierungsprozess | defaultTimeoutMillisecond oder default_timeout_millisecond |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
KameleoonError.sdkNotReady | Ausnahme, die anzeigt, dass das SDK noch nicht vollständig initialisiert ist. |
Feature flags und Variationen
isFeatureActive()
- 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom Parameter
track)
Diese Methode hieß zuvor activateFeature und wurde in der SDK-Version 4.0.0 entfernt.
Um einen Feature-Toggle zu aktivieren, rufen Sie diese Methode auf. isFeatureActive() akzeptiert featureKey als erforderliches Argument, um zu prüfen, ob die angegebene Funktion für einen Besucher aktiv sein wird.
Wenn ein Besucher noch nie mit diesem feature flag verknüpft wurde, gibt diese Methode einen zufälligen booleschen Wert zurück (true, wenn dem Benutzer diese Funktion angezeigt werden soll, andernfalls false). Wenn der Besucher bereits mit diesem feature flag registriert ist, gibt die Methode den vorherigen featureFlag-Wert zurück.
Stellen Sie sicher, dass Sie eine Fehlerbehandlung wie im Beispielcode gezeigt implementieren, um mögliche Fehler abzufangen.
Kameleoon verwendet Tracking, um Sitzungen und Besucher zu zählen, wenn Sie bestimmte Methoden aufrufen, wie z. B. isFeatureActive(), getVariation() oder getVariations().Verwenden Sie den Standardwert true für den Parameter track, wenn Sie Besucher einer Variation aussetzen und sie zählen müssen. Setzen Sie den Parameter track nur dann auf false, wenn Sie diese Methoden aufrufen, bevor Sie Besucher aussetzen.Wenn Sie beispielsweise getVariations() aufrufen, um alle Variationen abzurufen, bevor Sie Besucher aussetzen, setzen Sie den Parameter track auf false. Diese Einstellung verhindert, dass Kameleoon eine Sitzung verfrüht zählt. Sie können das Tracking dann später auslösen, wenn Sie den Besucher explizit aussetzen.Kameleoon sendet standardmäßig jede Sekunde Tracking-Daten. Sie können dieses Intervall mit der Tracking-Intervall-Konfigurationsoption auf bis zu fünf Sekunden konfigurieren. Kameleoon gruppiert Tracking-Ereignisse in einer einzigen Sitzung, solange das Intervall zwischen den Ereignissen weniger als 30 Minuten beträgt. Wenn mehr als 30 Minuten zwischen Tracking-Ereignissen vergehen, zählt Kameleoon die Ereignisse als separate Sitzungen. Ein Besuch erscheint in Ihren Berichten 30 Minuten nach dem letzten aufgezeichneten Ereignis in der Sitzung.
let featureKey = "new_checkout"
var hasNewCheckout = false
do {
hasNewCheckout = try kameleoonClient.isFeatureActive(featureKey: featureKey)
// disabling tracking
hasNewCheckout = kameleoonClient.isFeatureActive(featureKey: featureKey, track: false);
} catch {
switch error {
case KameleoonError.sdkNotReady:
// Exception indicating that the SDK has not completed its initialization yet.
hasNewCheckout = false
case KameleoonError.Feature.notFound:
// The feature key is not in the configuration file that has been fetched by the SDK.
hasNewCheckout = false
default:
// Any other error.
hasNewCheckout = false
}
}
if hasNewCheckout
{
// Implement new checkout code here
}
Die Methode isFeatureActive() wertet die ausgelieferte Variante aus, nicht den Zustand des Master-Flags. Wenn Sie Regeln ausschließen, verwendet die Methode den Standardzustand Then, for everyone else serve. Wenn Sie Off für diesen Standardzustand auswählen, gibt die Methode immer false zurück, auch wenn der Master-feature flag On ist.
Argumente
| Name | Typ | Beschreibung |
|---|
| featureKey | String | Der Schlüssel der Funktion, die Sie einem Benutzer ausstellen möchten. Dieses Feld ist erforderlich. |
| track | Bool | Ein optionaler Parameter zum Aktivieren oder Deaktivieren des Trackings der Feature-Auswertung (standardmäßig true). |
Rückgabewert
| Typ | Beschreibung |
|---|
Bool | Wert der Funktion, der für den Besucher registriert ist. |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
KameleoonError.sdkNotReady | Ausnahme, die anzeigt, dass das SDK nicht vollständig initialisiert ist. |
KameleoonError.Feature.notFound | Ausnahme, die anzeigt, dass die angeforderte Feature-ID nicht in der internen Konfiguration des SDK gefunden wurde. Diese Ausnahme bedeutet in der Regel, dass der feature flag auf der Kameleoon-Seite noch nicht aktiviert wurde (aber der Code, der die Funktion implementiert, bereits in der Webanwendung bereitgestellt ist). |
getVariation()
- 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom Parameter
track)
Ruft die Variation ab, die einem bestimmten Besucher für einen spezifischen feature flag zugewiesen wurde.
Diese Methode benötigt visitorCode und featureKey als Pflichtargumente. Das Argument track ist optional und standardmäßig true.
Sie gibt die zugewiesene Variation für den Besucher zurück. Wenn der Besucher nicht mit feature flag-Regeln verknüpft ist, gibt die Methode die Standard-Variation für den angegebenen feature flag zurück.
Stellen Sie sicher, dass in Ihrem Code eine ordnungsgemäße Fehlerbehandlung implementiert ist, um potenzielle Ausnahmen zu verwalten.
Die Standardvariation bezieht sich auf die Variation, die einem Besucher zugewiesen wird, wenn er keiner der vordefinierten Auslieferungsregeln für einen feature flag entspricht. Mit anderen Worten, es ist die Fallback-Variation, die auf alle Benutzer angewendet wird, die nicht durch spezifische Regeln angesprochen werden. Sie wird als Variation im Abschnitt “Then, for everyone else…” in einer Verwaltungsoberfläche dargestellt.
let featureKey = "featureKey"
var variation: Types.Variation?
do {
variation = try kameleoonClient.getVariation(featureKey: featureKey)
// disabling tracking
variation = kameleoonClient.getVariation(featureKey: featureKey, track: false);
} catch {
switch error {
case KameleoonError.sdkNotReady:
// Exception indicating that the SDK has not completed its initialization yet.
case KameleoonError.Feature.notFound:
// The feature key is not in the configuration file that has been fetched by the SDK.
case KameleoonError.Feature.environmentDisabled:
// The feature flag is disabled for the environment.
default:
// Any other error.
}
}
let title = variation?.variables["title"].value
switch variation?.key {
case "on":
// Main variation key is selected for visitorCode
case "alternative_variation":
// Alternative variation key
default:
// Default variation key
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| visitorCode (erforderlich) | String | Eindeutige Kennung des Besuchers. | |
| featureKey (erforderlich) | String | Schlüssel der Funktion, die Sie einem Besucher ausstellen möchten. | |
| track (optional) | Bool | Ein optionaler Parameter zum Aktivieren oder Deaktivieren des Trackings der Feature-Auswertung. | true |
Rückgabewert
| Typ | Beschreibung |
|---|
Variation | Eine Variation, die einem bestimmten Besucher für einen spezifischen feature flag zugewiesen wurde. |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
KameleoonError.visitorCodeInvalid | Ausnahme, die anzeigt, dass der bereitgestellte Visitor Code nicht gültig ist. Er ist entweder leer oder länger als 255 Zeichen. |
KameleoonError.Feature.notFound | Ausnahme, die anzeigt, dass der angeforderte Feature Key nicht in der internen Konfiguration des SDK gefunden wurde. Dies bedeutet in der Regel, dass der feature flag in der Kameleoon-App nicht aktiviert ist (aber der Code, der die Funktion implementiert, bereits in der Anwendung bereitgestellt ist). |
KameleoonError.Feature.environmentDisabled | Ausnahme, die anzeigt, dass der feature flag für die aktuelle Umgebung des Besuchers (z. B. production, staging oder development) deaktiviert ist. |
getVariations()
- 📨 Sendet Tracking-Daten an Kameleoon (abhängig vom Parameter
track)
Ruft eine Map von Variation-Objekten ab, die einem bestimmten Besucher über alle feature flags hinweg zugewiesen sind.
Diese Methode iteriert über alle verfügbaren feature flags und gibt die zugewiesene Variation für jeden mit dem angegebenen Besucher verknüpften flag zurück. Sie nimmt onlyActive und track als optionale Argumente entgegen.
- Wenn
onlyActive auf true gesetzt ist, gibt die Methode getVariations() Variationen von feature flags zurück, sofern der Benutzer nicht mit der off-Variation gebucketet ist.
- Der Parameter
track steuert, ob die Methode die Variationszuweisungen verfolgt oder nicht. Standardmäßig ist er auf true gesetzt. Wenn er auf false gesetzt ist, wird das Tracking deaktiviert.
Die zurückgegebene Map besteht aus feature flag-Schlüsseln als Schlüsseln und ihren entsprechenden Variation als Werten. Wenn für einen feature flag keine Variation zugewiesen ist, gibt die Methode die Standard-Variation für diesen flag zurück.
Eine ordnungsgemäße Fehlerbehandlung sollte implementiert werden, um potenzielle Ausnahmen zu verwalten.
Die Standardvariation bezieht sich auf die Variation, die einem Besucher zugewiesen wird, wenn er keiner der vordefinierten Auslieferungsregeln für einen feature flag entspricht. Mit anderen Worten, es ist die Fallback-Variation, die auf alle Benutzer angewendet wird, die nicht durch spezifische Regeln angesprochen werden. Sie wird als Variation im Abschnitt “Then, for everyone else…” in einer Verwaltungsoberfläche dargestellt.
do {
let variations = kameleoonClient.getVariations();
// only active variations
let variations = kameleoonClient.getVariations(onlyActive: true);
// disable tracking
let variations = kameleoonClient.getVariations(track: false);
} catch KameleoonError.sdkNotReady {
// Exception indicating that the SDK has not completed its initialization yet.
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| onlyActive (optional) | Bool | Ein optionaler Parameter, der angibt, ob Variationen für aktive (true) oder alle (false) feature flags zurückgegeben werden sollen. | false |
| track (optional) | Bool | Ein optionaler Parameter zum Aktivieren oder Deaktivieren des Trackings der Feature-Auswertung. | true |
Rückgabewert
| Typ | Beschreibung |
|---|
Dict<String, Variation> | Map, die die zugewiesenen Variation-Objekte der feature flags unter Verwendung der Schlüssel der entsprechenden Features enthält. |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
KameleoonError.sdkNotReady | Gibt an, dass das SDK noch nicht vollständig initialisiert ist. |
setForcedVariation()
Mit dieser Methode können Sie einem Benutzer programmatisch eine bestimmte Variation zuweisen und dabei den Standard-Auswertungsprozess umgehen. Dies ist besonders wertvoll für kontrollierte Experimente, bei denen die übliche Auswertungslogik nicht erforderlich ist oder übersprungen werden muss. Es kann auch in Szenarien wie Debugging oder benutzerdefinierten Tests hilfreich sein.
Wenn eine erzwungene Variation gesetzt ist, überschreibt sie die Echtzeit-Auswertungslogik von Kameleoon. Prozesse wie Segmentierung, Targeting-Bedingungen und algorithmische Berechnungen werden übersprungen. Um Segmentierung und Targeting-Bedingungen während eines Experiments beizubehalten, setzen Sie stattdessen forceTargeting=false.
Eine erzwungene Variation wird genauso behandelt wie eine ausgewertete Variation. Sie wird in Analytics verfolgt und im Benutzerkontext wie jede standardmäßig ausgewertete Variation gespeichert, um Konsistenz im Reporting zu gewährleisten.
Die Methode kann unter bestimmten Bedingungen Ausnahmen auslösen (z. B. ungültige Parameter, Benutzerkontext oder interne Probleme). Eine ordnungsgemäße Ausnahmebehandlung ist unerlässlich, um sicherzustellen, dass Ihre Anwendung stabil und belastbar bleibt.
let experimentId = 9516
do {
// Forcing the variation "on" for the experiment 9516 for the visitor
try kameleoonClient.setForcedVariation(experimentId: experimentId, variationKey: "on")
// Forcing the variation "on" while preserving segmentation and targeting conditions during the experiment
try kameleoonClient.setForcedVariation(experimentId: experimentId, variationKey: "on", forceTargeting: false)
// Resetting the forced variation for the experiment 9516 for the visitor
try kameleoonClient.setForcedVariation(experimentId: experimentId, variationKey: nil);
} catch {
// Handling the KameleoonError, KameleoonError.Feature and common Error
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| experimentId (erforderlich) | Int | Experiment Id, die während des Auswertungsprozesses angesprochen und ausgewählt wird. | |
| variationKey (erforderlich) | String | Variation Key, der einer Variation entspricht, die als zurückgegebener Wert für das Experiment erzwungen werden soll. Wenn der Wert nil ist, wird die erzwungene Variation zurückgesetzt. | |
| forceTargeting (optional) | Bool | Gibt an, ob das Targeting für das Experiment erzwungen und übersprungen (true) oder wie im Standard-Auswertungsprozess angewendet werden soll (false). | true |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
KameleoonError.sdkNotReady | Gibt an, dass das SDK noch nicht vollständig initialisiert ist. |
KameleoonError.Feature.experimentNotFound | Ausnahme, die anzeigt, dass die angeforderte Experiment-ID nicht in der internen Konfiguration des SDK gefunden wurde. Dies ist in der Regel normal und bedeutet, dass das der Regel entsprechende Experiment auf der Kameleoon-Seite noch nicht aktiviert wurde. |
KameleoonError.Feature.variationNotFound | Ausnahme, die anzeigt, dass der angeforderte Variation Key(id) nicht in der internen Konfiguration des SDK gefunden wurde. Dies ist in der Regel normal und bedeutet, dass das der Variation entsprechende Experiment auf der Kameleoon-Seite noch nicht aktiviert wurde. |
In den meisten Fällen muss nur der grundlegende Fehler KameleoonError/KameleoonError.Feature behandelt werden, wie im Beispiel gezeigt. Wenn jedoch verschiedene Fehlertypen eine Reaktion erfordern, behandeln Sie jeden separat basierend auf den spezifischen Anforderungen. Zusätzlich können für eine erhöhte Zuverlässigkeit allgemeine Sprachfehler durch Einbeziehung von Error behandelt werden.
evaluateAudiences()
- 📨 Sendet Tracking-Daten an Kameleoon
Diese Methode wertet Besucher gegen alle verfügbaren Audiences Explorer-Segmente aus und verfolgt diejenigen, die übereinstimmen.
evaluateAudiences() sollte aufgerufen werden, nachdem alle relevanten Besucherdaten gesetzt oder aktualisiert wurden, und kurz vor dem Abrufen einer Feature-Variation oder dem Prüfen eines feature flag. Dieser Ansatz stellt sicher, dass der Besucher gegen die aktuellsten verfügbaren Daten ausgewertet wird, was eine genaue Audience-Zuweisung basierend auf allen Kriterien ermöglicht.
Nach dem Aufruf dieser Methode können Sie eine detaillierte Analyse der Segmentleistung im Audiences Explorer durchführen.
do {
try kameleoonClient.evaluateAudiences();
} catch {
// Handling the errors
}
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
KameleoonError.sdkNotReady | Gibt an, dass das SDK noch nicht vollständig initialisiert ist. |
In den meisten Fällen muss nur der grundlegende Fehler KameleoonError/KameleoonError.Feature behandelt werden, wie im Beispiel gezeigt. Wenn jedoch verschiedene Fehlertypen eine Reaktion erfordern, behandeln Sie jeden separat basierend auf den spezifischen Anforderungen. Zusätzlich können für eine erhöhte Zuverlässigkeit allgemeine Sprachfehler durch Einbeziehung von Error behandelt werden.
getFeatureList()
Gibt eine Liste der feature flag-Schlüssel zurück, die derzeit für das SDK verfügbar sind.
let allFeatureList = kameleoonClient.getFeatureList()
Rückgabewert
| Typ | Beschreibung |
|---|
[String] | Liste der feature flag-Schlüssel |
getDataFile()
Um alle feature flags auszuwerten, verwenden Sie getVariations(). Diese Methode ist effizienter als der Aufruf von DataFile und das Iterieren durch flags mit getVariation().
Gibt die aktuelle SDK-Konfiguration als DataFile-Objekt zurück.
do {
let dataFile = try kameleoonClient.getDataFile()
} catch KameleoonError.sdkNotReady {
// Exception indicates that the SDK has not completed its initialization yet.
} catch {
// Handling the KameleoonError, KameleoonError.Feature and common Error
}
Rückgabewert
| Typ | Beschreibung |
|---|
DataFile | Das DataFile, das die SDK-Konfiguration enthält |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
KameleoonError.sdkNotReady | Gibt an, dass das SDK noch nicht vollständig initialisiert ist. |
Ziele
trackConversion()
- 📨 Sendet Tracking-Daten an Kameleoon
Verwenden Sie diese Methode, um Conversions zu verfolgen. Diese Methode erfordert goalId, um die Conversion auf diesem bestimmten Ziel zu verfolgen. Darüber hinaus akzeptiert diese Methode auch die Argumente revenue, metadata und negative.
Die Methode trackConversion() gibt keinen Wert zurück. Diese Methode ist nicht blockierend, da der Serveraufruf asynchron erfolgt.
let goalId = 83023
kameleoonClient.trackConversion(goalId: goalId, revenue: 10.0)
kameleoonClient.trackConversion(goalId: goalId, revenue: 10.0, metadata: CustomData(id: 1, values: "metadata"))
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| goalId (erforderlich) | Int | ID des Ziels. | |
| revenue (optional) | Double | Umsatz der Conversion. | 0 |
| negative (optional) | Bool | Definiert, ob der Umsatz positiv oder negativ ist. | false |
| metadata (optional) | CustomData... / [CustomData] | Metadaten der Conversion. Müssen vorher in der Kameleoon-App definiert werden. | [] |
Metadatenwerte sind über Rohdatenexporte und die Ergebnisseite zugänglich.Wenn der Parameter metadata bereitgestellt wird, verwendet Kameleoon diese angegebenen Werte für die aktuelle Conversion anstelle dessen, was zuvor mit der Methode addData() erfasst wurde. Wenn der Parameter weggelassen wird, verwendet Kameleoon die zuletzt verfolgten Werte für diese CustomData vor der Conversion und innerhalb desselben Besuchs.Kameleoon berücksichtigt nur die Metadatenwerte, die explizit als Parameter an die Methode trackConversion() übergeben werden.Im folgenden Beispiel verknüpft Kameleoon die Conversion nur mit dem custom data-Wert, der explizit als Parameter angegeben wurde (hier: Index 5 mit dem Wert “Amex Credit Card”).kameleoonClient.addData([CustomData(id: 5, values: "Credit Card"), CustomData(id: 9, "Express Delivery")]);
kameleoonClient.trackConversionWithOptParams(goalId: 1000, metadata: CustomData(5, "Amex Credit Card"));
Ereignisse
updateConfigurationHandler()
Mit der Methode updateConfigurationHandler() können Sie das Ereignis behandeln, wenn die Konfiguration Daten aktualisiert hat. Sie nimmt einen Eingabeparameter, handler. Der Handler, der aufgerufen wird, wenn die Konfiguration mit einem Echtzeit-Konfigurationsereignis aktualisiert wird.
kameleoonClient.updateConfigurationHandler {
// configuration was updated
}
Argumente
| Name | Typ | Beschreibung |
|---|
| handler | Optional<(() -> Void)> | Der Handler, der aufgerufen wird, wenn die Konfiguration mit einem Echtzeit-Konfigurationsereignis aktualisiert wird. |
Besucherdaten
visitorCode
Gibt den eindeutigen Visitor Code zurück, der im SDK verwendet wird.
let visitorCode = kameleoonClient.visitorCode
Rückgabewert
| Typ | Beschreibung |
|---|
String | Zeichenfolge, die einen eindeutigen Visitor Code darstellt, der im SDK verwendet wird. |
addData()
Die Methode addData() fügt Targeting-Daten zum Speicher hinzu, sodass andere Methoden die Daten verwenden können, um zu entscheiden, ob der aktuelle Besucher angesprochen werden soll oder nicht.
Die Methode addData() gibt keinen Wert zurück und interagiert nicht von selbst mit den Kameleoon-Backend-Servern. Stattdessen werden alle deklarierten Daten für die zukünftige Übertragung mit der Methode flush() gespeichert. Dieser Ansatz reduziert die Anzahl der durchgeführten Serveraufrufe, da die Daten in der Regel zu einem einzigen Serveraufruf gruppiert werden, der durch flush() ausgelöst wird.
Die Methode trackConversion() sendet auch alle zuvor verknüpften Daten, genau wie flush(). Gleiches gilt für die Methoden getVariation() und getVariations(), wenn eine Experimentregel ausgelöst wird.
Jeder Besucher kann nur eine Instanz verknüpfter Daten für die meisten Datentypen haben. CustomData ist jedoch eine Ausnahme. Besucher können eine Instanz verknüpfter CustomData pro Index haben.
// Add a single data item (tracked by default)
kameleoonClient.addData(CustomData(index: 1, values: "value"))
// Add multiple data items (tracked by default)
kameleoonClient.addData(
CustomData(index: 20, values: "value"),
Geolocation(country: "France")
)
// Add multiple data items stored locally for targeting only (not sent to the Kameleoon Data API)
kameleoonClient.addData(
track: false,
CustomData(index: 20, values: "value"),
Geolocation(country: "France")
)
Argumente
| Name | Typ | Beschreibung | Standardwert |
|---|
| track (optional) | Bool | Gibt an, ob die hinzugefügten Daten für das Tracking in Frage kommen. Wenn auf false gesetzt, werden die Daten lokal gespeichert und nur für die Targeting-Auswertung verwendet; sie werden nicht an die Kameleoon Data API gesendet. | true |
| data (erforderlich) | KameleoonData... / [KameleoonData] | Sammlung von Kameleoon-Datentypen. | |
flush()
- 📨 Sendet Tracking-Daten an Kameleoon
Die Methode flush() sammelt die mit dem Besucher verknüpften Kameleoon-Daten. Anschließend sendet sie eine Tracking-Anfrage zusammen mit allen Daten, die mit der Methode addData hinzugefügt und noch nicht über eine dieser Methoden gesendet wurden. flush() ist nicht blockierend, da der Serveraufruf asynchron erfolgt.
flush bietet Kontrolle darüber, wann die mit einem bestimmten visitorCode verknüpften Daten an die Server gesendet werden. Wenn addData() beispielsweise ein Dutzend Mal aufgerufen wird, wäre es ineffizient, bei jedem Aufruf von addData() Daten an den Server zu senden. Rufen Sie flush() einmal auf.
kameleoonClient.addData(CustomData(id: 20, values: "true", "20"))
kameleoonClient.addData(Conversion(goalId: 32, revenue: 10.0, negative: false))
kameleoonClient.flush() // Interval tracking (most performant way for tracking)
kameleoonClient.flush(instant: true) // Instant tracking
Argumente
| Name | Typ | Beschreibung |
|---|
| instant | Bool | Boolesches Flag, das angibt, ob die Daten sofort gesendet werden sollen (true) oder gemäß dem standardmäßigen Tracking-Intervall (false), das mit dem SDK-Parameter trackingIntervalMillisecond in KameleoonClientConfig oder tracking_interval_millisecond festgelegt wird. Dieses Feld ist optional. |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
KameleoonError.sdkNotReady | Fehler, der anzeigt, dass das SDK seine Initialisierung nicht abgeschlossen hat. |
getRemoteData()
- 🔄 Führt eine asynchrone Anfrage durch
Diese Methode hieß zuvor retrieveDataFromRemoteSource und wurde in der SDK-Version 4.0.0 entfernt.
Verwenden Sie diese Methode, um Daten von einem Kameleoon-Remote-Server basierend auf dem aktiven siteCode und dem Argument key (oder dem aktiven visitorCode, wenn key weggelassen wird) abzurufen. visitorCode und siteCode werden in KameleoonClientFactory.create() angegeben. Daten können schnell und bequem auf hoch skalierbaren Remote-Servern unter Verwendung der Kameleoon Data API gespeichert werden. Die Anwendung kann die Daten dann mit dieser Methode abrufen.
Da ein Serveraufruf erforderlich ist, ist dieser Mechanismus asynchron. Daher sollten Sie entweder:
- Einen
completion-Callback als Argument an die Methode übergeben, um sicherzustellen, dass Sie benachrichtigt werden, wenn die Daten erfolgreich abgerufen wurden.
- Asynchrone Operationen verwenden.
struct Test1: Decodable {
let value: String
private enum CodingKeys: String, CodingKey {
case value = "json_value"
}
}
kameleoonClient.getRemoteData(key: "test") { (result: Result<Test1, Error>) in
switch result {
case .success(let test1):
// test1 is a decoded value for Test1 type
case .failure:
// error includes informaion about request's failure
}
}
kameleoonClient.getRemoteData(key: "test") { (data: Result<Data, Error>) in
switch result {
case .success(let data):
if let json = try JSONSerialization.jsonObject(with: data) as? [String: Any] {
print(json)
}
case .failure:
// error includes informaion about request's failure
}
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| key (optional) | String | Der Schlüssel, mit dem die zu abrufenden Daten verknüpft sind. | "" |
| completion (erforderlich) | (Result<T: Decodable, Error>) -> Void | Der Callback, der die empfangenen Daten verarbeitet. | |
Ein häufiger Fehler ist der Aufruf von async-Funktionen mit try? oder innerhalb eines verschachtelten do-catch-Blocks ohne CancellationError erneut auszulösen. Dies kann die Aufgabenstornierung beeinträchtigen und zu unerwartetem Verhalten führen.
Um eine korrekte Aufgabenstornierung zu gewährleisten, vermeiden Sie die Verwendung von try? oder do-catch um async-Funktionen, es sei denn, Sie lösen CancellationError explizit erneut aus.
struct Test1: Decodable {
let value: String
private enum CodingKeys: String, CodingKey {
case value = "json_value"
}
}
Task {
do {
let test1: Test1 = try await kameleoonClient.getRemoteData(key: "test")
// test1 is a decoded value for Test1 type
} catch {
// handle error
}
}
Task {
do {
let data: Data = try await kameleoonClient.getRawRemoteData(key: "test")
if let json = try JSONSerialization.jsonObject(with: data) as? [String: Any] {
print(json)
}
} catch {
// handle error
}
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| key (optional) | String | Der Schlüssel, mit dem die zu abrufenden Daten verknüpft sind. | "" |
Rückgabewert
| Typ | Beschreibung |
|---|
Decodable | Ein Decodable-Objekt, das den geparsten abgerufenen Wert enthält. |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
Error | Gibt an, dass die Anfrage aufgrund eines Fehlers fehlgeschlagen ist. |
getRemoteVisitorData()
- 🔄 Führt eine asynchrone Anfrage durch
getRemoteVisitorData() ist eine asynchrone Methode zum Abrufen von Kameleoon Visits Data für den Besucher von der Kameleoon Data API. Die Methode fügt die Daten dem Speicher hinzu, damit andere Methoden sie bei Targeting-Entscheidungen verwenden können.
Die mit dieser Methode erhaltenen Daten spielen eine wichtige Rolle, wenn Sie:
- Daten verwenden möchten, die auf anderen Geräten erfasst wurden.
- auf den Verlauf eines Benutzers zugreifen möchten, wie z. B. custom data, die bei früheren Besuchen erfasst wurden.
Lesen Sie diesen Artikel, um mögliche Anwendungsfälle besser zu verstehen.
Standardmäßig ruft getRemoteVisitorData() automatisch die zuletzt gespeicherten custom data mit scope=Visitor ab und hängt sie an den Besucher an, ohne dass die Methode addData() aufgerufen werden muss. Dies ist besonders nützlich für die Synchronisierung von custom data zwischen mehreren Geräten.Es wird empfohlen, nur auf fehlgeschlagene Ergebnisse zu prüfen. Falls erforderlich, kann jedoch überprüft werden, ob die Daten dem Besucher hinzugefügt wurden und für Targeting-Zwecke verfügbar sind (oder zum Debugging, obwohl die Verwendung von Logging zum Debugging besser ist). Zusätzlich können Daten manuell verwaltet werden, wenn der Parameter addData=false übergeben wird.
Da ein Serveraufruf erforderlich ist, ist dieser Mechanismus asynchron. Daher sollten Sie entweder:
- Einen
completion-Callback als Argument an die Methode übergeben, um sicherzustellen, dass Sie benachrichtigt werden, wenn die Daten erfolgreich abgerufen und dem Besucher hinzugefügt wurden.
- Asynchrone Operationen verwenden.
// Fetch visitor data and automatically add it
kameleoonClient.getRemoteVisitorData { result in
switch result {
case .success(let visitorData):
// visitorData includes all retrieved data that was added for the visitor
case .failure:
// Handle the error, which contains information about the request failure
}
}
// Fetch visitor data without automatically adding it
kameleoonClient.getRemoteVisitorData(addData: false) { result in
switch result {
case .success(let visitorData):
// visitorData includes all retrieved data that was added for the visitor
case .failure:
// Handle the error, which contains information about the request failure
}
}
// Fetch a custom list of data types
let filter = Types.RemoteVisitorDataFilter(
previousVisitAmount: 25, currentVisit: true, conversions: true, experiments: true, geolocation: true
)
kameleoonClient.getRemoteVisitorData(filter: filter) { result in
switch result {
case .success(let visitorData):
// visitorData includes all retrieved data that was added for the visitor
case .failure:
// Handle the error, which contains information about the request failure
}
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| filter (optional) | RemoteVisitorDataFilter | Filter, der auswählt, welche Daten aus dem Besuchsverlauf abgerufen werden sollen. Standardmäßig ruft die Methode CustomData aus dem aktuellen und dem zuletzt vorherigen Besuch ab. | RemoteVisitorDataFilter.default |
| addData (optional) | Boolean | Ein Boolean, der angibt, ob die Methode automatisch abgerufene Daten für einen Besucher hinzufügen soll. | true |
| completion (erforderlich) | (Result<[KameleoonData], Error>) -> Void | Der Callback, der die empfangenen Besucherdaten verarbeitet. | |
Ein häufiger Fehler ist der Aufruf von async-Funktionen mit try? oder innerhalb eines verschachtelten do-catch-Blocks ohne CancellationError erneut auszulösen. Dies kann die Aufgabenstornierung beeinträchtigen und zu unerwartetem Verhalten führen.
Um eine korrekte Aufgabenstornierung zu gewährleisten, vermeiden Sie die Verwendung von try? oder do-catch um async-Funktionen, es sei denn, Sie lösen CancellationError explizit erneut aus.
// Fetch visitor data and automatically add it
Task {
do {
let visitorData = try await kameleoonClient.getRemoteVisitorData()
// visitorData includes all retrieved data that was added for the visitor
} catch {
// Handle the error, which contains information about the request failure
}
}
// Fetch visitor data without automatically adding it
Task {
do {
let visitorData = try await kameleoonClient.getRemoteVisitorData(addData: false)
// visitorData includes all retrieved data but was not added for the visitor
} catch {
// Handle the error, which contains information about the request failure
}
}
// Fetch a custom list of data types
Task {
do {
let filter = Types.RemoteVisitorDataFilter(
previousVisitAmount: 25, currentVisit: true, conversions: true, experiments: true, geolocation: true
)
let visitorData = try await kameleoonClient.getRemoteVisitorData(filter: filter)
// visitorData includes all retrieved data based on the specified filter
} catch {
// Handle the error, which contains information about the request failure
}
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| filter (optional) | RemoteVisitorDataFilter | Filter, der auswählt, welche Daten aus dem Besuchsverlauf abgerufen werden sollen. Standardmäßig ruft die Methode CustomData aus dem aktuellen und dem zuletzt vorherigen Besuch ab. | RemoteVisitorDataFilter.default |
| addData (optional) | Boolean | Ein Boolean, der angibt, ob die Methode automatisch abgerufene Daten für einen Besucher hinzufügen soll. | true |
Rückgabewert
| Typ | Beschreibung |
|---|
[KameleoonData] | Ein Array mit den abgerufenen Daten für den Besucher. |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
Error | Gibt an, dass die Anfrage aufgrund eines Fehlers fehlgeschlagen ist. |
Verwendung von Parametern mit RemoteVisitorDataFilter
Die Methode getRemoteVisitorData() bietet Flexibilität, indem sie es Ihnen ermöglicht, verschiedene Parameter beim Abrufen von Daten zu Besuchern zu definieren. Egal, ob Sie auf der Grundlage von Zielen, Experimenten oder Variationen targeten, der gleiche Ansatz gilt für alle Datentypen.
Angenommen, Sie möchten Daten zu Besuchern abrufen, die ein Ziel “Order transaction” abgeschlossen haben. Sie können Parameter innerhalb der Methode getRemoteVisitorData() angeben, um Ihr Targeting zu verfeinern. Wenn Sie beispielsweise nur Benutzer ansprechen möchten, die das Ziel in ihren letzten fünf Besuchen konvertiert haben, können Sie den Parameter previousVisitAmount auf 5 und conversions auf true setzen.
Die in diesem Beispiel gezeigte Flexibilität ist nicht auf Zieldaten beschränkt. Sie können Parameter innerhalb der Methode getRemoteVisitorData() verwenden, um Daten zu verschiedenen Besucherverhalten abzurufen.
Hier ist die Liste der verfügbaren Types.RemoteVisitorDataFilter-Optionen:| Name | Typ | Beschreibung | Standard |
|---|
| previousVisitAmount (optional) | Int | Anzahl der vorherigen Besuche, aus denen Daten abgerufen werden sollen. Zahl zwischen 1 und 25 | 1 |
| currentVisit (optional) | Bool | Wenn true, werden Daten des aktuellen Besuchs abgerufen | true |
| customData (optional) | Bool | Wenn true, werden custom data abgerufen. | true |
| conversions (optional) | Bool | Wenn true, werden Conversion-Daten abgerufen. | false |
| experiments (optional) | Bool | Wenn true, werden Experimentdaten abgerufen. | false |
| geolocation (optional) | Bool | Wenn true, werden Geolokalisierungsdaten abgerufen. | false |
| kcs (optional) | Bool | Wenn true, wird der Kameleoon Conversion Score (KCS) abgerufen. Erfordert das AI Predictive Targeting Add-on | false |
| visitorCode (optional) | Bool | Wenn true, ruft Kameleoon den visitorCode aus dem letzten Besuch ab und verwendet ihn für den aktuellen Besuch. visitorCode ist erforderlich, wenn Sie sicherstellen möchten, dass der Besucher, identifiziert durch seinen visitorCode, bei Cross-Device-Experimenten immer die gleiche Variation über Besuche hinweg erhält. | true |
| personalization (optional) | Bool | Wenn true, werden Personalisierungsdaten abgerufen. personalization ist für die Personalisierungsbedingung erforderlich | false |
| cbs (optional) | Bool | Wenn true, werden Contextual Bandit-Score-Daten abgerufen. | false |
getVisitorWarehouseAudience()
- 🔄 Führt eine asynchrone Anfrage durch
Ruft alle Audience-Daten ab, die mit dem Besucher in Ihrem Data Warehouse verknüpft sind. Der optionale Parameter warehouseKey ist in der Regel Ihre interne Benutzer-ID. Der Parameter customDataIndex entspricht der Kameleoon custom data, die Kameleoon zum Ansprechen Ihrer Besucher verwendet. Weitere Details finden Sie in der Warehouse-Targeting-Dokumentation.
Da ein Serveraufruf erforderlich ist, ist dieser Mechanismus asynchron. Daher sollten Sie entweder:
- Einen
completion-Callback als Argument an die Methode übergeben, um sicherzustellen, dass Sie benachrichtigt werden, wenn die Daten erfolgreich abgerufen und dem Besucher hinzugefügt wurden.
- Coroutines für die asynchrone Verarbeitung verwenden.
Es wird empfohlen, nur auf fehlgeschlagene Ergebnisse zu prüfen. Falls erforderlich, kann jedoch überprüft werden, ob die Daten dem Besucher hinzugefügt wurden und für Targeting-Zwecke verfügbar sind (oder zum Debugging, obwohl die Verwendung von Logging zum Debugging besser ist).
// Fetch visitor warehouse audience data
kameleoonClient.getVisitorWarehouseAudience(customDataIndex: 10) { result in
switch result {
case .success(let customData):
// Data was added. You can access it from `customData`
case .failure:
// Handle the error, which contains information about the request failure
}
}
// Fetch visitor warehouse audience data with a specific warehouse key
kameleoonClient.getVisitorWarehouseAudience(
warehouseKey: "warehouseKey", customDataIndex: 10
) { result in
switch result {
case .success(let customData):
// Data was added. You can access it from `customData`
case .failure:
// Handle the error, which contains information about the request failure
}
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| warehouseKey (optional) | String | Der eindeutige Schlüssel zur Identifizierung der Warehouse-Daten (in der Regel Ihre interne Benutzer-ID). | "" |
| customDataIndex (erforderlich) | Int | Eine ganze Zahl, die den Index der custom data darstellt, die Sie zum Ansprechen Ihrer BigQuery Audiences verwenden möchten. | |
| completion | (Result<CustomData, Error>) -> Void | Der Callback, der die empfangenen Daten verarbeitet. | |
Ein häufiger Fehler ist der Aufruf von async-Funktionen mit try? oder innerhalb eines verschachtelten do-catch-Blocks ohne CancellationError erneut auszulösen. Dies kann die Aufgabenstornierung beeinträchtigen und zu unerwartetem Verhalten führen.
Um eine korrekte Aufgabenstornierung zu gewährleisten, vermeiden Sie die Verwendung von try? oder do-catch um async-Funktionen, es sei denn, Sie lösen CancellationError explizit erneut aus.
// Fetch visitor warehouse audience data
Task {
do {
let customData = try await kameleoonClient.getVisitorWarehouseAudience(customDataIndex: 10)
// Data was added. You can access it from `customData`
} catch {
// Handle the error, which contains information about the request failure
}
}
// Fetch visitor warehouse audience data with a specific warehouse key
Task {
do {
let customData = try await kameleoonClient.getVisitorWarehouseAudience(
warehouseKey: "warehouseKey", customDataIndex: 10
)
// Data was added. You can access it from `customData`
} catch {
// Handle the error, which contains information about the request failure
}
}
Argumente
| Name | Typ | Beschreibung | Standard |
|---|
| warehouseKey (optional) | String | Der eindeutige Schlüssel zur Identifizierung der Warehouse-Daten (in der Regel Ihre interne Benutzer-ID). | "" |
| customDataIndex (erforderlich) | Int | Eine ganze Zahl, die den Index der custom data darstellt, die Sie zum Ansprechen Ihrer BigQuery Audiences verwenden möchten. | |
Rückgabewert
| Typ | Beschreibung |
|---|
CustomData | Ein für einen Besucher hinzugefügter CustomData-Eintrag. Im Allgemeinen können Sie diesen Wert ignorieren, aber er kann für Testzwecke nützlich sein. |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
Error | Gibt an, dass die Anfrage aufgrund eines Fehlers fehlgeschlagen ist. |
setLegalConsent()
Sie müssen diese Methode verwenden, um anzugeben, ob der Besucher seine rechtliche Zustimmung zur Verwendung seiner personenbezogenen Daten gegeben hat. Das Setzen des Parameters legalConsent auf false beschränkt die Datentypen, die Sie in Tracking-Anfragen aufnehmen können. Diese Methode hilft Ihnen, rechtliche und regulatorische Anforderungen einzuhalten und gleichzeitig verantwortungsbewusst mit Besucherdaten umzugehen. Weitere Informationen zu personenbezogenen Daten finden Sie in den Richtlinien zur Einwilligungsverwaltung.
Argumente
| Name | Typ | Beschreibung |
|---|
| legalConsent | boolean | Ein boolescher Wert, der den Status der rechtlichen Zustimmung darstellt. true gibt an, dass der Besucher seine rechtliche Zustimmung gegeben hat; false gibt an, dass der Besucher seine rechtliche Zustimmung nie erteilt oder widerrufen hat. Dieses Feld ist erforderlich. |
kameleoonClient.setLegalConsent(true)
Datentypen
In diesem Abschnitt werden die von Kameleoon unterstützten Datentypen aufgeführt. Es werden mehrere Standarddatentypen bereitgestellt sowie der Typ CustomData zum Definieren benutzerdefinierter Datentypen.
Conversion
Der hier gespeicherte Datensatz Conversion kann verwendet werden, um Experiment- und Personalisierungsberichte nach einem zugehörigen Ziel zu filtern.
- Jeder Besucher kann mehrere
Conversion-Objekte haben.
- Die
goalId finden Sie in der Kameleoon-App.
| Name | Typ | Beschreibung | Standard |
|---|
| goalId (erforderlich) | Int | ID des Ziels. | |
| revenue (optional) | Double | Umsatz der Conversion | 0 |
| negative (optional) | Bool | Definiert, ob der Umsatz positiv oder negativ ist. | false |
| metadata (optional) | CustomData... / [CustomData] | Metadaten der Conversion. | [] |
kameleoonClient.addData(Conversion(goalId: 32, revenue: 10.0, negative: false))
kameleoonClient.addData(Conversion(goalId: 32, metadata: CustomData(id: 1, values: "metadata")))
CustomData
CustomData ermöglicht es, jeden Datentyp einfach mit jedem Besucher zu verknüpfen. CustomData kann dann als Targeting-Bedingung in Segmenten oder als Filter/Aufschlüsselung in Experimentberichten verwendet werden.
Weitere Informationen zu custom data finden Sie in diesem Artikel.
| Name | Typ | Beschreibung | |
|---|
| index/name (erforderlich) | Int/String | Index oder Name der custom data. Entweder index oder name muss angegeben werden, um die Daten zu identifizieren. | |
| overwrite (optional) | Bool | Flag, um explizit zu steuern, wie die Werte gespeichert werden und wie sie in Berichten erscheinen. Mehr anzeigen | true |
| values (erforderlich) | String... oder [String] | Werte der zu speichernden custom data. | |
- Jeder Besucher darf nur ein
CustomData pro eindeutigem index haben. Das Hinzufügen eines weiteren CustomData mit demselben index ersetzt das bestehende CustomData.
- Der custom data-
index kann im Custom Data dashboard unter der Spalte “INDEX” gefunden werden.
- Um zu verhindern, dass das SDK Daten mit dem ausgewählten Index aus Datenschutzgründen an die Kameleoon-Server sendet, aktivieren Sie beim Erstellen von custom data die Option Use this data only locally for targeting purposes.
- Das Hinzufügen einer mit einem Namen erstellten
CustomData-Instanz, wenn die Konfiguration der SDK-Instanz nicht aktuell ist oder der Name nicht registriert ist, führt dazu, dass die Daten ignoriert werden.
kameleoonClient.addData(CustomData(index: 1, values: "value"))
// With several values
kameleoonClient.addData(CustomData(index: 1, values: "value 1", "value 2"))
// To set the 'overwrite' flag to false
kameleoonClient.addData(CustomData(index: 1, overwrite: false, values: ["first value", "second value"]))
// To use a name instead of the index
kameleoonClient.addData(CustomData(name: "my-custom-data", values: "value"))
Device
Seit dem iOS SDK 4.14.0 wird das Device automatisch basierend auf dem Wert von UIDevice.current.userInterfaceIdiom erkannt. Sie können es jedoch bei Bedarf manuell überschreiben.
Speichert Informationen über das Gerät des Benutzers.
| Name | Typ | Beschreibung |
|---|
| device | Device | Liste der Geräte: phone, tablet, desktop. Dieses Feld ist erforderlich. |
try? kameleoonClient.addData(Device.desktop);
Geolocation
Geolocation enthält die Geolokalisierungsdetails des Besuchers.
| Name | Typ | Beschreibung |
|---|
| country (erforderlich) | String | Das Land des Besuchers. |
| region (optional) | String? | Die Region des Besuchers. |
| city (optional) | String? | Die Stadt des Besuchers. |
| postalCode (optional) | String? | Die Postleitzahl des Besuchers. |
| latitude (optional) | Double? | Die Breitengradkoordinate, die den Standort des Besuchers darstellt. Die Koordinatenzahl steht für Dezimalgrad. |
| longitude (optional) | Double? | Die Längengradkoordinate, die den Standort des Besuchers darstellt. Die Koordinatenzahl steht für Dezimalgrad. |
- Jeder Besucher kann nur eine
Geolocation haben. Das Hinzufügen einer zweiten Geolocation überschreibt die erste.
kameleoonClient.addData(Geolocation(country: "France", region: "Île-de-France", city: "Paris"));
Rückgabetypen
DataFile
Das DataFile enthält die Konfigurationsdetails des SDK.
Es kann bei Bedarf um zusätzliche Informationen erweitert werden, wenn Kunden dies wünschen. Wenn Sie weitere Details benötigen, wenden Sie sich bitte an Ihren Customer Success Manager.
| Name | Typ | Beschreibung |
|---|
| featureFlags | [String: FeatureFlag] | Eine Map von FeatureFlag-Objekten, indexiert nach feature flag-Schlüsseln. |
| dateModified | Int | Der Zeitstempel (in Millisekunden), der angibt, wann das DataFile zuletzt geändert wurde. |
// Retrieves the dictionary of feature flags from the DataFile.
// The dictionary is keyed by feature flag identifiers, with each value being a FeatureFlag object.
let featureFlags = dataFile.featureFlags
// Retrieves the last modification timestamp of the DataFile.
// The value is an Int representing milliseconds since the Unix epoch.
let dateModified = dataFile.dateModified
FeatureFlag
Der FeatureFlag stellt eine Reihe von Eigenschaften dar, die einen feature flag selbst definieren — z. B. seine Variations, Rules, den Umgebungsstatus und andere zugehörige Details.
Er kann bei Bedarf um zusätzliche Informationen erweitert werden, wenn Kunden dies wünschen. Wenn Sie weitere Details benötigen, wenden Sie sich bitte an Ihren Customer Success Manager.
| Name | Typ | Beschreibung |
|---|
| environmentEnabled | Bool | Gibt an, ob der feature flag in der aktuellen Umgebung aktiviert ist. |
| defaultVariationKey | String | Der Schlüssel der mit dem feature flag verknüpften Standardvariation. |
| variations | [String: Variation] | Eine Map von Variation-Objekten, indexiert nach Variationsschlüsseln. |
| rules | [Rule] | Eine Liste von Rule-Objekten |
// Check whether the feature flag is enabled in the current environment
let isEnvironmentEnabled = featureFlag.environmentEnabled
// Retrieve the key of the default variation
let defaultVariationKey = featureFlag.defaultVariationKey
// Retrieve the default variation object
let defaultVariation = featureFlag.defaultVariation
// Retrieve all variations of the feature flag as a map (key = variation key, value = Variation object)
let variations = featureFlag.variations
// Retrieve all targeting rules associated with the feature flag
let rules = featureFlag.rules
Rule
Die Rule stellt eine Reihe von Eigenschaften dar, die eine Regel selbst definieren — z. B. ihre Variations.
Sie kann bei Bedarf um zusätzliche Informationen erweitert werden, wenn Kunden dies wünschen. Wenn Sie weitere Details benötigen, wenden Sie sich bitte an Ihren Customer Success Manager.
| Name | Typ | Beschreibung |
|---|
| variations | [String: Variation] | Eine Map von Variation-Objekten, indexiert nach Variationsschlüsseln. |
// Retrieve all variations of the rule as a map (key = variation key, value = Variation object)
let variations = rule.variations
Variation
Variation enthält Informationen über die dem Besucher zugewiesene Variation (oder die Standardvariation, wenn keine spezifische Zuweisung vorhanden ist).
| Name | Typ | Beschreibung |
|---|
| name | String | Der Name der Variation. |
| key | String | Der eindeutige Schlüssel zur Identifizierung der Variation. |
| id | Int | Die ID der zugewiesenen Variation (oder -1, wenn es sich um die Standardvariation handelt). |
| experimentId | Int | Die ID des mit der Variation verknüpften Experiments (oder -1, falls Standard). |
| variables | [String: Variable] | Eine Map mit den Variablen der zugewiesenen Variation, indexiert nach Variablennamen. variables kann eine leere Sammlung sein, wenn keine Variablen verknüpft sind. |
- Das
Variation-Objekt liefert Details über die zugewiesene Variation und das zugehörige Experiment, während das Variable-Objekt spezifische Details zu jeder Variablen innerhalb einer Variation enthält.
- Stellen Sie sicher, dass Ihr Code den Fall handhabt, in dem
id oder experimentId -1 sein kann, was eine Standardvariation anzeigt.
- Die
variables-Map kann leer sein, wenn keine Variablen mit der Variation verknüpft sind.
// Retrieving the variation name
let variationName = variation.name
// Retrieving the variation key
let variationKey = variation.key
// Retrieving the variation id
let variationId = variation.id
// Retrieving the experiment id
let experimentId = variation.experimentId
// Retrieving the variables map
let variables = variation.variables
Variable
Variable enthält Informationen über eine Variable, die mit der zugewiesenen Variation verknüpft ist.
| Name | Typ | Beschreibung |
|---|
| key | String | Der eindeutige Schlüssel zur Identifizierung der Variablen. |
| type | String | Der Typ der Variablen. Mögliche Werte: BOOLEAN, NUMBER, STRING, JSON. |
| value | Any? | Der Wert der Variablen, der von einem der folgenden Typen sein kann: Bool, Int, Double, String, [String: Any] (json-Objekt), [Any] (json-Array). |
// Retrieving the variables map
let variables = variation.variables
// Variable type can be retrieved for further processing
let type = variables["isDiscount"]?.type ?? ""
// Get the bool value of "isDiscount" (default to false if missing or not a Bool)
let isDiscount = variables["isDiscount"]?.value as? Bool ?? false
// Get the numeric value of "number" as an Int (default to 0 if missing or not numeric)
let number = (variables["number"]?.value as? NSNumber)?.intValue ?? 0
// Get the String value of "title" (default to an empty string if missing or not a String)
let title = variables["title"]?.value as? String ?? ""
Veraltete Methoden
Diese Methoden sind veraltet und werden in der SDK-Version 5.0.0 entfernt.
getFeatureVariationKey()
- 📨 Sendet Tracking-Daten an Kameleoon
Verwenden Sie diese Methode, um den Schlüssel der Feature-Variation für einen bestimmten Benutzer abzurufen. Diese Methode nimmt einen featureKey als erforderliches Argument, um den Variationsschlüssel für den angegebenen Benutzer abzurufen.
Wenn der Besucher noch nie mit diesem feature flag verknüpft war, gibt das SDK einen zufällig zugewiesenen Variationsschlüssel zurück (gemäß den feature flag-Regeln). Wenn der Besucher bereits mit diesem feature flag registriert ist, gibt diese Methode den vorherigen Variationsschlüssel zurück. Wenn der Besucher keiner der Regeln entspricht, wird die in der Kameleoon-App definierte Standardvariation zurückgegeben.
Stellen Sie sicher, dass Sie eine ordnungsgemäße Fehlerbehandlung wie im Beispielcode gezeigt einrichten, um mögliche Fehler abzufangen.
let featureKey = "new_checkout"
var variationKey = ""
do {
variationKey = try kameleoonClient.getFeatureVariationKey(featureKey: featureKey)
switch variationKey {
case "variation 1":
// The visitor has been bucketed with variation 1 key
case "variation 2":
// The visitor has been bucketed with variation 1 key
default:
//The visitor has been bucketed with the default variation or is part of the unallocated traffic sample
}
} catch {
switch error {
case KameleoonError.sdkNotReady:
// Exception indicating that the SDK has not completed its initialization yet.
case KameleoonError.Feature.notFound:
// The feature key is not in the configuration file that has been fetched by the SDK. Trigger the old checkout for this visitor.
case KameleoonError.Feature.environmentDisabled:
// The feature flag is disabled for the environment.
default:
// Any other error.
}
}
getActiveFeatureList()
Um die Liste der feature flag-Schlüssel abzurufen, die derzeit für den Besucher verfügbar und aktiv sind.
let activeFeatureFlags = kameleoonClient.getActiveFeatureList()
Rückgabewert
| Typ | Beschreibung |
|---|
| [String] | Liste der feature flag-Schlüssel, die für den Besucher aktiv sind |
getActiveFeatures()
Die Methode getActiveFeatures ruft Informationen über die aktiven feature flags ab, die für den angegebenen Visitor Code verfügbar sind.
let activeFeatures = kameleoonClient.getActiveFeatures()
Rückgabewert
| Typ | Beschreibung |
|---|
[String: Types.Variation] | Ein Dictionary, das die dem Besucher zugewiesenen Variationen für jede aktive Funktion unter Verwendung der Schlüssel der entsprechenden aktiven Funktionen enthält. |
getFeatureVariable()
- 📨 Sendet Tracking-Daten an Kameleoon
- Verwenden Sie stattdessen
getVariation().
- Diese Methode hieß zuvor
obtainFeatureVariable() und wurde in der SDK-Version 4.0.0 entfernt.
Rufen Sie diese Methode auf, um die Feature-Variable eines Variationsschlüssels abzurufen, der mit einem Benutzer verknüpft ist.
Diese Methode nimmt featureKey und variableKey als erforderliche Argumente, um die Variable des Variationsschlüssels für einen bestimmten Benutzer abzurufen.
Wenn ein Besucher noch nie mit diesem feature flag verknüpft war, gibt das SDK einen Variablenwert für den Variationsschlüssel zurück, den es gemäß den feature flag-Regeln zufällig zuweist. Wenn der Benutzer bereits mit diesem feature flag registriert ist, gibt das SDK den Variablenwert für die zuvor verknüpfte Variation zurück. Wenn der Benutzer keiner der Regeln entspricht, wird die Standardvariable zurückgegeben.
String featureKey = "myFeature"
String variableKey = "myVariable"
try {
let variable = kameleoonClient.getFeatureVariable(featureKey: featureKey, variableKey: variableKey)
// your custom code, depending on variableValue
} catch {
switch error {
case KameleoonError.sdkNotReady:
// Exception indicating that the SDK has not completed its initialization.
case KameleoonError.Feature.notFound:
// The Feature Key is not in the configuration file that has been fetched by the SDK. Trigger the old checkout for this visitor.
case KameleoonError.Feature.environmentDisabled:
// The feature flag is disabled for the environment.
case KameleoonError.Feature.variableNotFound:
// Exception indicating that the requested variable has not been found. Check that the variable's key matches the one in your code.
default:
// Any other error.
}
}
Argumente
| Name | Typ | Beschreibung |
|---|
| featureKey | String | Identifikationsschlüssel der Funktion, die Sie abrufen möchten. Dieses Feld ist erforderlich. |
| variableKey | String | Name der Variablen, für die Sie einen Wert abrufen möchten. Dieses Feld ist erforderlich. |
Rückgabewert
| Typ | Beschreibung |
|---|
| Any | Mit diesem feature flag verknüpfte Daten. Die Werte können Int, String, Bool oder Dictionary sein (je nach dem in der Weboberfläche definierten Typ). |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
| KameleoonError.sdkNotReady | Ausnahme, die anzeigt, dass das SDK nicht vollständig initialisiert ist. |
| KameleoonError.Feature.notFound | Ausnahme, die anzeigt, dass die angeforderte Feature-ID nicht in der internen Konfiguration des SDK gefunden wurde. Diese Ausnahme bedeutet in der Regel, dass der feature flag auf der Kameleoon-Seite noch nicht aktiviert wurde (aber der Code, der die Funktion implementiert, bereits in der Webanwendung bereitgestellt ist). |
| KameleoonException.Feature.environmentDisabled | Ausnahme, die anzeigt, dass der feature flag für die aktuelle Umgebung des Besuchers (z. B. production, staging oder development) deaktiviert ist. |
| KameleoonError.Feature.variableNotFound | Ausnahme, die anzeigt, dass die angeforderte Variable nicht gefunden wurde. Stellen Sie sicher, dass der Schlüssel der Variablen in der Kameleoon-App mit dem Schlüssel in Ihrem Code übereinstimmt. |
getFeatureVariationVariables()
- Verwenden Sie stattdessen
getVariation().
- Diese Methode hieß zuvor
getFeatureAllVariables und wurde in der SDK-Version 4.0.0 entfernt.
Um alle Variablen für eine Funktion abzurufen, rufen Sie diese Methode auf. Sie können Ihre Feature-Variablen in der Kameleoon-App ändern.
Diese Methode nimmt featureKey als Argument. Sie gibt Daten mit dem Typ [String: Any] zurück, wie in der Weboberfläche definiert. Sie löst eine Ausnahme (KameleoonError.Feature.notFound) aus, wenn die angeforderte Funktion nicht in der internen Konfiguration des SDK gefunden wurde.
let featureKey = "myFeature"
let variationKey = "on"
do {
allVariables = try kameleoonClient.getFeatureVariationVariables(featureKey: featureKey, variationKey: variationKey);
} catch KameleoonError.Feature.notFound {
// The feature is not activated in Kameleoon.
} catch KameleoonError.Feature.environmentDisabled {
// The feature flag is disabled for the environment.
} catch {
// This is a generic Exception handler that will handle all errors.
}
Argumente
| Name | Typ | Beschreibung |
|---|
| featureKey | String | Identifikationsschlüssel der Funktion, die Sie abrufen möchten. Dieses Feld ist erforderlich. |
| variationKey | String | Der Schlüssel der Variation, die Sie abrufen möchten. Dieses Feld ist erforderlich. |
Rückgabewert
| Typ | Beschreibung |
|---|
| [String: Any] | Mit diesem feature flag verknüpfte Daten. Die Werte können Int, String, Bool oder Dictionary sein (je nach dem in der Weboberfläche definierten Typ). |
Ausgelöste Fehler
| Typ | Beschreibung |
|---|
| KameleoonError.sdkNotReady | Ausnahme, die anzeigt, dass das SDK nicht vollständig initialisiert ist. |
| KameleoonError.Feature.notFound | Ausnahme, die anzeigt, dass die angeforderte Feature-ID nicht in der internen Konfiguration des SDK gefunden wurde. Diese Ausnahme bedeutet in der Regel, dass der feature flag in der Kameleoon-App nicht aktiviert wurde (aber der Code, der die Funktion implementiert, bereits in der Webanwendung bereitgestellt ist). |
| KameleoonException.Feature.environmentDisabled | Ausnahme, die anzeigt, dass der feature flag für die aktuelle Umgebung des Besuchers (z. B. production, staging oder development) deaktiviert ist. |
| KameleoonError.Feature.variationNotFound | Ausnahme, die anzeigt, dass der angeforderte Variationsschlüssel nicht in der internen Konfiguration des SDK gefunden wurde. Diese Ausnahme bedeutet, dass der feature flag vom SDK noch nicht abgerufen wurde, was passieren kann, wenn sich das SDK im Polling-Modus befindet. |
let featureKey = "myFeature"
let variationKey = "on"
do {
allVariables = try kameleoonClient.getFeatureVariationVariables(featureKey: featureKey, variationKey: variationKey);
} catch KameleoonError.Feature.notFound {
// The feature is not activated in Kameleoon.
} catch KameleoonError.Feature.environmentDisabled {
// The feature flag is disabled for the environment.
} catch {
// This is a generic Exception handler that will handle all errors.
}