Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Ajout de code à votre application
Pour utiliser CloudWatch Evidently, vous devez ajouter du code à votre application pour attribuer une variation à chaque session utilisateur et pour envoyer des métriques à Evidently. Vous utilisez l'EvaluateFeature
opération CloudWatch Evidently pour attribuer des variations aux sessions utilisateur, et vous utilisez l'PutProjectEvents
opération pour envoyer des événements à Evidently afin qu'ils soient utilisés pour calculer des métriques pour vos lancements ou vos expériences.
Lorsque vous créez des variations ou des métriques personnalisées, la console CloudWatch Evidently fournit des exemples du code que vous devez ajouter.
Pour un end-to-end exemple, voirDidacticiel : tests A/B avec l'exemple d'application Evidently.
En utilisant EvaluateFeature
Lorsque des variantes de fonctionnalités sont utilisées lors d'un lancement ou d'une expérience, l'application utilise l' EvaluateFeatureopération pour attribuer une variation à chaque session utilisateur. L'attribution d'une variation à un utilisateur est un événement d'évaluation. Lorsque vous appelez cette opération, vous transmettez ce qui suit :
Nom de fonction– Obligatoire. Evidently traite l'évaluation selon les règles d'évaluation des fonctions du lancement ou de l'expérience, et sélectionne une variation pour l'entité.
entityId— Obligatoire. Représente un utilisateur unique.
evaluationContext— Facultatif. JSONObjet représentant des informations supplémentaires sur un utilisateur. Evidently utilisera cette valeur pour faire correspondre l'utilisateur à un segment de votre audience lors des évaluations de fonctionnalités, si vous avez créé des segments. Pour de plus amples informations, veuillez consulter Utilisez des segments pour cibler votre audience.
Voici un exemple de valeur
evaluationContext
que vous pouvez envoyer à Evidently.{ "Browser": "Chrome", "Location": { "Country": "United States", "Zipcode": 98007 } }
Évaluations persistantes
CloudWatch Utilise évidemment des évaluations « persistantes ». Une configuration unique d'entityId
, de la fonctionnalité, de la configuration de fonctionnalité et d'evaluationContext
reçoit toujours la même attribution de variation. Le seul moment où l’affectation de variation change est lorsqu'une entité est ajoutée à une substitution ou que le trafic d'expérience est composé.
Une configuration de fonctionnalité comprend les éléments suivants :
-
Les variations de fonctionnalités
-
La configuration de variation (pourcentages attribués à chaque variation) pour une expérience en cours pour cette fonctionnalité, le cas échéant.
-
La configuration de variation pour un lancement en cours d'exécution de cette fonctionnalité, le cas échéant. La configuration de variation inclut les remplacements de segment définis, le cas échéant.
Si l'allocation de trafic d'une expérience est augmentée, tous les entityId
qui étaient précédemment affectés à un groupe de traitement d'expérience continueront à bénéficier du même traitement. Tout entityId
ayant été précédemment attribué au groupe de contrôle peut être affecté à un groupe de traitement d'expérience, selon la configuration de variation spécifiée pour l'expérience.
Si l'allocation de trafic d'une expérience est réduite, un entityId
peut passer d'un groupe de traitement à un groupe de contrôle, mais il ne sera pas transféré vers un autre groupe de traitement.
En utilisant PutProjectEvents
Pour coder une métrique personnalisée pour Evidently, vous utilisez l' PutProjectEventsopération. Voici un exemple de charge utile simple.
{ "events": [ { "timestamp": {{$timestamp}}, "type": "aws.evidently.custom", "data": "{\"details\": {\"pageLoadTime\": 800.0}, \"userDetails\": {\"userId\": \"test-user\"}}" } ] }
Le entityIdKey
peut simplement être un entityId
ou vous pouvez le renommer par autre chose quelconque, par exemple userId
. Dans l'éventualité même, entityId
peut être un nom d'utilisateur, un ID de séance, etc.
"metricDefinition":{ "name": "noFilter", "entityIdKey": "userDetails.userId", //should be consistent with jsonValue in events "data" fields "valueKey": "details.pageLoadTime" },
Pour vous assurer que les événements sont associés au lancement ou à l'expérience correcte, vous devez passer la même chose.entityId
lorsque vous appelez les deuxEvaluateFeature
etPutProjectEvents
. N'oubliez pas d'appeler PutProjectEvents
après l'EvaluateFeature
appel, sinon les données seront supprimées et ne seront pas utilisées par CloudWatch Evidently.
LePutProjectEvents
ne nécessite pas le nom de l'entité en tant que paramètre d'entrée. De cette façon, vous pouvez utiliser un seul événement dans différentes expériences. Par exemple, supposons que vous appelezEvaluateFeature
avec leentityId
Réglé suruserDetails.userId
. Si deux expériences ou plus sont en cours d'exécution, un seul événement de la session de cet utilisateur peut émettre des mesures pour chacune de ces expériences. Pour ce faire, vous appelezPutProjectEvents
une fois pour chaque expérience, en utilisant cette mêmeentityId
.
Timing
Après les appels de votre applicationEvaluateFeature
, il y a une période d'une heure où les événements métriques dePutProjectEvents
sont attribués sur la base de cette évaluation. Si d'autres événements surviennent après la période d'une heure, ils ne sont pas attribués.
Toutefois, si la même choseentityId
est utilisé pour un nouveauEvaluateFeature
appel pendant la fenêtre d'une heure de cet appel initial, le plus tardEvaluateFeature
est maintenant utilisé à la place, et le minuteur d'une heure est redémarré. Cela ne peut se produire que dans certaines circonstances, par exemple lorsque le trafic d'expérience est composé entre les deux affectations, comme expliqué dans la précédenteÉvaluations persistantesSection.
Pour un end-to-end exemple, voirDidacticiel : tests A/B avec l'exemple d'application Evidently.