com.iheart.thomas.abtest.model
AbtestSpec
Related Doc:
package model
name of the test, it's more like a note/description. It is NOT an identifier.
feature name of the treatment. This is an identifier with which feature code can determine for each user which treatment they get.
author name. Can be used for ownership
scheduled start of the test
scheduled end of the test, optional, if not given the test will last indefinitely
group definitions. group sizes don't have to add up to 1, but they cannot go beyond 1. If the sum group size is less than 1, it means that there is a portion (1 - the sum group size) of users won't be the in tests at all, you could make this group your control group.
an array of string tags for eligibility control. Once set, only users having these tags (tags are passed in group assignment inquiry requests) are eligible for this test.
by default Thomas uses the "userId" field passed in the group assignment inquiry request as the unique identification for segmenting users. In some A/B test cases, e.g. some features in the user registration process, a user Id might not be given yet. In such cases, you can choose to use any user meta field as the unique identification for users.
this is more advanced eligibility control. You can set a field and regex pair to match user meta. Only users whose metadata field value matches the regex are eligible for the experiment.
by default Thomas will try to keep the user assignment consistent between different versions of experiments of a feature. Setting this field to true will redistribute users again among all groups.
his field is used for creating mutually exclusive tests. When Thomas segments users into different groups, it hashes the user Id to a number between 0 and 1. If an A/B test is set with a set of segment ranges, then only hashes within that range will be eligible for that test. Thus if two tests have non-overlapping segment ranges, they will be mutually exclusive, i.e. users who eligible for one will not be eligible for the other.
by default Thomas uses the "userId" field passed in the group assignment inquiry request as the unique identification for segmenting users.
by default Thomas uses the "userId" field passed in the group assignment inquiry request as the unique identification for segmenting users. In some A/B test cases, e.g. some features in the user registration process, a user Id might not be given yet. In such cases, you can choose to use any user meta field as the unique identification for users.
author name.
author name. Can be used for ownership
scheduled end of the test, optional, if not given the test will last indefinitely
feature name of the treatment.
feature name of the treatment. This is an identifier with which feature code can determine for each user which treatment they get.
group definitions.
group definitions. group sizes don't have to add up to 1, but they cannot go beyond 1. If the sum group size is less than 1, it means that there is a portion (1 - the sum group size) of users won't be the in tests at all, you could make this group your control group.
this is more advanced eligibility control.
this is more advanced eligibility control. You can set a field and regex pair to match user meta. Only users whose metadata field value matches the regex are eligible for the experiment.
name of the test, it's more like a note/description.
name of the test, it's more like a note/description. It is NOT an identifier.
an array of string tags for eligibility control.
an array of string tags for eligibility control. Once set, only users having these tags (tags are passed in group assignment inquiry requests) are eligible for this test.
by default Thomas will try to keep the user assignment consistent between different versions of experiments of a feature.
by default Thomas will try to keep the user assignment consistent between different versions of experiments of a feature. Setting this field to true will redistribute users again among all groups.
his field is used for creating mutually exclusive tests.
his field is used for creating mutually exclusive tests. When Thomas segments users into different groups, it hashes the user Id to a number between 0 and 1. If an A/B test is set with a set of segment ranges, then only hashes within that range will be eligible for that test. Thus if two tests have non-overlapping segment ranges, they will be mutually exclusive, i.e. users who eligible for one will not be eligible for the other.
scheduled start of the test
Data used to create an A/B tests
name of the test, it's more like a note/description. It is NOT an identifier.
feature name of the treatment. This is an identifier with which feature code can determine for each user which treatment they get.
author name. Can be used for ownership
scheduled start of the test
scheduled end of the test, optional, if not given the test will last indefinitely
group definitions. group sizes don't have to add up to 1, but they cannot go beyond 1. If the sum group size is less than 1, it means that there is a portion (1 - the sum group size) of users won't be the in tests at all, you could make this group your control group.
an array of string tags for eligibility control. Once set, only users having these tags (tags are passed in group assignment inquiry requests) are eligible for this test.
by default Thomas uses the "userId" field passed in the group assignment inquiry request as the unique identification for segmenting users. In some A/B test cases, e.g. some features in the user registration process, a user Id might not be given yet. In such cases, you can choose to use any user meta field as the unique identification for users.
this is more advanced eligibility control. You can set a field and regex pair to match user meta. Only users whose metadata field value matches the regex are eligible for the experiment.
by default Thomas will try to keep the user assignment consistent between different versions of experiments of a feature. Setting this field to true will redistribute users again among all groups.
his field is used for creating mutually exclusive tests. When Thomas segments users into different groups, it hashes the user Id to a number between 0 and 1. If an A/B test is set with a set of segment ranges, then only hashes within that range will be eligible for that test. Thus if two tests have non-overlapping segment ranges, they will be mutually exclusive, i.e. users who eligible for one will not be eligible for the other.