Module 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.

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

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.