Module aws_sdk_evidently::types

Data structures used by operation inputs/outputs.

Modules

• builders
  Builders
• error
  Error types that Amazon CloudWatch Evidently can respond with.

Structs

• CloudWatchLogsDestination

  A structure containing the CloudWatch Logs log group where the project stores evaluation events.

• CloudWatchLogsDestinationConfig

  A structure containing the CloudWatch Logs log group where the project stores evaluation events.

• EvaluationRequest

  This structure assigns a feature variation to one user session.

• EvaluationResult

  This structure displays the results of one feature evaluation assignment to one user session.

• EvaluationRule

  A structure that contains the information about an evaluation rule for this feature, if it is used in a launch or experiment.

• Event

  A structure that contains the information about one evaluation event or custom event sent to Evidently. This is a JSON payload. If this event specifies a pre-defined event type, the payload must follow the defined event schema.

• Experiment

  A structure containing the configuration details of an experiment.

• ExperimentExecution

  This structure contains the date and time that the experiment started and ended.

• ExperimentReport

  A structure that contains results of an experiment.

• ExperimentResultsData

  A structure that contains experiment results for one metric that is monitored in the experiment.

• ExperimentSchedule

  This structure contains the time and date that Evidently completed the analysis of the experiment.

• Feature

  This structure contains information about one Evidently feature in your account.

• FeatureSummary

  This structure contains information about one Evidently feature in your account.

• Launch

  This structure contains the configuration details of one Evidently launch.

• LaunchExecution

  This structure contains information about the start and end times of the launch.

• LaunchGroup

  A structure that defines one launch group in a launch. A launch group is a variation of the feature that you are including in the launch.

• LaunchGroupConfig

  A structure that defines one launch group in a launch. A launch group is a variation of the feature that you are including in the launch.

• MetricDefinition

  This structure defines a metric that is being used to evaluate the variations during a launch or experiment.

• MetricDefinitionConfig

  This structure defines a metric that you want to use to evaluate the variations during a launch or experiment.

• MetricGoal

  A structure that tells Evidently whether higher or lower values are desired for a metric that is used in an experiment.

• MetricGoalConfig

  Use this structure to tell Evidently whether higher or lower values are desired for a metric that is used in an experiment.

• MetricMonitor

  A structure that defines a metric to be used to monitor performance of the variations during a launch.

• MetricMonitorConfig

  A structure that defines a metric to be used to monitor performance of the variations during a launch.

• OnlineAbConfig

  A structure that contains the configuration of which variation to use as the "control" version. The "control" version is used for comparison with other variations. This structure also specifies how much experiment traffic is allocated to each variation.

• OnlineAbDefinition

  A structure that contains the configuration of which variation to use as the "control" version. The "control" version is used for comparison with other variations. This structure also specifies how much experiment traffic is allocated to each variation.

• Project

  This structure defines a project, which is the logical object in Evidently that can contain features, launches, and experiments. Use projects to group similar features together.

• ProjectAppConfigResource

  This is a structure that defines the configuration of how your application integrates with AppConfig to run client-side evaluation.

• ProjectAppConfigResourceConfig

  Use this parameter to configure client-side evaluation for your project. Client-side evaluation allows your application to assign variations to user sessions locally instead of by calling the EvaluateFeature operation to assign the variations. This mitigates the latency and availability risks that come with an API call.

• ProjectDataDelivery

  A structure that contains information about where Evidently is to store evaluation events for longer term storage.

• ProjectDataDeliveryConfig

  A structure that contains information about where Evidently is to store evaluation events for longer term storage.

• ProjectSummary

  A structure that contains configuration information about an Evidently project.

• PutProjectEventsResultEntry

  A structure that contains Evidently's response to the sent events, including an event ID and error codes, if any.

• RefResource

  A structure that contains information about one experiment or launch that uses the specified segment.

• S3Destination

  If the project stores evaluation events in an Amazon S3 bucket, this structure stores the bucket name and bucket prefix.

• S3DestinationConfig

  If the project stores evaluation events in an Amazon S3 bucket, this structure stores the bucket name and bucket prefix.

• ScheduledSplit

  This structure defines the traffic allocation percentages among the feature variations during one step of a launch, and the start time of that step.

• ScheduledSplitConfig

  This structure defines the traffic allocation percentages among the feature variations during one step of a launch, and the start time of that step.

• ScheduledSplitsLaunchConfig

  An array of structures that define the traffic allocation percentages among the feature variations during each step of a launch. This also defines the start time of each step.

• ScheduledSplitsLaunchDefinition

  An array of structures that define the traffic allocation percentages among the feature variations during each step of a launch. This also defines the start time of each step.

• Segment

  This structure contains information about one audience segment. You can use segments in your experiments and launches to narrow the user sessions used for experiment or launch to only the user sessions that match one or more criteria.

• SegmentOverride

  This structure specifies a segment that you have already created, and defines the traffic split for that segment to be used in a launch.

• Treatment

  A structure that defines one treatment in an experiment. A treatment is a variation of the feature that you are including in the experiment.

• TreatmentConfig

  A structure that defines one treatment in an experiment. A treatment is a variation of the feature that you are including in the experiment.

• ValidationExceptionField

  A structure containing an error name and message.

• Variation

  This structure contains the name and variation value of one variation of a feature.

• VariationConfig

  This structure contains the name and variation value of one variation of a feature.

Enums

• ChangeDirectionEnum
  When writing a match expression against ChangeDirectionEnum, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• EventType
  When writing a match expression against EventType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• ExperimentBaseStat
  When writing a match expression against ExperimentBaseStat, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• ExperimentReportName
  When writing a match expression against ExperimentReportName, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• ExperimentResultRequestType
  When writing a match expression against ExperimentResultRequestType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• ExperimentResultResponseType
  When writing a match expression against ExperimentResultResponseType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• ExperimentStatus
  When writing a match expression against ExperimentStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• ExperimentStopDesiredState
  When writing a match expression against ExperimentStopDesiredState, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• ExperimentType
  When writing a match expression against ExperimentType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• FeatureEvaluationStrategy
  When writing a match expression against FeatureEvaluationStrategy, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• FeatureStatus
  When writing a match expression against FeatureStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• LaunchStatus
  When writing a match expression against LaunchStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• LaunchStopDesiredState
  When writing a match expression against LaunchStopDesiredState, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• LaunchType
  When writing a match expression against LaunchType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• ProjectStatus
  When writing a match expression against ProjectStatus, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• SegmentReferenceResourceType
  When writing a match expression against SegmentReferenceResourceType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• ValidationExceptionReason
  When writing a match expression against ValidationExceptionReason, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.
• VariableValue

  The value assigned to a feature variation. This structure must contain exactly one field. It can be boolValue, doubleValue, longValue, or stringValue.

• VariationValueType
  When writing a match expression against VariationValueType, it is important to ensure your code is forward-compatible. That is, if a match arm handles a case for a feature that is supported by the service but has not been represented as an enum variant in a current version of SDK, your code should continue to work when you upgrade SDK to a future version in which the enum does include a variant for that feature.