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'EvaluateFeatureopération CloudWatch Evidently pour attribuer des variations aux sessions utilisateur, et vous utilisez l'PutProjectEventsopé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 plus d’informations, consultez 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.entityIdlorsque vous appelez les deuxEvaluateFeatureetPutProjectEvents. N'oubliez pas d'appeler PutProjectEvents après l'EvaluateFeatureappel, sinon les données seront supprimées et ne seront pas utilisées par CloudWatch Evidently.

LePutProjectEventsne 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 appelezEvaluateFeatureavec leentityIdRé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 appelezPutProjectEventsune 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 dePutProjectEventssont 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 choseentityIdest utilisé pour un nouveauEvaluateFeatureappel pendant la fenêtre d'une heure de cet appel initial, le plus tardEvaluateFeatureest 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.