> ## Documentation Index
> Fetch the complete documentation index at: https://docs.kameleoon.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Go SDK
> Intégrez le SDK Go de Kameleoon pour exécuter des expériences et activer des feature flags dans les applications et services web Go.
Avec le SDK Go, vous pouvez exécuter des expériences et activer des feature flags. L'intégration de notre SDK dans votre application web est simple, et son empreinte (utilisation de la mémoire et du réseau) est faible.
**Pour commencer** : Pour obtenir de l'aide pour démarrer, consultez le [guide du développeur](#guide-du-développeur).
**Journal des modifications** : Dernière version du SDK Go : 3.18.0 [Changelog](https://github.com/Kameleoon/client-go/blob/master/CHANGELOG.md).
**Méthodes du SDK** : Pour la documentation complète de référence du SDK Go, consultez la section [référence](#référence).
## Guide du développeur
Suivez cette section pour installer et configurer le SDK, et découvrir les fonctionnalités avancées.
### Pour commencer
#### Installation du client Go
Pour installer le SDK Go de Kameleoon, utilisez la commande `go get` et installez notre package directement depuis notre dépôt GitHub. Exécutez simplement la commande ci-dessous :
```shell theme={null}
go get github.com/Kameleoon/client-go/v3
```
#### Configuration supplémentaire
Pour fournir des paramètres supplémentaires au SDK Go, vous pouvez utiliser un fichier de configuration, qui vous permet de personnaliser le comportement du SDK. Vous pouvez télécharger un exemple de fichier de configuration [ici](/assets/developer-docs/sdks/web-sdks/client-configs/client-go.yaml).
Nous recommandons d'installer ce fichier au chemin par défaut `/etc/kameleoon/client-go.yaml`, qui sera lu automatiquement. Si vous devez personnaliser ce chemin, vous pouvez fournir un argument supplémentaire à la méthode `NewClient()`. Spécifiez soit une chaîne indiquant un chemin alternatif vers le fichier de configuration, soit ajoutez un objet JavaScript (map) contenant la configuration.
La version actuelle du SDK Go dispose des clés suivantes dans le fichier de configuration :
| Clé | Description | Valeur par défaut |
| --------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------- |
| `ClientID` / `client_id` (*obligatoire*) | Requis pour l'authentification au service Kameleoon. Pour trouver votre `client_id`, consultez la documentation [API credentials](/user-manual/account-and-team-management/users-and-teams/api-credentials). | |
| `ClientSecret` / `client_secret` (*obligatoire*) | Requis pour l'authentification au service Kameleoon. Pour trouver votre `client_secret`, consultez la documentation [API credentials](/user-manual/account-and-team-management/users-and-teams/api-credentials). | |
| `SessionDuration` / `session_duration` (*optionnel*) | Désigne l'intervalle de temps prédéfini pendant lequel Kameleoon stocke le visiteur et ses données associées en mémoire (RAM). Notez que l'augmentation de la durée de session augmente la quantité de RAM à allouer pour stocker les données des visiteurs. | `30` minutes |
| `RefreshInterval` / `refresh_interval` (*optionnel*) | Spécifie l'intervalle de rafraîchissement, en minutes, auquel le SDK récupère la configuration des expériences actives et des feature flags. La valeur détermine le temps maximal nécessaire pour propager les modifications, telles que l'activation ou la désactivation des feature flags ou le lancement d'expériences, vers vos serveurs de production. De plus, nous proposons un [mode streaming](/developer-docs/feature-experimentation/technical-reference/technical-considerations/#streaming-premium-option) qui utilise les événements envoyés par le serveur (SSE) pour pousser automatiquement de nouvelles configurations au SDK et appliquer ces nouvelles configurations en temps réel, sans aucun délai. | `60` minutes |
| `DefaultTimeout` / `default_timeout` (*optionnel*) | Spécifie le délai d'attente, en millisecondes, pour les requêtes réseau du SDK. Définissez la valeur à 30 secondes ou plus si vous n'avez pas une connexion stable. Certaines méthodes disposent d'un paramètre supplémentaire que vous pouvez utiliser pour remplacer le délai d'attente par défaut pour cette méthode particulière. Si vous ne spécifiez pas explicitement le délai d'attente pour une méthode, le SDK utilise cette valeur par défaut. | `10000` millisecondes |
| `TrackingInterval` / `tracking_interval` (*optionnel*) | Spécifie l'intervalle des requêtes de tracking en millisecondes. Tous les visiteurs que Kameleoon a évalués pour un feature flag ou dont les données ont été envoyées (flush) sont inclus dans cette requête de tracking, que le SDK effectue une fois par intervalle. La valeur minimale est `1000` ms, qui est également la valeur par défaut, et la valeur maximale est `5000` ms. | `1000` millisecondes |
| `Environment` / `environment` (*optionnel*) | Environnement à partir duquel la configuration du feature flag doit être utilisée. La valeur peut être `production`, `staging`, `development`. Consultez l'article [gestion des environnements](/user-manual/experimentation/feature-experimentation/configure-your-feature-flags/manage-environments) pour plus de détails. | `production` |
| `TopLevelDomain` / `top_level_domain` *(obligatoire en mode hybride)* | Le domaine de premier niveau actuel pour votre site web. Utilisez le format : `example.com`. N'incluez pas `https://`, `www`, ou d'autres sous-domaines. Kameleoon utilise cette information pour définir le cookie correspondant sur le domaine de premier niveau. | `""` |
| `ProxyUrl` / `proxy_url` (*optionnel*) | Définit l'hôte proxy pour tous les appels serveur sortants effectués par le SDK. | `""` |
| `NetworkDomain` / `network_domain` (*optionnel*) | Domaine personnalisé utilisé par les SDK pour les requêtes sortantes, souvent pour le proxy. Doit être un domaine valide (par exemple, example.com ou sub.example.com). Les formats invalides utilisent la valeur par défaut de Kameleoon. | `""` |
| `VerboseMode` / `verbose_mode` *(déprécié)* | Valeur booléenne (`true` ou `false`) qui active la journalisation supplémentaire, y compris les requêtes réseau et les informations de débogage. Ce champ est déprécié et sera supprimé dans la version `4.0.0` du SDK. Utilisez [`logging.SetLogLevel`](#niveaux-de-journalisation) à la place. | `false` |
Pour en savoir plus sur `client_id` et `client_secret`, et les instructions pour les obtenir, veuillez consulter cet [article](/user-manual/account-and-team-management/users-and-teams/api-credentials). Il convient de noter que notre SDK Go utilise l'API Automation et suit le flux des informations d'identification client OAuth 2.0.
#### Initialisation du client Kameleoon
Une fois notre SDK installé dans votre application, vous devez initialiser Kameleoon. Toutes les interactions avec le SDK, telles que le déclenchement d'une expérience, s'effectuent via l'objet (le client Kameleoon) créé à l'aide de la méthode `NewClient()`.
Vous pouvez personnaliser le comportement du SDK (par exemple, l'environnement ou les informations d'identification) en fournissant un [objet de configuration](#configuration-supplémentaire).
```go theme={null}
import (
kameleoon "github.com/Kameleoon/client-go/v3"
)
// First option
config := &kameleoon.KameleoonClientConfig{
Network: kameleoon.NetworkConfig{ // Optional
ProxyURL: "http://proxy-pass:1234/", // Optional
DoTimeout: 10 * time.Second, // Optional
ReadTimeout: 5 * time.Second, // Optional
WriteTimeout: 5 * time.Second, // Optional
MaxConnsPerHost: 10000, // Optional
},
ClientID: "your-client-id", // This field is required. Please enter your client_id here.
ClientSecret: "your-client-secret", // This field is required. Please enter your client_secret here.
TopLevelDomain: "example.com", // This field is strictly recommended, otherwise you may have problems when using subdomains.
RefreshInterval: time.Hour, // Optional (60 minutes by default)
TrackingInterval: time.Second, // Optional (1000 ms by default)
Environment: "staging", // Optional
SessionDuration: 30 * time.Minute, // Optional (30 minutes by default)
NetworkDomain: "example.com", // Optional
}
client, err := KameleoonClientFactory.Create("your-project-sitecode", config)
// Second option
config, err := LoadConfig("/etc/kameleoon/client-go.yaml")
client, err := KameleoonClientFactory.Create("your-project-sitecode", config)
// Notice: In the example above, the configuration is loaded every time. To load it once, use `CreateFromFile`.
// Third option
client, err := KameleoonClientFactory.CreateFromFile("your-project-sitecode", "/etc/kameleoon/client-go.yaml")
```
#### Activation d'un feature flag
##### Attribution d'un ID unique à un utilisateur
Pour attribuer un ID unique à un utilisateur, vous pouvez utiliser la méthode [`GetVisitorCode()`](#getvisitorcode). Si un **visitor code** n'existe pas (à partir du cookie des en-têtes de la requête), la méthode génère un ID unique aléatoire ou utilise un `defaultVisitorCode` que vous auriez généré. L'ID est ensuite défini dans un cookie des en-têtes de réponse.
Si vous utilisez Kameleoon en [mode hybride](/developer-docs/feature-experimentation/get-started/hybrid-experimentation), l'appel à la méthode `GetVisitorCode()` garantit que l'ID unique (**visitor code**) est partagé entre le fichier d'application `engine.js` (anciennement nommé `kameleoon.js`) et le SDK.
##### Récupération de la configuration d'un flag
Pour implémenter un feature flag dans votre code, vous devez d'abord créer le feature flag dans votre compte Kameleoon.
Pour déterminer le statut ou la variation d'un feature flag pour un utilisateur spécifique, vous devez utiliser la méthode [`GetVariation()`](#getvariation) ou [`IsFeatureActive()`](#isfeatureactive) pour récupérer la configuration basée sur le `featureKey`.
La méthode `GetVariation()` gère à la fois les feature flags simples avec des états ON/OFF et les flags plus complexes avec plusieurs variations. La méthode récupère la variation appropriée pour l'utilisateur en vérifiant les règles du feature, en assignant la variation et en la renvoyant en fonction du `featureKey` et du `visitorCode`.
La méthode `IsFeatureActive()` peut être utilisée si vous souhaitez récupérer la configuration d'un feature flag simple qui a uniquement un état ON ou OFF, par opposition aux feature flags plus complexes avec plusieurs variations ou options de ciblage.
Si votre feature flag a des variables associées (telles que des comportements spécifiques liés à chaque variation), `GetVariation()` vous permet également d'accéder à l'objet [`Variation`](#variation), qui fournit des détails sur la variation assignée et son expérience associée. Cette méthode vérifie si l'utilisateur est ciblé, trouve la variation assignée au visiteur et l'enregistre dans le stockage. Lorsque `GetVariationOptParams.Track=true`, le SDK enverra l'événement d'exposition à l'expérience spécifiée lors de la prochaine requête de tracking, qui est déclenchée automatiquement en fonction du [`tracking_interval`](#configuration-supplémentaire) du SDK. Par défaut, cet intervalle est défini à 1000 millisecondes (1 seconde).
La méthode `GetVariation()` vous permet de contrôler si le tracking est effectué. Si `GetVariationOptParams.Track=false`, aucun événement d'exposition ne sera envoyé par le SDK. Cela est utile si vous préférez ne pas suivre les données via le SDK et préférez vous appuyer sur le tracking côté client géré par le moteur Kameleoon, par exemple. De plus, définir `GetVariationOptParams.Track=false` est utile lorsque vous utilisez la méthode `GetVariations()`, où vous pourriez avoir besoin uniquement des variations pour tous les flags sans déclencher d'événements de tracking. Pour en savoir plus sur le fonctionnement du tracking, consultez [cet article](/developer-docs/feature-experimentation/technical-reference/faq-global#when-does-the-sdk-send-a-tracking-request-for-analytics)
##### Ajout de points de données pour cibler un utilisateur ou filtrer / segmenter les visites dans les rapports
Pour cibler un utilisateur, assurez-vous d'avoir ajouté des points de données pertinents à son profil avant de récupérer la variation du feature ou de vérifier si le flag est actif. Utilisez la méthode [`AddData()`](#adddata) pour ajouter ces points de données au profil de l'utilisateur.
Pour récupérer les points de données collectés sur d'autres appareils ou pour accéder aux données passées de l'utilisateur (collectées côté client lorsque vous utilisez Kameleoon en mode hybride), utilisez la méthode [`GetRemoteVisitorData()`](#getremotevisitordata). Cette méthode récupère les données de manière asynchrone à partir des serveurs. Il est important d'appeler `GetRemoteVisitorData()` *avant* de récupérer la variation ou de vérifier si le feature flag est actif, car ces données peuvent être nécessaires pour assigner un utilisateur à une variation donnée.
Pour en savoir plus sur les conditions de ciblage disponibles, consultez [l'article détaillé sur le sujet](/developer-docs/feature-experimentation/targeting-and-segmentation/native-segmentation).
De plus, les points de données que vous ajoutez au profil du visiteur seront disponibles lors de l'analyse de vos expériences, vous permettant de filtrer et de segmenter vos résultats par des facteurs tels que l'appareil et le navigateur. Le mode hybride de Kameleoon collecte automatiquement une variété de points de données côté client, ce qui facilite la segmentation de vos résultats sur la base de ces points de données pré-collectés. Voir la liste complète [ici](/fr/user-manual/experiment-analytics/analyze-results/results-page/results-page-settings#ventiler-l’audience).
Si vous devez suivre des points de données supplémentaires au-delà de ce qui est collecté automatiquement, vous pouvez utiliser la [fonctionnalité Custom Data](#customdata) de Kameleoon. Les Custom Data vous permettent de capturer et d'analyser des informations spécifiques pertinentes pour vos expériences. N'oubliez pas d'appeler la méthode [`Flush*()`](#flushall--flushvisitor--flushvisitorinstantly) pour envoyer les données collectées aux serveurs Kameleoon pour analyse.
Pour garantir l'exactitude de vos résultats, il est recommandé de filtrer les bots en utilisant le type de données [`UserAgent`](#useragent).
##### Suivi de l'exposition au flag et des conversions d'objectifs
Lorsqu'un utilisateur effectue une action souhaitée (telle qu'un achat), elle est enregistrée comme une conversion. Pour suivre les conversions, utilisez la méthode [`TrackConversion()`](#trackconversion) et fournissez les paramètres requis `visitorCode` et `goalId`.
La requête de suivi de conversion sera envoyée avec la prochaine requête de tracking planifiée, que le SDK envoie à intervalles réguliers (définis par [`tracking_interval`](#configuration-supplémentaire)). Si vous préférez envoyer la requête immédiatement, utilisez la méthode [`FlushVisitorInstantly()`](#flushall--flushvisitor--flushvisitorinstantly).
##### Envoi d'événements aux solutions d'analyse
Pour suivre les conversions et envoyer les événements d'exposition à votre solution d'analyse client, vous devez d'abord implémenter Kameleoon en [mode hybride](/developer-docs/feature-experimentation/get-started/hybrid-experimentation/). Ensuite, utilisez la méthode [`GetEngineTrackingCode()`](#getenginetrackingcode).
La méthode `GetEngineTrackingCode()` récupère le code de tracking unique nécessaire pour envoyer des événements d'exposition à votre solution d'analyse. L'utilisation de cette méthode vous permet d'enregistrer des événements et de les envoyer à la plateforme d'analyse de votre choix.
### Expérimentation cross-device
Pour prendre en charge les visiteurs qui accèdent à une application depuis plusieurs appareils, Kameleoon permet la synchronisation des données de visiteur précédemment collectées sur chacun des appareils du visiteur et la réconciliation de leur historique de visites entre les appareils grâce à l'expérimentation cross-device. Des études de cas et des informations détaillées sur la façon dont Kameleoon gère les données entre les appareils sont disponibles dans l'[article sur l'expérimentation cross-device](/developer-docs/cross-device-experimentation).
#### Synchronisation des custom data entre appareils
Bien que la synchronisation du mapping personnalisé soit utilisée pour aligner les données des visiteurs entre les appareils, elle n'est pas toujours nécessaire. Voici deux scénarios où la synchronisation du mapping personnalisé n'est pas requise :
**Même ID utilisateur entre les appareils**
Si le même ID utilisateur est utilisé de manière cohérente sur tous les appareils, la synchronisation est gérée automatiquement sans synchronisation du mapping personnalisé. Il suffit d'appeler la méthode `GetRemoteVisitorData()` lorsque vous souhaitez synchroniser les données collectées entre plusieurs appareils.
**Instances multi-serveurs avec des ID cohérents**
Dans des configurations complexes impliquant plusieurs serveurs (par exemple, des instances de serveurs distribués), où le même ID utilisateur est disponible sur tous les serveurs, la synchronisation entre les serveurs (avec `GetRemoteVisitorData()`) est suffisante sans synchronisation supplémentaire du mapping personnalisé.
Les clients qui ont besoin de données supplémentaires peuvent consulter la description de la méthode [`GetRemoteVisitorData()`](#getremotevisitordata) pour obtenir des conseils supplémentaires. Dans le code ci-dessous, on suppose que le même identifiant unique (dans ce cas, le `visitorCode`, qui peut également être appelé `userId`) est utilisé de manière cohérente entre les deux appareils pour une récupération précise des données.
Si vous souhaitez synchroniser les données collectées en temps réel, vous devez choisir la portée **Visitor** pour vos custom data.
```go title="Device A" theme={null}
// In this example, Custom data with index `90` was set to "Visitor" scope in Kameleoon.
const VisitorScopeCustomDataIndex = 90
kameleoonClient.AddData(visitorCode, types.NewCustomData(VisitorScopeCustomDataIndex, "your data"))
err := kameleoonClient.FlushVisitor(visitorCode)
```
```go title="Device B" theme={null}
// Before working with the data, call the `GetRemoteVisitorData` method.
_, err := kameleoonClient.GetRemoteVisitorData(visitorCode, true)
// After calling the method, the SDK on Device B will have access to CustomData of Visitor scope defined on Device A.
// So, "your data" will be available for targeting and tracking the visitor.
```
#### Utilisation des custom data pour la fusion de sessions
L'[expérimentation cross-device](/developer-docs/cross-device-experimentation) permet de combiner l'historique d'un visiteur sur chacun de ses appareils (réconciliation d'historique). La réconciliation d'historique permet de fusionner différentes sessions de visiteurs en une seule. Pour réconcilier l'historique des visites, utilisez [`CustomData`](#customdata) pour fournir un identifiant unique pour le visiteur. Pour plus d'informations, consultez la [documentation dédiée](/developer-docs/cross-device-experimentation/#activating-cross-device-history-reconciliation).
Une fois la réconciliation cross-device activée, l'appel à [`GetRemoteVisitorData()`](#getremotevisitordata) avec le paramètre `userId` récupère toutes les données connues pour un utilisateur donné.
Les sessions avec le même identifiant seront toujours affichées avec la même variation dans une expérience. Dans la vue Visitor des pages de résultats de votre expérience, ces sessions apparaîtront comme un seul visiteur.
La configuration du SDK garantit que les sessions associées voient toujours la même variation de l'expérience. Cependant, il existe certaines limites concernant l'allocation des variations cross-device. Ces limites sont décrites [ici](/developer-docs/cross-device-experimentation#critical-points-and-practical-insights).
Suivez le guide [activation de la réconciliation cross-device de l'historique](#expérimentation-cross-device) pour configurer vos custom data sur la plateforme Kameleoon.
Ensuite, vous pouvez utiliser le SDK normalement. Les méthodes suivantes peuvent être utiles dans le contexte de la fusion de sessions :
* `GetRemoteVisitorData()` avec l'ajout de `UniqueIdentifier(true)` - pour récupérer les données de tous les visiteurs liés.
* [`TrackConversion()`](#trackconversion) ou [`Flush*()`](#flushall--flushvisitor--flushvisitorinstantly) avec l'ajout de données `UniqueIdentifier(true)` - pour suivre certaines données pour un visiteur spécifique associé à un autre visiteur.
Comme les custom data que vous utilisez comme identifiant doivent être définies sur la **portée Visitor**, vous devez utiliser la [synchronisation cross-device des custom data](/developer-docs/cross-device-experimentation) pour récupérer l'identifiant avec la méthode [`GetRemoteVisitorData()`](#getremotevisitordata) sur chaque appareil.
Voici un exemple d'utilisation des custom data pour la fusion de sessions.
```go theme={null}
// In this example, `91` represents the Custom Data's index
// configured as a unique identifier in Kameleoon.
const MappingIndex = 91
const FeatureKey = "ff123"
// 1. Before the visitor is authenticated
// Retrieve the variation for an unauthenticated visitor.
// Assume `anonymousVisitorCode` is the randomly generated ID for that visitor.
anonymousVariation, err := kameleoonClient.GetVariation(anonymousVisitorCode, FeatureKey)
// 2. After the visitor is authenticated
// Assume `userId` is the authenticated visitor's visitor code.
kameleoonClient.AddData(anonymousVisitorCode, types.NewCustomData(MappingIndex, userId))
err := kameleoonClient.FlushVisitorInstantly(anonymousVisitorCode)
// Indicate that `userId` is a unique identifier.
kameleoonClient.AddData(userId, types.NewUniqueIdentifier(true))
// 3. After the visitor has been authenticated
// Retrieve the variation for the `userId`, which will match the anonymous visitor code's variation.
userVariation, err := kameleoonClient.GetVariation(userId, FeatureKey)
isSameVariation := userVariation.Key == anonymousVariation.Key // true
// The `userId` and `anonymousVisitorCode` are now linked and tracked as a single visitor.
err := kameleoonClient.TrackConversionRevenue(userId, 123, 10.0)
// Additionally, the linked visitors will share all fetched remote visitor data.
_, err := kameleoonClient.GetRemoteVisitorData(userId, true)
```
Dans cet exemple, l'application possède une page de connexion. Étant donné que l'ID utilisateur est inconnu au moment de la connexion, un identifiant de visiteur anonyme généré par la méthode [`GetVisitorCode()`](#getvisitorcode) est utilisé. Une fois que l'utilisateur s'est connecté, le visiteur anonyme est associé à l'ID utilisateur et utilisé comme identifiant unique pour le visiteur.
### Utilisation d'une clé de bucketing personnalisée
Par défaut, Kameleoon utilise un ID de visiteur anonyme unique (`visitorCode`) pour assigner les utilisateurs aux variations de feature flag. Cet ID est généralement généré et stocké sur l'appareil de l'utilisateur (dans un cookie de navigateur pour les SDK côté client et côté serveur — dans le stockage persistant pour les SDK mobiles). Cependant, dans certains scénarios, vous pouvez avoir besoin de garantir que tous les utilisateurs d'une même organisation voient la même variante d'un feature flag.
L'option **Custom Bucketing Key** vous permet de remplacer ce comportement par défaut en fournissant votre propre identifiant personnalisé pour le bucketing. Ce remplacement garantit que la logique d'attribution de Kameleoon utilise votre clé spécifiée au lieu du `visitorCode` par défaut.
#### Cas d'usage
L'utilisation d'une clé de bucketing personnalisée est essentielle pour maintenir la cohérence et la précision de vos attributions de feature flag, en particulier dans ces situations :
* **Expériences au niveau du compte ou de l'organisation :** Pour les produits B2B ou les scénarios où vous souhaitez assigner tous les utilisateurs d'une même organisation à la même variation, vous pouvez utiliser un identifiant comme un `accountId`. Les clés de bucketing personnalisées sont cruciales pour les A/B tests de fonctionnalités qui impactent une équipe ou une entreprise entière.
En implémentant une clé de bucketing personnalisée, vous garantissez une plus grande cohérence et précision dans vos expériences, conduisant à des résultats plus fiables et à une meilleure expérience utilisateur.
#### Détails techniques
Lorsque vous configurez une clé de bucketing personnalisée pour un feature flag, vous fournissez à Kameleoon un identifiant spécifique provenant des données de votre application :
```go theme={null}
client.AddData(visitorCode, types.NewCustomData(index, "newVisitorCode"))
```
* **Fournir la clé personnalisée :** Vous fournissez votre identifiant personnalisé au SDK Kameleoon en utilisant la méthode [`AddData()`](#adddata). Dans cette méthode, vous passerez votre clé de bucketing personnalisée choisie en tant qu'objet [`CustomData`](#customdata). Ici, `newVisitorCode` fait référence à l'identifiant que vous souhaitez utiliser pour votre bucketing (par exemple, le nouveau `userId` ou `accountId`).
Pour que la clé de bucketing personnalisée fonctionne correctement, elle doit également être définie et configurée pour le feature flag lors du processus de création ou de modification du flag. Sans cette configuration correspondante, le bucketing du SDK n'appliquera pas votre clé personnalisée. Pour des instructions détaillées sur la configuration dans Kameleoon, consultez cet [article](/user-manual/experimentation/feature-experimentation/create-and-manage-flags/create-a-feature-flag#Advanced_Flag_Settings).
* **Logique de bucketing :** Une fois qu'une clé de bucketing personnalisée est fournie via la méthode `AddData()`, tous les calculs de hachage pour l'attribution des utilisateurs aux variations utiliseront ce `newVisitorCode` (votre clé personnalisée) au lieu du `visitorCode` par défaut. L'utilisation du `newVisitorCode` signifie que la décision de bucketing est liée à votre identifiant personnalisé, garantissant des attributions cohérentes dans divers contextes où cet identifiant est présent.
* **Suivi des données et analyses :** Il est essentiel de noter que, bien que le `newVisitorCode` (votre clé personnalisée) soit utilisé pour les décisions de bucketing, **toutes les données ultérieures (événements de tracking et conversions, par exemple) sont envoyées et associées au `visitorCode` *original*.** Cette séparation garantit que vos analyses reflètent fidèlement les parcours et interactions individuels des utilisateurs dans le contexte plus large de votre expérience, même lorsque le bucketing est effectué à un niveau supérieur (comme un compte) ou sur plusieurs appareils/sessions. Vos données originales de visiteur restent intactes pour une production de rapports complète.
#### Exigences techniques
Pour utiliser efficacement une clé de bucketing personnalisée :
* La clé doit être une `string`.
* Elle doit être unique pour l'entité que vous souhaitez bucketer (par exemple, si vous utilisez un `userId`, l'ID de chaque utilisateur doit être unique).
* La clé doit être disponible pour le SDK au moment exact où la décision de feature flag est évaluée pour cet utilisateur ou cette requête.
### Conditions de ciblage
Les SDK Kameleoon prennent en charge une variété de conditions de ciblage prédéfinies que vous pouvez utiliser pour cibler les utilisateurs dans vos campagnes. Pour la liste des conditions prises en charge par ce SDK, consultez [utiliser l'historique de visite pour cibler les utilisateurs](/developer-docs/feature-experimentation/targeting-and-segmentation/native-segmentation).
Vous pouvez également utiliser vos propres [données externes pour cibler les utilisateurs](/developer-docs/apis/data-api-rest/tutorials/storing-and-retrieving-external-data-to-target-users).
### Journalisation
Le SDK génère des journaux pour refléter divers processus et problèmes internes.
#### Niveaux de journalisation
Le SDK prend en charge la configuration de la limitation de la journalisation par un niveau de journalisation.
```go theme={null}
import (
"development.kameleoon.net/sdk/go-sdk/v3/logging"
)
// The `NONE` log level does not allow logging.
logging.SetLogLevel(logging.NONE)
// The `ERROR` log level only allows logging issues that may affect the SDK's primary behavior.
logging.SetLogLevel(logging.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.
logging.SetLogLevel(logging.WARNING)
//The `INFO` log level allows logging general information on the SDK's internal processes.
// It extends the `WARNING` log level.
logging.SetLogLevel(logging.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 our support team
// to assist with internal troubleshooting.
logging.SetLogLevel(logging.DEBUG)
```
#### Gestion personnalisée des journaux
Le SDK écrit ses journaux dans la sortie de la console par défaut. Ce comportement peut être remplacé.
La limitation de la journalisation par un niveau de journalisation est effectuée séparément de la logique de gestion des journaux.
```go theme={null}
import (
"development.kameleoon.net/sdk/go-sdk/v3/logging"
"github.com/sirupsen/logrus"
)
type CustomLogger struct {
}
func NewCustomLogger() logging.LoggerWithLevel {
return &CustomLogger{}
}
func (dl CustomLogger) Log(level logging.LogLevel, message string) {
switch level {
case logging.NONE:
case logging.ERROR:
logrus.Error(message)
case logging.WARNING:
logrus.Warn(message)
case logging.INFO:
logrus.Info(message)
case logging.DEBUG:
logrus.Debug(message)
}
}
// 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.
logging.SetLogLevel(logging.DEBUG) // Optional; defaults to `logging.WARNING`.
logging.SetLogger(NewCustomLogger())
```
## Référence
Voici une documentation de référence complète du SDK Go.
### Initialisation
#### Create()
Appelez cette méthode avant toutes les autres pour initialiser le SDK. Cette méthode se trouve dans `KameleoonClientFactory`. Cela crée une instance de `KameleoonClient` pour gérer toutes les interactions entre le SDK et votre application.
```go theme={null}
const siteCode = "sitecode"
config := &kameleoon.KameleoonClientConfig{
// ...
}
client, err := KameleoonClientFactory.Create(siteCode, config)
```
##### Arguments
| Nom | Type | Description |
| ------------------------ | ----------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| siteCode (*obligatoire*) | string | Il s'agit d'une [clé unique](/user-manual/faq#how-do-i-find-my-sitecode) du projet Kameleoon que vous utilisez avec le SDK. |
| cfg (*obligatoire*) | \*KameleoonClientConfig | Représente soit le chemin vers le fichier de configuration du SDK, soit l'objet de configuration. Si vous fournissez l'objet de configuration, il doit contenir les clés de configuration correctes. |
##### Valeur de retour
| Type | Description |
| --------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| KameleoonClient | Une instance de **KameleoonClient** qui sera utilisée pour gérer vos expériences et feature flags. |
| error | Une erreur s'est produite dans l'appel à `Create`. L'erreur peut être `errs.SiteCodeIsEmpty` ou `errs.ConfigCredentialsInvalid`. |
#### CreateFromFile()
Appelez cette méthode avant toutes les autres pour initialiser le SDK. Cette méthode se trouve dans `KameleoonClientFactory`. Cela crée une instance de `KameleoonClient` pour gérer toutes les interactions entre le SDK et votre application.
```go theme={null}
const siteCode = "sitecode"
client, err := KameleoonClientFactory.CreateFromFile(siteCode, "/etc/kameleoon/client-go.yaml")
```
###### Arguments
| Nom | Type | Description |
| ------------------------ | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| siteCode (*obligatoire*) | string | Un **siteCode** Kameleoon. |
| cfgPath (*obligatoire*) | string | Un chemin vers le fichier de configuration. Le fichier est chargé uniquement si `KameleoonClientFactory` ne stocke pas d'instance `KameleoonClient` avec le **siteCode** spécifié. |
###### Valeur de retour
| Type | Description |
| --------------- | ---------------------------------------------------------------------------------------------------------------------- |
| KameleoonClient | Une instance de **KameleoonClient** qui sera utilisée pour gérer vos expériences et feature flags. |
| error | Une erreur s'est produite dans `Create`. L'erreur peut être `errs.SiteCodeIsEmpty` ou `errs.ConfigCredentialsInvalid`. |
#### Forget()
La méthode `Forget` supprime une instance `KameleoonClient` du `KameleoonClientFactory` avec le **siteCode** spécifié et libère les ressources utilisées par l'instance `KameleoonClient`. L'instance `KameleoonClient` ne doit pas être utilisée après l'appel de la méthode `Forget`.
```go theme={null}
const siteCode = "sitecode"
KameleoonClientFactory.Forget(siteCode)
```
###### Arguments
| Nom | Type | Description |
| -------- | ------ | ------------------------------------------------------------------------------------------------------------------ |
| siteCode | string | Le **siteCode** de l'instance `KameleoonClient` à supprimer de `KameleoonClientFactory`. Ce champ est obligatoire. |
#### WaitInit()
L'initialisation du client Kameleoon n'est pas immédiate, car elle nécessite une requête au serveur de notre CDN (Content Delivery Network) pour récupérer la configuration actuelle de toutes les expériences actives et feature flags.
La méthode `WaitInit` de `kameleoon.KameleoonClient` vous permet d'attendre jusqu'à ce que l'instance `KameleoonClient` soit prête à être utilisée.
```go theme={null}
err := client.WaitInit()
if err != nil {
// Client wasn't initialized properly
fmt.Println(err)
} else {
// The SDK has been initialized; you can fetch a feature flag / experiment configuration here.
}
```
##### Valeur de retour
| Type | Description |
| ----- | ---------------------------------------------------------------- |
| error | Une erreur s'est produite pendant le processus d'initialisation. |
### Feature flags et variations
#### IsFeatureActive() / IsFeatureActiveWithTracking()
* 📨 *Envoie des données de tracking à Kameleoon (selon le paramètre `track`)*
Utilisez cette méthode si vous souhaitez récupérer la configuration d'un feature flag simple, qui a uniquement un état ON / OFF, par opposition aux feature flags plus complexes avec plusieurs variations ou options de ciblage. Si votre feature flag a des variations et des variables, vous devriez utiliser la méthode [`GetVariation`](#getvariation).
Elle prend un **visitorCode** et un **featureKey** comme arguments obligatoires pour vérifier si le feature flag est actif pour un utilisateur donné.
Si l'utilisateur n'a pas été associé à votre feature flag auparavant, le SDK renvoie une valeur booléenne aléatoire (**true** si l'utilisateur doit avoir cette fonctionnalité ou **false** sinon). Cependant, si l'utilisateur est déjà enregistré pour ce feature flag, le SDK détecte la valeur précédente du feature flag.
Il est important de mettre en place une gestion appropriée des erreurs dans votre code pour capturer toute exception potentielle qui pourrait survenir, comme illustré dans l'exemple de code.
Si vous spécifiez un `visitorCode`, la méthode `IsFeatureActive` l'utilise comme identifiant unique de visiteur, ce qui est utile pour l'[expérimentation cross-device](/developer-docs/cross-device-experimentation). Lorsque vous spécifiez un `visitorCode` et définissez le paramètre `isUniqueIdentifier` sur `true`, le SDK lie les données envoyées (flush) au visiteur associé à l'identifiant spécifié.
Le paramètre `isUniqueIdentifier` est déprécié. Veuillez utiliser [`UniqueIdentifier`](#uniqueidentifier) à la place.
L'`isUniqueIdentifier` peut être utile dans des situations particulières ; par exemple, si vous ne pouvez pas accéder au `visitorCode` anonyme attribué à un visiteur, mais que vous pouvez utiliser un ID interne lié à ce visiteur via la fusion de sessions.
Kameleoon utilise le tracking pour compter les sessions et les visiteurs lorsque vous appelez certaines méthodes, telles que `IsFeatureActive()`, `GetVariation()` ou `GetVariations()`.
Utilisez la valeur par défaut `true` pour le paramètre `GetVariationOptParams.Track` lorsque vous exposez les visiteurs à une variation et devez les compter. Définissez le paramètre `GetVariationOptParams.Track` sur `false` uniquement si vous appelez ces méthodes avant d'exposer les visiteurs.
Par exemple, si vous appelez `GetVariations()` pour récupérer toutes les variations avant d'exposer les visiteurs, définissez le paramètre `GetVariationsOptParams.Track` sur `false`. Ce réglage empêche Kameleoon de compter prématurément une session. Vous pouvez ensuite déclencher le tracking ultérieurement lorsque vous exposez explicitement le visiteur.
Kameleoon envoie les données de tracking toutes les secondes par défaut. Vous pouvez configurer cet intervalle jusqu'à cinq secondes en utilisant l'option de configuration de l'intervalle de tracking. Kameleoon regroupe les événements de tracking dans une seule session tant que l'intervalle entre les événements est inférieur à 30 minutes. Si plus de 30 minutes s'écoulent entre les événements de tracking, Kameleoon considère les événements comme des sessions distinctes. Une visite apparaît dans vos rapports 30 minutes après le dernier événement enregistré de la session.
```go theme={null}
const featureKey = "new_checkout"
// Check if a Feature Flag is active (ON / OFF)
hasNewCheckout, err := client.IsFeatureActive(visitorCode, featureKey)
// disabling tracking
hasNewCheckout, err := client.IsFeatureActiveWithTracking(visitorCode, featureKey, false)
if err != nil {
switch err.(type) {
case *errs.VisitorCodeInvalid:
// The provided visitor code is not valid. Trigger the old checkout for this visitor.
hasNewCheckout = false
case *errs.FeatureConfigNotFound:
// The Feature Key is not yet in the configuration file that has been fetched by the SDK. Trigger the old checkout for this visitor.
hasNewCheckout = false
default:
// Handle unexpected errors
panic(err)
}
}
if hasNewCheckout {
// Implement new checkout code here
}
```
La méthode `IsFeatureActive()` évalue la variante servie, pas l'état du flag maître. Si vous excluez des règles, la méthode utilise l'état par défaut **Then, for everyone else serve**. Si vous sélectionnez **Off** pour cet état par défaut, la méthode renvoie toujours `false` même lorsque le feature flag maître est **On**.
##### Arguments
| Nom | Type | Description |
| ----------------------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| visitorCode | string | L'identifiant unique de l'utilisateur. Ce champ est obligatoire. |
| featureKey | string | La clé du feature que vous souhaitez exposer à un utilisateur. Ce champ est obligatoire. |
| isUniqueIdentifier (Déprécié) | bool | Un paramètre pour spécifier si le visitorCode est un identifiant unique. S'il n'est pas fourni, la valeur par défaut est `false`. Ce champ est facultatif. |
| track | bool | Un paramètre de la méthode `IsFeatureActiveWithTracking` pour activer ou désactiver le tracking de l'évaluation du feature. `IsFeatureActive(visitorCode, featureKey)` équivaut à `IsFeatureActiveWithTracking(visitorCode, featureKey, true)`. |
##### Valeur de retour
| Type | Description |
| ---- | ------------------------------------------------------------------------- |
| bool | Valeur du feature flag qui est enregistrée pour un **visitorCode** donné. |
##### Exceptions levées
| Type | Description |
| -------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| errs.FeatureConfigNotFound | Cette erreur indique que la clé de feature demandée n'a pas pu être trouvée dans la configuration interne du SDK. Cela se produit généralement lorsque le feature flag n'a pas encore été récupéré par le SDK, ce qui peut arriver si le SDK est en mode [polling](/fr/developer-docs/feature-experimentation/technical-reference/technical-considerations#polling-par-defaut). |
| errs.VisitorCodeInvalid | Cette erreur est renvoyée lorsque le visitor code fourni est invalide, c'est-a-dire qu'il est vide ou que sa longueur dépasse 255 caractères. |
#### GetVariation()
* 📨 *Envoie des données de tracking à Kameleoon (selon le paramètre `GetVariationOptParams.Track`)*
Récupère la [`Variation`](#variation) attribuée à un visiteur donné pour un feature flag spécifique.
Cette méthode prend un `visitorCode` et un `featureKey` comme arguments obligatoires. L'argument `GetVariationOptParams.Track` est facultatif et vaut `true` par défaut.
Elle renvoie la `Variation` attribuée au visiteur. Si le visiteur n'est associé à aucune règle de feature flag, la méthode renvoie la `Variation` par défaut pour le feature flag donné.
Assurez-vous qu'une gestion appropriée des erreurs est implémentée dans votre code pour gérer les exceptions potentielles.
La variation par défaut fait référence à la variation attribuée à un visiteur lorsqu'il ne correspond à aucune règle de delivery prédéfinie pour un feature flag. En d'autres termes, c'est la variation de repli appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée comme la variation dans la section "Then, for everyone else..." d'une interface de gestion.
```go theme={null}
const featureKey = "new_checkout"
variation, err := client.GetVariation(visitorCode, featureKey)
// disabling tracking
variation, err := client.GetVariation(visitorCode, featureKey, NewGetVariationOptParams().Track(false))
if err != nil {
// handle error
}
// Fetch a variable value for the assigned variation
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
}
```
##### Arguments
| Nom | Type | Description | Défaut |
| ----------------------------------------- | -------- | ------------------------------------------------------------------------------------------ | ------ |
| visitorCode (*obligatoire*) | `string` | Identifiant unique du visiteur. | |
| featureKey (*obligatoire*) | `string` | Clé du feature que vous souhaitez exposer à un visiteur. | |
| GetVariationOptParams.Track (*optionnel*) | `bool` | Un paramètre facultatif pour activer ou désactiver le tracking de l'évaluation du feature. | `true` |
##### Valeur de retour
| Type | Description |
| ----------- | ------------------------------------------------------------------------------------------------------------------------------- |
| `Variation` | Une [`Variation`](#variation) attribuée à un visiteur donné pour un feature flag spécifique en cas de succès, sinon une erreur. |
##### Exceptions levées
| Type | Description |
| --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `errs.VisitorCodeInvalid` | Exception indiquant que le visitor code fourni n'est pas valide. Il est vide ou de longueur supérieure à 255 caractères. |
| `errs.FeatureNotFound` | Exception indiquant que la clé de feature demandée n'a pas été trouvée dans la configuration interne du SDK. Cela signifie généralement que le feature flag n'est pas activé dans l'application Kameleoon (mais que le code implémentant la fonctionnalité est déjà déployé dans l'application). |
| `errs.FeatureEnvironmentDisabled` | Exception indiquant que le feature flag est désactivé pour l'environnement actuel du visiteur (par exemple, production, staging ou development). |
#### GetVariations()
* 📨 *Envoie des données de tracking à Kameleoon (selon le paramètre `GetVariationsOptParams.Track`)*
Récupère une map d'objets [`Variation`](#variation) attribués à un visiteur donné pour tous les feature flags.
Cette méthode itère sur tous les feature flags disponibles et renvoie la `Variation` attribuée pour chaque flag associé au visiteur spécifié. Elle prend `visitorCode` comme argument obligatoire, tandis que `GetVariationsOptParams.OnlyActive` et `GetVariationsOptParams.Track` sont facultatifs.
* Si `GetVariationsOptParams.OnlyActive` est défini sur `true`, la méthode `GetVariations()` renverra les variations des feature flags à condition que l'utilisateur ne soit pas bucketé avec la variation `off`.
* Le paramètre `GetVariationsOptParams.Track` contrôle si la méthode suivra ou non les attributions de variations. Par défaut, il est défini sur `true`. S'il est défini sur `false`, le tracking sera désactivé.
La map renvoyée contient les clés des feature flags comme clés et leurs `Variation` correspondantes comme valeurs. Si aucune variation n'est attribuée pour un feature flag, la méthode renvoie la `Variation` par défaut pour ce flag.
Une gestion appropriée des erreurs doit être implémentée pour gérer les exceptions potentielles.
La variation par défaut fait référence à la variation attribuée à un visiteur lorsqu'il ne correspond à aucune règle de delivery prédéfinie pour un feature flag. En d'autres termes, c'est la variation de repli appliquée à tous les utilisateurs qui ne sont pas ciblés par des règles spécifiques. Elle est représentée comme la variation dans la section "Then, for everyone else..." d'une interface de gestion.
```go theme={null}
variations, err := client.GetVariations(visitorCode)
// all active variations
variations, err := client.GetVariations(visitorCode, NewGetVariationsOptParams().OnlyActive(true))
// disable tracking
variations, err := client.GetVariations(visitorCode, NewGetVariationsOptParams().Track(false))
if err != nil {
// handle error
}
```
##### Arguments
| Nom | Type | Description | Défaut |
| ----------------------------------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| visitorCode (*obligatoire*) | `string` | Identifiant unique du visiteur. | |
| GetVariationsOptParams.OnlyActive (*optionnel*) | `bool` | Un paramètre facultatif indiquant s'il faut renvoyer les variations pour les feature flags actifs (`true`) ou tous les feature flags (`false`). | `false` |
| GetVariationsOptParams.Track (*optionnel*) | `bool` | Un paramètre facultatif pour activer ou désactiver le tracking de l'évaluation du feature. | `true` |
##### Valeur de retour
| Type | Description |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| `map[string]Variation` | Map qui contient les objets [`Variation`](#variation) attribués des feature flags en utilisant les clés des features correspondantes en cas de succès, sinon une erreur. |
##### Exceptions levées
| Type | Description |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `errs.VisitorCodeInvalid` | Exception indiquant que le visitor code fourni n'est pas valide. Il est vide ou de longueur supérieure à 255 caractères. |
##### Arguments
| Nom | Type | Description |
| ----------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| visitorCode | string | Identifiant unique de l'utilisateur. Ce champ est obligatoire. |
| OnlyActive | bool | Un paramètre facultatif indiquant s'il faut renvoyer les variations pour les feature flags actifs (`true`) ou tous les feature flags (`false`) (Par défaut : `false`). |
| Track | bool | Un paramètre facultatif pour activer ou désactiver le tracking de l'évaluation du feature (Par défaut : `true`). |
##### Valeur de retour
| Type | Description |
| ---------------------- | -------------------------------------------------------------------------------------------------------------------------------- |
| `map[string]Variation` | Map qui contient les [`Variations`](#variation) attribuées des feature flags en utilisant les clés des features correspondantes. |
##### Exceptions levées
| Type | Description |
| ------------------ | ------------------------------------------------------------------------------------------------------------------------ |
| VisitorCodeInvalid | Exception indiquant que le visitor code fourni n'est pas valide. Il est vide ou de longueur supérieure à 255 caractères. |
#### SetForcedVariation()
La méthode vous permet d'attribuer programmatiquement une [`Variation`](#variation) spécifique à un utilisateur, en contournant le processus d'évaluation standard. Cela est particulièrement utile pour les expériences contrôlées où la logique d'évaluation habituelle n'est pas nécessaire ou doit être ignorée. Cela peut également être utile dans des scénarios tels que le débogage ou les tests personnalisés.
Lorsqu'une variation **forcée** est définie, elle remplace la logique d'évaluation en temps réel de Kameleoon. Des processus tels que la segmentation, les conditions de ciblage et les calculs algorithmiques sont ignorés. Pour préserver la segmentation et les conditions de ciblage pendant une expérience, définissez `SetForcedVariationOptParams.ForceTargeting=false` à la place.
Les variations **simulées** sont toujours prioritaires dans l'ordre d'exécution. Si un calcul de variation **simulée** est déclenché, il sera entièrement traité et complété en premier.
Une variation forcée est traitée de la même manière qu'une variation évaluée. Elle est suivie dans les analyses et stockée dans le contexte utilisateur comme toute variation évaluée standard, assurant la cohérence dans la production de rapports.
La méthode peut lever des exceptions dans certaines conditions (par exemple, paramètres invalides, contexte utilisateur ou problèmes internes). Une gestion appropriée des exceptions est essentielle pour garantir que votre application reste stable et résiliente.
Il est important de distinguer les variations **forcées** des variations **[simulées](#getvisitorcode)** :
* **Variations forcées** : Sont spécifiques à une expérience individuelle.
* **Variations simulées** : Affectent le résultat global du **feature flag**.
```go theme={null}
const experimentId = 9516
// Forcing the variation "on" in the experiment 9516 for the visitor.
err := client.SetForcedVariation(visitorCode, experimentId, "on")
// Forcing the variation "on" while preserving segmentation and targeting conditions during the experiment.
err := client.SetForcedVariation(
visitorCode, experimentId, "on", NewSetForcedVariationOptParams().ForceTargeting(false),
)
// Resetting the forced variation in the experiment 9516 for the visitor.
err := client.SetForcedVariation(visitorCode, experimentId, "")
if err != nil {
// Handling the error
}
```
##### Arguments
| Nom | Type | Description | Défaut |
| -------------------------------------------------------- | -------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------ |
| visitorCode (*obligatoire*) | `string` | Identifiant unique du visiteur. | |
| experimentId (*obligatoire*) | `int` | **Experiment Id** qui sera ciblé et sélectionné pendant le processus d'évaluation. | |
| variationKey (*obligatoire*) | `string` | **Variation Key** correspondant à une `Variation` qui doit être forcée comme valeur de retour pour l'expérience. Si la valeur est `""`, la variation forcée sera réinitialisée. | |
| SetForcedVariationOptParams.ForceTargeting (*optionnel*) | `bool` | Indique si le ciblage pour l'expérience doit être forcé et ignoré (`true`) ou appliqué comme dans le processus d'évaluation standard (`false`). | `true` |
##### Exceptions levées
| Type | Description |
| -------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `errs.VisitorCodeInvalid` | Exception indiquant que le visitor code fourni n'est pas valide. Il est vide ou de longueur supérieure à 255 caractères. |
| `errs.FeatureExperimentNotFound` | Exception indiquant que l'experiment id demandé n'a pas été trouvé dans la configuration interne du SDK. C'est généralement normal et signifie que l'expérience correspondant à la règle n'a pas encore été activée du côté de Kameleoon. |
| `errs.FeatureVariationNotFound` | Exception indiquant que la variation key(id) demandée n'a pas été trouvée dans la configuration interne du SDK. C'est généralement normal et signifie que l'expérience correspondant à la variation n'a pas encore été activée du côté de Kameleoon. |
#### EvaluateAudiences()
* 📨 *Envoie des données de tracking à Kameleoon*
Cette méthode évalue les visiteurs par rapport à tous les segments disponibles de l'Audiences Explorer et suit ceux qui correspondent.
`EvaluateAudiences()` doit être appelée **après que toutes les données pertinentes du visiteur ont été définies ou mises à jour**, et **juste avant** d'obtenir une variation de feature ou de vérifier un feature flag. Cette approche garantit que le visiteur est évalué par rapport aux données les plus récentes disponibles, permettant une attribution précise des audiences en fonction de tous les critères.
Après avoir appelé cette méthode, vous pouvez effectuer une analyse détaillée des performances des segments dans l'Audiences Explorer.
```go theme={null}
if err := client.EvaluateAudiences(visitorCode); err != nil {
// Handling the error
}
```
##### Arguments
| Nom | Type | Description |
| --------------------------- | -------- | ------------------------------- |
| visitorCode (*obligatoire*) | `string` | Identifiant unique du visiteur. |
##### Exceptions levées
| Type | Description |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `errs.VisitorCodeInvalid` | Exception indiquant que le visitor code fourni n'est pas valide. Il est vide ou de longueur supérieure à 255 caractères. |
#### GetDataFile()
Pour évaluer tous les feature flags, utilisez [`GetVariations()`](#getvariations). Cette méthode est plus efficace que d'appeler `DataFile` et de parcourir les flags avec [`GetVariation()`](#getvariation).
Renvoie la configuration actuelle du SDK sous forme d'objet [`DataFile`](#datafile).
```go theme={null}
dataFile := client.GetDataFile()
```
##### Valeur de retour
| Type | Description |
| ---------- | ------------------------------------------------------------ |
| `DataFile` | Le [`DataFile`](#datafile) contenant la configuration du SDK |
### Données du visiteur
#### GetVisitorCode()
Cette méthode s'appelait auparavant `ObtainVisitorCode`, qui a été supprimée dans la version `3.0.0` du SDK.
Pour assurer la cohérence de l'identification de l'utilisateur, en particulier lorsque vous utilisez Kameleoon en [mode hybride](/developer-docs/feature-experimentation/get-started/hybrid-experimentation/), vous devez appeler la méthode [`GetVisitorCode()`](#getvisitorcode) pour obtenir le `visitorCode` Kameleoon du visiteur actuel. Voici comment cela fonctionne :
1. Kameleoon vérifie s'il y a un cookie **kameleoonVisitorCode** associé à la requête HTTP actuelle. S'il est trouvé, Kameleoon utilise ce code comme identifiant du visiteur.
2. Si aucun cookie n'est trouvé, la méthode générera aléatoirement un nouvel identifiant, ou utilisera l'argument **defaultVisitorCode** s'il est passé. L'utilisation de vos identifiants comme visitor codes vous permet de faire correspondre les visiteurs Kameleoon avec vos propres utilisateurs sans recherches supplémentaires.
3. Le cookie côté serveur **kameleoonVisitorCode** est ensuite défini avec la valeur de l'identifiant via l'en-tête HTTP et la méthode renvoie la valeur de l'identifiant.
Pour plus d'informations, veuillez consulter cet [article](/developer-docs/feature-experimentation/get-started/hybrid-experimentation).
Si vous décidez de fournir votre propre `User ID` au lieu d'utiliser le visitorCode généré par Kameleoon, il est de votre responsabilité de garantir que le User ID est unique. Le SDK ne vérifie pas l'unicité. Il est important de noter que le User ID que vous fournissez ne doit pas dépasser 255 caractères, car tout caractère excédentaire entraînera la levée d'une exception.
La méthode `GetVisitorCode()` vous permet de définir des variations **simulées** pour un visiteur. Lorsque les cookies (d'une **requête** ou d'un **document**) contiennent la clé `kameleoonSimulationFFData`, le processus d'évaluation standard est contourné. À la place, la méthode renvoie directement une [`Variation`](#variation) basée sur les données fournies.
Vous pouvez appliquer des simulations de deux manières :
* **Automatiquement (recommandé) :** Si vous utilisez Kameleoon Web Experimentation ou le SDK en [mode hybride](/developer-docs/feature-experimentation/get-started/hybrid-experimentation#linking-feature-experiments-with-front-end-tracking-code), le cookie est créé automatiquement lors de la simulation de l'affichage d'une variante à l'aide du [Simulation Panel](/user-manual/experimentation/feature-experimentation/using-the-rollout-planner/validation-and-rollback/using-simulation-mode).
* **Manuellement :** Définissez manuellement le cookie `kameleoonSimulationFFData`.
Il est important de distinguer les variations **simulées** des variations **[forcées](#setforcedvariation)** :
* **Variations simulées** : Affectent le résultat global du **feature flag**.
* **Variations forcées** : Sont spécifiques à une expérience individuelle.
⚙️ **Configuration manuelle**
Veuillez vous assurer que le cookie `kameleoonSimulationFFData` suit ce format :
* `kameleoonSimulationFFData={"featureKey":{"expId":10,"varId":20}}` : Simule la variation avec `varId` de l'expérience `expId` pour le `featureKey` donné.
* `kameleoonSimulationFFData={"featureKey":{"expId":0}}` : Simule la variation par défaut (définie dans la section **Then, for everyone else in Production, serve**) pour le `featureKey` donné.
⚠️ Pour garantir un bon fonctionnement, la valeur du cookie doit être encodée comme un composant URI en utilisant une méthode telle que [`encodeURIComponent`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/encodeURIComponent).
```go theme={null}
visitorCode, err := client.GetVisitorCode(req, resp)
visitorCode, err := client.GetVisitorCode(req, resp, "defaultVisitorCode")
```
##### Arguments
| Nom | Type | Description |
| ------------------ | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| request | \*fasthttp.Request | L'objet fasthttp.Request actuel doit être passé en tant que premier paramètre. Ce champ est obligatoire. |
| response | \*fasthttp.Response | L'objet fasthttp.Response actuel doit être passé en tant que deuxième paramètre. Ce champ est obligatoire. |
| defaultVisitorCode | string | Ce paramètre sera utilisé comme **visitorCode** si aucun cookie **kameleoonVisitorCode** existant n'est trouvé sur la requête. Ce champ est facultatif, et par défaut un **visitorCode** aléatoire sera généré. |
##### Valeur de retour
| Type | Description |
| --------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| (string, error) | Une paire composée d'un **visitorCode** qui sera associé à cet utilisateur particulier et d'une erreur. Il doit être utilisé avec la plupart des méthodes du SDK. |
##### Exceptions levées
| Message d'erreur | Description |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| errs.VisitorCodeInvalid | Cette erreur est renvoyée lorsque le visitor code fourni est invalide, c'est-a-dire qu'il est vide ou que sa longueur dépasse 255 caractères. |
#### AddData()
La méthode `AddData()` ajoute des [données de ciblage](#types-de-données) au stockage pour que d'autres méthodes puissent utiliser les données pour décider de cibler ou non le visiteur actuel.
La méthode `AddData()` ne renvoie aucune valeur et n'interagit pas avec les serveurs back-end de Kameleoon par elle-même. À la place, toutes les données déclarées sont enregistrées pour une transmission future à l'aide de la méthode [`Flush*()`](#flushall--flushvisitor--flushvisitorinstantly). Cette approche réduit le nombre d'appels serveur effectués, car les données sont généralement regroupées en un seul appel serveur déclenché par `Flush*()`.
La méthode [`TrackConversion()`](#trackconversion) envoie également toutes les données précédemment associées, tout comme `Flush*()`. Il en va de même pour les méthodes [`GetVariation()`](#getvariation) et [`GetVariations()`](#getvariations) si une règle d'expérimentation est déclenchée.
Chaque visiteur ne peut avoir qu'une seule instance de données associées pour la plupart des types de données. Cependant, [`CustomData`](#customdata) est une exception. Les visiteurs peuvent avoir une instance de `CustomData` associée par index.
```go theme={null}
import (
"github.com/Kameleoon/client-go/v3/types"
)
// Add a single data item (tracked by default)
client.AddData(visitorCode, types.NewBrowser(types.BrowserTypeChrome))
// Add multiple data items (tracked by default)
client.AddData(visitorCode,
types.NewPageViewWithTitle("https://url.com", "title", 3),
types.UserAgent("UserAgent"),
)
// Add multiple data items stored locally for targeting only (not sent to the Kameleoon Data API)
client.AddDataWithOptParams(
visitorCode,
NewAddDataOptParams().Track(false),
types.NewPageViewWithTitle("https://url.com", "title", 3),
types.UserAgent("UserAgent")
)
```
##### Arguments
| Nom | Type | Description | Valeur par défaut |
| --------------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------- |
| visitorCode (*obligatoire*) | `string` | Identifiant unique du visiteur. | |
| track (*optionnel*) | `bool` | Spécifie si les données ajoutées sont éligibles au tracking. Lorsque défini sur `false`, les données sont stockées localement et utilisées uniquement pour l'évaluation du ciblage ; elles ne sont pas envoyées à la Kameleoon Data API. | `true` |
| allData (*obligatoire*) | `...types.Data` | Collection des types de données Kameleoon. | |
##### Exceptions
| Type | Description |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `errs.VisitorCodeInvalid` | Exception indiquant que le visitor code fourni n'est pas valide. Il est vide ou de longueur supérieure à 255 caractères. |
#### FlushAll() / FlushVisitor() / FlushVisitorInstantly()
* 📨 *Envoie des données de tracking à Kameleoon*
Les méthodes `FlushAll()/FlushVisitor()/FlushVisitorInstantly()` collectent les données Kameleoon liées au visiteur. Elles envoient ensuite une requête de tracking, avec toutes les données ajoutées à l'aide de la méthode `AddData`, qui n'ont pas encore été envoyées en utilisant l'une de [ces méthodes](/developer-docs/feature-experimentation/technical-reference/faq-global#when-does-the-sdk-send-a-tracking-request-for-analytics). `Flush*()` est non bloquant car l'appel serveur est effectué de manière asynchrone.
`Flush*()` vous permet de contrôler quand les données associées à un `visitorCode` donné sont envoyées à nos serveurs. Par exemple, si vous appelez `AddData()` une douzaine de fois, il serait inefficace d'envoyer des données au serveur après chaque appel à `AddData()`, donc tout ce que vous avez à faire est d'appeler `Flush()` une fois à la fin.
La méthode `FlushVisitor()/FlushVisitorInstantly()` utilise `visitorCode` comme identifiant unique du visiteur, ce qui est utile pour l'[expérimentation cross-device](/developer-docs/cross-device-experimentation). Lorsque vous spécifiez un `visitorCode` et définissez le paramètre `isUniqueIdentifier` sur `true`, le SDK lie les données envoyées (flush) au visiteur associé à l'identifiant spécifié.
Le paramètre `isUniqueIdentifier` est déprécié. Veuillez utiliser [`UniqueIdentifier`](#uniqueidentifier) à la place.
L'`isUniqueIdentifier` peut être utile dans des situations particulières ; par exemple, si vous ne pouvez pas accéder au `visitorCode` anonyme attribué à un visiteur, mais que vous pouvez utiliser un ID interne lié à ce visiteur via la fusion de sessions.
```go theme={null}
import (
"github.com/Kameleoon/client-go/v3/types"
)
visitorCode, err := client.GetVisitorCode(req, resp)
client.AddData(visitorCode, types.NewBrowser(types.BrowserTypeChrome))
client.AddData(visitorCode, types.NewConversionWithRevenue(32, 10, false))
client.FlushVisitor(visitorCode) // Interval tracking (most performant tracking method)
client.FlushAll() // Interval tracking for all visitors' unsent data
client.FlushVisitorInstantly(visitorCode) // Instant tracking
client.FlushAll(true) // Instant tracking for all visitors' unsent data
// if you operate with a unique ID
client.AddData(types.NewUniqueIdentifier(true))
client.FlushVisitor(visitorCode)
```
##### Arguments
| Nom | Type | Description |
| ----------------------------- | ------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| visitorCode | string | L'identifiant unique de l'utilisateur. Ce champ est obligatoire pour `FlushVisitor()/FlushVisitorInstantly()`. |
| isUniqueIdentifier (Déprécié) | bool | Un paramètre de la méthode `FlushVisitor` pour spécifier si le visitorCode est un identifiant unique. S'il n'est pas fourni, la valeur par défaut est `false`. Ce champ est facultatif. |
##### Exceptions levées
| Type | Description |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| errs.VisitorCodeInvalid | Cette exception est levée lorsque le visitor code fourni est invalide, c'est-a-dire qu'il est vide ou que sa longueur dépasse 255 caractères. |
#### GetRemoteData()
La méthode `GetRemoteData()` récupère les données externes stockées sur le serveur distant de Kameleoon pour le **siteCode** spécifié (spécifié dans le constructeur `KameleoonClient`) selon une **clé** passée en argument. Cette clé est généralement le Visitor Code Kameleoon ou votre User ID.
Vous pouvez utiliser cette méthode pour récupérer les préférences de l'utilisateur, les données historiques ou toute autre donnée pertinente pour la logique de votre application. En stockant ces données sur nos serveurs hautement évolutifs à l'aide de notre Data API, vous pouvez gérer efficacement de grandes quantités de données et les récupérer pour tous vos visiteurs ou utilisateurs.
La valeur de retour de la méthode est un objet JSON qui peut être décodé à l'aide de la fonction `json.Unmarshal()`. Vous pouvez utiliser ces données pour créer des segments de ciblage avancés pour les feature flags et les expériences, ou pour filtrer les rapports d'expérience et de personnalisation en fonction de toute valeur stockée dans les données récupérées.
```go theme={null}
type Test1 struct {
Value string `json:"some field to insert or update"`
}
remoteData, err := s.client.GetRemoteData("USER_ID") // uses default timeout
var test1 Test1
err = json.Unmarshal(remoteData, &test1)
remoteData, err := s.client.GetRemoteData("USER_ID", 1000)
```
Notez que, puisqu'un appel serveur est requis, ce mécanisme est asynchrone.
Nous proposons des intégrations natives avec Mixpanel, Segment et GA4 pour récupérer des cohortes externes et les utiliser dans des feature experiments. La clé utilisée dans ces intégrations est soit notre Visitor code, soit votre User ID. Vous pouvez vous référer à l'exemple de code fourni ci-dessous pour récupérer et utiliser les cohortes Mixpanel :
```go theme={null}
//Retrieve and use Mixpanel Cohorts
type Cohort struct {
Id string `json:"mixpanel_cohort_id"`
Name string `json:"mixpanel_cohort_name"`
ProjectId string `json:"mixpanel_cohort_project_id"`
}
type MixPanelCohorts struct {
Cohorts []Cohort `json:"mixpanel_cohorts"`
}
remoteData, err := s.client.GetRemoteData("USER_ID")
var mixPanel MixPanelCohorts
if err = json.Unmarshal(remoteData, &mixPanel); err == nil {
cohorts := make([]string, len(mixPanel.Cohorts))
for _, cohort := range mixPanel.Cohorts {
cohorts = append(cohorts, cohort.Id)
}
client.AddData(visitorCode, types.NewCustomData(customDataIndex, cohorts...))
}
```
##### Arguments
| Nom | Type | Description |
| ------- | ------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| key | string | La clé à laquelle les données que vous essayez de récupérer sont associées. Ce champ est obligatoire. Cette clé est généralement le Visitor Code Kameleoon ou votre propre User ID. |
| timeout | int | Le paramètre timeout spécifie le temps maximal pendant lequel la méthode peut être bloquée en attente d'un résultat, en millisecondes. Ce champ est facultatif ; s'il n'est pas fourni, la méthode utilisera la valeur de délai d'attente par défaut fournie lors de l'[initialisation du SDK](#initialisation). |
##### Valeur de retour
| Type | Description |
| ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| \[]byte | Cela renvoie les informations associées à la récupération des données pour une **clé** spécifique. Le résultat doit être décodé à l'aide de la fonction `json.Unmarshal`(). |
##### Exceptions levées
| Type | Description |
| ----- | ----------------------------------------- |
| error | Erreur indiquant que la requête a expiré. |
#### GetRemoteVisitorData()
`GetRemoteVisitorData()` est une méthode asynchrone pour récupérer les données de visites Kameleoon pour le `VisitorCode` à partir de la Kameleoon Data API. La méthode ajoute les données au stockage pour que d'autres méthodes puissent les utiliser lors des décisions de ciblage.
Les données obtenues à l'aide de cette méthode jouent un rôle important lorsque vous souhaitez :
* utiliser des données collectées depuis d'autres appareils.
* accéder à l'historique d'un utilisateur, comme les pages précédemment visitées lors de visites passées.
* utiliser des données qui ne sont accessibles que côté client, comme les variables datalayer et les objectifs qui ne convertissent que sur le front-end.
Lisez [cet article](/developer-docs/feature-experimentation/targeting-and-segmentation/native-segmentation) pour mieux comprendre les cas d'utilisation possibles.
Par défaut, `GetRemoteVisitorData()` récupère automatiquement les dernières custom data stockées avec `Scope=Visitor` et les attache au visiteur sans avoir besoin d'appeler la méthode `AddData()`. C'est particulièrement utile pour [synchroniser les custom data entre plusieurs appareils](/developer-docs/sdks/web-sdks/nodejs-sdk#synchronizing-custom-data-across-devices).
Le paramètre `IsUniqueIdentifier` est déprécié. Veuillez utiliser [`UniqueIdentifier`](#uniqueidentifier) à la place.
L'`isUniqueIdentifier` peut être utile dans des situations particulières ; par exemple, si vous ne pouvez pas accéder au `visitorCode` anonyme attribué à un visiteur, mais que vous pouvez utiliser un ID interne lié à ce visiteur via la fusion de sessions.
```go theme={null}
visitorCode := "visitorCode"
var visitorData []types.Data
var err error
// Visitor data will be fetched and automatically added for `visitorCode`
visitorData, err = client.GetRemoteVisitorData(visitorCode, true) // default timeout will be used
visitorData, err = client.GetRemoteVisitorData(visitorCode, true, time.Second) // 1000 milliseconds timeout
// If you only want to fetch data and add it yourself manually, set `addData` to `false`.
visitorData, err = client.GetRemoteVisitorData(visitorCode, false) // default timeout will be used
visitorData, err = client.GetRemoteVisitorData(visitorCode, false, time.Second) // 1000 milliseconds timeout
// If you operate with a unique ID
client.AddData(types.NewUniqueIdentifier(true))
visitorData, err = client.GetRemoteVisitorData(visitorCode, true)
// If you want to fetch a custom list of data types
var visitorData = client.GetRemoteVisitorDataWithFilter(
visitorCode,
true,
types.RemoteVisitorDataFilter{PreviousVisitAmount: 10, CustomData: true, Conversion: true, Experiments: true},
// default timeout will be used
)
// or
var visitorData = client.GetRemoteVisitorDataWithFilter(
visitorCode,
true,
types.RemoteVisitorDataFilter{PreviousVisitAmount: 10, CustomData: true, Conversion: true, Experiments: true},
time.Second, // 1000 milliseconds timeout
)
```
##### Arguments de GetRemoteVisitorData
| Nom | Type | Description |
| ----------- | ------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| visitorCode | string | Le visitor code pour lequel vous souhaitez récupérer les données attribuées. Ce champ est obligatoire. |
| addData | bool | Un booléen indiquant si la méthode doit ajouter automatiquement les données récupérées pour un visiteur. Ce champ est obligatoire. |
| timeout | time.Duration | Le paramètre timeout spécifie le temps maximal pendant lequel la méthode peut être bloquée en attente d'un résultat, en millisecondes. Ce champ est facultatif ; s'il n'est pas fourni, la méthode utilisera la valeur de délai d'attente par défaut fournie lors de l'[initialisation du SDK](#initialisation). |
##### Arguments de GetRemoteVisitorDataWithFilter
| Nom | Type | Description |
| ----------- | ----------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| visitorCode | string | Le visitor code pour lequel vous souhaitez récupérer les données attribuées. Ce champ est obligatoire. |
| addData | bool | Un booléen indiquant si la méthode doit ajouter automatiquement les données récupérées pour un visiteur. Ce champ est obligatoire. |
| filter | types.RemoteVisitorDataFilter | Filtre permettant de spécifier les données à récupérer à partir des visites. Ce champ est obligatoire. |
| timeout | time.Duration | Le paramètre timeout spécifie le temps maximal pendant lequel la méthode peut être bloquée en attente d'un résultat, en millisecondes. Ce champ est facultatif ; s'il n'est pas fourni, la méthode utilisera la valeur de délai d'attente par défaut fournie lors de l'[initialisation du SDK](#initialisation). |
##### Arguments de GetRemoteVisitorDataWithOptParams
La méthode `GetRemoteVisitorDataWithOptParams` est dépréciée. Veuillez utiliser [`GetRemoteVisitorDataWithFilter`](/developer-docs/sdks/web-sdks/go-sdk#arguments-of-getremotevisitordatawithfilter) et [`UniqueIdentifier`](#uniqueidentifier) à la place.
| Nom | Type | Description |
| ----------- | ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------- |
| visitorCode | string | Le visitor code pour lequel vous souhaitez récupérer les données attribuées. Ce champ est obligatoire. |
| addData | bool | Un booléen indiquant si la méthode doit ajouter automatiquement les données récupérées pour un visiteur. Ce champ est obligatoire. |
| filter | types.RemoteVisitorDataFilter | Filtre permettant de spécifier les données à récupérer à partir des visites. Ce champ est obligatoire. |
| params | kameleoon.RemoteVisitorDataOptParams | Paramètres facultatifs. |
Voici la liste des champs de `kameleoon.RemoteVisitorDataOptParams` :
| Nom | Type | Description |
| ------------------------------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| IsUniqueIdentifier (*optionnel*) (Déprécié) | `bool` | Un paramètre pour spécifier si le visitorCode est un identifiant unique. S'il n'est pas fourni, la valeur par défaut est `false`. |
| Timeout (*optionnel*) | `time.Duration` | Le paramètre timeout spécifie le temps maximal pendant lequel la méthode peut être bloquée en attente d'un résultat, en millisecondes. Ce champ est facultatif ; s'il n'est pas fourni, la méthode utilisera la valeur de délai d'attente par défaut fournie lors de l'[initialisation du SDK](#initialisation). |
La valeur par défaut de `kameleoon.RemoteVisitorDataOptParams` qui est `types.RemoteVisitorDataFilter{PreviousVisitAmount: 1, CurrentVisit: true, CustomData: true}`, peut être obtenue avec la fonction `types.DefaultRemoteVisitorDataFilter()`.
##### Valeur de retour
| Type | Description |
| ------------- | -------------------------------------------------- |
| \[]types.Data | Une slice de données attribuées au visiteur donné. |
| error | Une erreur survenue. |
##### Utilisation des paramètres dans GetRemoteVisitorData()
La méthode `GetRemoteVisitorData()` offre une flexibilité en vous permettant de définir divers paramètres lors de la récupération des données sur les visiteurs. Que vous cibliez en fonction d'objectifs, d'expériences ou de variations, la même approche s'applique à tous les types de données.
Par exemple, supposons que vous souhaitiez récupérer des données sur les visiteurs qui ont atteint un objectif "Order transaction". Vous pouvez spécifier des paramètres dans la méthode `GetRemoteVisitorData()` pour affiner votre ciblage. Par exemple, si vous souhaitez cibler uniquement les utilisateurs qui ont converti sur l'objectif lors de leurs cinq dernières visites, vous pouvez définir le paramètre `PreviousVisitAmount` sur 5 et `Conversions` sur true.
La flexibilité illustrée dans cet exemple ne se limite pas aux données d'objectif. Vous pouvez utiliser des paramètres dans la méthode `GetRemoteVisitorData()` pour récupérer des données sur une variété de comportements de visiteurs.
Voici la liste des options `types.RemoteVisitorDataFilter` disponibles :
| Nom | Type | Description | Défaut |
| --------------------------------- | ------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| PreviousVisitAmount (*optionnel*) | `int` | Nombre de visites précédentes à partir desquelles récupérer les données. Nombre entre `1` et `25` | `1` |
| CurrentVisit (*optionnel*) | `bool` | Si true, les données de la visite actuelle seront récupérées | `true` |
| CustomData (*optionnel*) | `bool` | Si true, les custom data seront récupérées. | `true` |
| PageViews (*optionnel*) | `bool` | Si true, les données de page seront récupérées. | `false` |
| Geolocation (*optionnel*) | `bool` | Si true, les données de géolocalisation seront récupérées. | `false` |
| Device (*optionnel*) | `bool` | Si true, les données d'appareil seront récupérées. | `false` |
| Browser (*optionnel*) | `bool` | Si true, les données de navigateur seront récupérées. | `false` |
| OperatingSystem (*optionnel*) | `bool` | Si true, les données du système d'exploitation seront récupérées. | `false` |
| Conversions (*optionnel*) | `bool` | Si true, les données de conversion seront récupérées. | `false` |
| Experiments (*optionnel*) | `bool` | Si true, les données d'expérience seront récupérées. | `false` |
| Kcs (*optionnel*) | `bool` | Si true, le Kameleoon Conversion Score (KCS) sera récupéré. Nécessite le [module complémentaire AI Predictive Targeting](/user-manual/ai-predictive-targeting/target-users-based-on-likelihood-to-convert) | `false` |
| VisitorCode (*optionnel*) | `bool` | Si true, Kameleoon récupérera le `visitorCode` de la visite la plus récente et l'utilisera pour la visite actuelle. Cela est nécessaire si vous souhaitez vous assurer que le visiteur, identifié par son `visitorCode`, reçoit toujours la même variation entre les visites pour l'[expérimentation cross-device](/developer-docs/cross-device-experimentation). | `true` |
| Personalization (*optionnel*) | `bool` | Si true, les données de personnalisation seront récupérées. Cela est requis pour la condition de personnalisation. | `false` |
| cbs (*optionnel*) | `bool` | Si true, les données de score Contextual Bandit seront récupérées. | `false` |
#### GetVisitorWarehouseAudience()
Récupère toutes les données d'audience associées au visiteur dans votre data warehouse en utilisant les `VisitorCode` et `WarehouseKey` spécifiés. Le `WarehouseKey` est généralement votre ID utilisateur interne. Le paramètre `CustomDataIndex` correspond aux custom data Kameleoon que Kameleoon utilise pour cibler vos visiteurs. Vous pouvez consulter la [documentation sur le ciblage warehouse](/user-manual/integrations/data-warehouses/bigquery/use-bigquery-as-a-source-audience-targeting) pour plus de détails. La méthode renvoie un objet `CustomData`, confirmant que les données ont été ajoutées au visiteur et sont disponibles à des fins de ciblage.
```go theme={null}
customData, err = client.GetVisitorWarehouseAudience(VisitorWarehouseAudienceParams{
VisitorCode: "visitorCode",
CustomDataIndex: 10,
WarehouseKey: "warehouseKey", // optional
Timeout: 5 * time.Second, // optional
})
customData, err = c.GetVisitorWarehouseAudienceWithOptParams(
"visitorCode", 10, VisitorWarehouseAudienceOptParams{WarehouseKey: "warehouseKey", Timeout: 5 * time.Second})
```
##### Arguments de GetVisitorWarehouseAudience
| Nom | Type | Description |
| --------------- | ------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| VisitorCode | string | Une chaîne d'identification unique du visiteur, ne peut pas dépasser 255 caractères. |
| CustomDataIndex | int | Un entier représentant l'index des custom data que vous souhaitez utiliser pour cibler vos audiences BigQuery. |
| WarehouseKey | string | Une clé unique pour identifier les données du warehouse (généralement, votre ID utilisateur interne). Ce champ est facultatif. |
| Timeout | time.Duration | Le paramètre timeout spécifie le temps maximal pendant lequel la méthode peut être bloquée en attente d'un résultat, en millisecondes. Ce champ est facultatif ; s'il n'est pas fourni, la méthode utilisera la valeur de délai d'attente par défaut fournie lors de l'[initialisation du SDK](#initialisation). Ce champ est facultatif. |
##### Arguments de GetVisitorWarehouseAudienceWithOptParams
| Nom | Type | Description |
| --------------- | --------------------------------------------- | -------------------------------------------------------------------------------------------------------------- |
| visitorCode | string | Une chaîne d'identification unique du visiteur, ne peut pas dépasser 255 caractères. |
| customDataIndex | int | Un entier représentant l'index des custom data que vous souhaitez utiliser pour cibler vos audiences BigQuery. |
| params | `kameleoon.VisitorWarehouseAudienceOptParams` | Paramètres facultatifs. |
Voici la liste des champs de `kameleoon.VisitorWarehouseAudienceOptParams` :
| Nom | Type | Description |
| ------------ | --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| WarehouseKey | `string` | Une clé unique pour identifier les données du warehouse (généralement, votre ID utilisateur interne). Ce champ est facultatif. |
| Timeout | `time.Duration` | Le paramètre timeout spécifie le temps maximal pendant lequel la méthode peut être bloquée en attente d'un résultat, en millisecondes. Ce champ est facultatif ; s'il n'est pas fourni, la méthode utilisera la valeur de délai d'attente par défaut fournie lors de l'\[initialisation du SDK]. Ce champ est facultatif. |
Pour la méthode `GetVisitorWarehouseAudience`, les paramètres sont passés à la fonction en tant que `params` de la structure `VisitorWarehouseAudienceParams` pour rendre certains d'entre eux facultatifs (`WarehouseKey` et `Timeout`).
Pour la méthode `GetVisitorWarehouseAudienceWithOptParams`, seuls les paramètres facultatifs sont passés à la fonction en tant que `params` de la structure `VisitorWarehouseAudienceOptParams`.
##### Valeur de retour
| Type | Description |
| ------------------ | ---------------------------------------------------------------------------------- |
| \*types.CustomData | Une instance `CustomData` confirmant que les données ont été ajoutées au visiteur. |
| error | Une erreur survenue. |
#### SetLegalConsent()
Vous devez utiliser cette méthode pour spécifier si le visiteur a donné son consentement légal à l'utilisation de ses données personnelles. Définir le paramètre `legalConsent` sur `false` limite les types de données que vous pouvez inclure dans les requêtes de tracking. Cette méthode vous aide à respecter les exigences légales et réglementaires tout en gérant les données des visiteurs de manière responsable. Vous pouvez trouver plus d'informations sur les données personnelles dans la [politique de gestion du consentement](/user-manual/project-management/consent-management-policy).
```go theme={null}
visitorCode, err := kameleoonClient.GetVisitorCode(req, resp)
err := kameleoonClient.SetLegalConsent(visitorCode, true, resp)
```
##### Arguments
| Nom | Type | Description |
| ----------- | ------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| visitorCode | string | L'identifiant unique de l'utilisateur. Ce champ est obligatoire. |
| consent | bool | Une valeur booléenne représentant le statut du consentement légal. `true` indique que le visiteur a donné son consentement légal, `false` indique que le visiteur n'a jamais fourni, ou a retiré, son consentement légal. Ce champ est obligatoire. |
| response | \*fasthttp.Response | La réponse HTTP où les valeurs dans les cookies seront ajustées en fonction du statut de consentement légal. Ce champ est facultatif. |
##### Exceptions levées
| Type | Description |
| ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------- |
| errs.VisitorCodeInvalid | Cette erreur est renvoyée lorsque le visitor code fourni est invalide, c'est-a-dire qu'il est vide ou que sa longueur dépasse 255 caractères. |
##### Comportement de révocation du consentement
Lorsque vous appelez `SetLegalConsent()` avec `consent=false`, le SDK ne supprime pas le cookie `kameleoonVisitorCode`. À la place, il cesse de prolonger la date d'expiration du cookie, permettant au cookie de persister jusqu'à son expiration naturelle.
Si vos exigences de conformité requièrent la suppression immédiate du fichier de cookie lors de l'opt-out, vous devez le supprimer manuellement en utilisant les méthodes natives de gestion des cookies de votre framework. Le SDK ne supprimera pas le fichier automatiquement.
### Objectifs et analyses tierces
#### TrackConversion()
* 📨 *Envoie des données de tracking à Kameleoon*
Utilisez cette méthode pour suivre une conversion pour un [objectif](/user-manual//assets/goals/create-a-goal) et un utilisateur spécifiques. Cette méthode nécessite `visitorCode` et `goalId`. De plus, cette méthode accepte également les arguments facultatifs `TrackConversionOptParams.Revenue`, `TrackConversionOptParams.Negative` et `TrackConversionOptParams.Metadata`. Le `visitorCode` est généralement identique à celui qui a été utilisé lors du déclenchement de l'expérience.
La méthode `TrackConversion()` ne renvoie aucune valeur. Cette méthode est non bloquante car l'appel serveur est effectué de manière asynchrone.
Le paramètre `isUniqueIdentifier` est déprécié. Veuillez utiliser [`UniqueIdentifier`](#uniqueidentifier) à la place.
L'`isUniqueIdentifier` peut également être utile dans d'autres scénarios particuliers, par exemple lorsque vous ne pouvez pas accéder au `visitorCode` anonyme initialement attribué au visiteur, mais que vous avez accès à un ID interne connecté au visiteur anonyme via les capacités de fusion de sessions.
```go theme={null}
import (
"github.com/Kameleoon/client-go/v3/types"
)
const goalID = 83023
client.TrackConversion(visitorCode, goalID)
client.TrackConversionRevenue(visitorCode, goalID, 10.0)
// Add metadata
client.TrackConversionWithOptParams(visitorCode, goalID, TrackConversionOptParams{
Metadata: []*types.CustomData{
types.NewCustomData(3, "metadata1", "md2"),
types.NewCustomData(5, "md3")
},
})
```
##### Arguments
| Nom | Type | Description | Défaut |
| ----------------------------------------------- | --------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------- |
| visitorCode (*obligatoire*) | `string` | Identifiant unique du visiteur. | |
| goalId (*obligatoire*) | `int` | ID de l'objectif. | |
| TrackConversionOptParams.Revenue (*optionnel*) | `float64` | Revenu de la conversion. | `0` |
| TrackConversionOptParams.Negative (*optionnel*) | `bool` | Définit si le revenu est positif ou négatif. | `false` |
| TrackConversionOptParams.Metadata (*optionnel*) | `[]*CustomData` | Vous permet de définir des valeurs spécifiques pour les custom data qui ont été définies comme métadonnées pour l'objectif dans l'application Kameleoon. Exemple : `[CustomData{id: 5, value: "Payment Type"}, CustomData{id: 6, value: "Delivery Method"}]`. Dans cet exemple, `5` et `9` sont les index des custom data (5 = "Payment Type", 9 = "Delivery Method"). | `nil` |
| isUniqueIdentifier *(déprécié)* | `bool` | Un paramètre facultatif pour spécifier si le visitorCode est un identifiant unique. | `false` |
Les valeurs TrackConversionOptParams.Metadata sont accessibles via les [exports de données brutes](/user-manual/experiment-analytics/analyze-results/results-page/results-page-actions#Export) et [la page de résultats](/user-manual/experiment-analytics/analyze-results/data-and-metrics/goal-metadata).
Si le paramètre `TrackConversionOptParams.Metadata` est fourni, Kameleoon utilisera ces valeurs spécifiées pour la conversion actuelle au lieu de ce qui a été précédemment collecté à l'aide de la méthode [`AddData()`](#adddata). Si le paramètre est omis, Kameleoon utilisera les dernières valeurs suivies pour ces [`CustomData`](#customdata) avant la conversion et au sein de la même visite.
Kameleoon ne prendra en compte que les valeurs de métadonnées qui sont explicitement passées en paramètres à la méthode `TrackConversion()`.
Dans l'exemple ci-dessous, Kameleoon associera la conversion uniquement à la valeur de custom data explicitement fournie en paramètre (ici : index 5 avec la valeur 'Amex Credit Card').
```go theme={null}
kameleoonClient.AddData(visitorCode, types.NewCustomData(5, "Credit Card"), types.NewCustomData(9, "Express Delivery"));
kameleoonClient.TrackConversionWithOptParams(visitorCode, 10, TrackConversionOptParams{
Metadata: []*types.CustomData{
types.NewCustomData(9, "Amex Credit Card"),
},
})
```
##### Exceptions
| Type | Description |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `errs.VisitorCodeInvalid` | Exception indiquant que le visitor code fourni n'est pas valide. Il est vide ou de longueur supérieure à 255 caractères. |
#### GetEngineTrackingCode()
Kameleoon s'intègre avec plusieurs solutions d'analyse, notamment Mixpanel, Google Analytics 4 et Segment. Pour suivre correctement les expériences côté serveur, appelez la méthode `GetEngineTrackingCode()` après que le visiteur a déclenché une expérience. Le SDK renvoie des commandes de file d'attente JavaScript pour les expériences que le visiteur a déclenchées au cours des cinq dernières secondes. Lorsque vous insérez ce code dans la page, Engine.js traite les commandes et envoie les événements d'exposition via l'intégration d'analyse active.
Consultez l'[expérimentation hybride](/developer-docs/feature-experimentation/get-started/hybrid-experimentation) pour plus d'informations sur l'implémentation de cette méthode.
```go theme={null}
engineTrackingCode := kameleoonClient.GetEngineTrackingCode(visitorCode)
```
* Pour utiliser cette fonctionnalité, implémentez à la fois le SDK Go et [Engine.js](/developer-docs/web-experimentation/implementation-and-deployment/standard-implementation) de Kameleoon. Comme Engine.js n'est utilisé que pour le tracking dans ce flux, vous pouvez installer la balise asynchrone avant la balise de fermeture ``.
* Si vous souhaitez uniquement suivre les expériences dans Kameleoon et que vous n'avez pas besoin d'envoyer des événements d'exposition à des outils d'analyse tiers, utilisez le [SDK JavaScript / TypeScript](/developer-docs/sdks/web-sdks/js-sdk). Cette option fonctionne bien pour les [plateformes serverless edge compute](/developer-docs/feature-experimentation/implementation-and-deployment/serverless-edge-compute-starter-kits). Le SDK JavaScript / TypeScript suit automatiquement les variations lorsque vous appelez [`getVisitorCode`](/developer-docs/sdks/web-sdks/js-sdk#getvisitorcode), à condition que vous ajoutiez les attributions d'expérience correspondantes à `window.kameleoonQueue`.
* Vous pouvez insérer le code de tracking renvoyé directement dans une balise HTML `