Global architecture
With the Remote Control API, you can create, update or delete your campaigns but also the variations of itself. A campaign is an aggregation of variation groups, which are themselves an aggregation of variations.
Using the Remote Control API, you can configure all the campaign configuration at once in a single request.
Predefined Types & Operators
- Campaign type can only be: ab, perso, deployment, flag, custom, toggle.
- Targeting operator can only be: EQUALS, NOT_EQUALS, STARTS_WITH, ENDS_WITH, CONTAINS, NOT_CONTAINS, GREATER_THAN, LOWER_THAN, EXISTS, NOT_EXISTS, GREATER_THAN_OR_EQUALS, LOWER_THAN_OR_EQUALS.
- Goal type can only be: event, transaction, pageview, screenview.
- Goal operator can only be: contains, ignoringParameters, exact, regexp.
If you wanna check in depth each field check Campaign API
The campaign architecture is the following :
{
"project_id": "<PROJECT_ID>",
"name": "<NAME>",
"description": "<DESCRIPTION>",
"type": "<TYPE>",
"variation_groups": [
{
"variations": [
{
"name": "<VARIATION_NAME>",
"allocation": "<ALLOCATION>",
"reference": "<REFERENCE>",
"modifications": {
"value": {
"<KEY>": "<VALUE>"
}
}
}
],
"targeting": {
"targeting_groups": [
{
"targetings": [
{
"operator": "<OPERATOR>",
"key": "<TARGETING_KEY>",
"value": "<TARGETING_VALUE>"
}
]
}
]
}
}
],
"scheduler": {
"start_date": "2023-01-01 10:00:00",
"stop_date": "2024-01-01 08:00:00",
"timezone": "Europe/Paris"
},
"primary_goal": {
"type": "<GOAL_TYPE>",
"label": "<GOAL_LABEL_Primary>"
},
"secondary_goals": [
{
"type": "<GOAL_TYPE>",
"label": "<GOAL_LABEL_SEC>",
}
]
}
Campaign architecture by use case type
AB Test use case
AB Test use case has the following architecture :
- 1 unique variation_group
- X variation you want in the unique variation group, including the original variation.
The targeting configuration is made on 1 variation group level and each visitor targeted will be allocated to one of its variations.
{
"project_id": "<PROJECT_ID>",
"name": "<NAME>",
"description": "<NAME>",
"type": "ab",
"variation_groups": [
{
"variations": [
{
"name": "Original",
"reference": true,
"allocation": 50,
"modifications": {
"type": "FLAG",
"value": {
"<FLAG_NAME>": "value1"
}
}
},
{
"name": "Variation 1",
"reference": false,
"allocation": 50,
"modifications": {
"type": "FLAG",
"value": {
"<FLAG_NAME>": "value2"
}
}
}
],
"targeting": {
"targeting_groups": [
{
"targetings": [
{
"key": "isVIP",
"operator": "EQUALS",
"value": "true"
}
]
}
]
}
}
]
}
Toggle use case
Toggle use case has the following architecture :
- X variation_group, one for each toggle case.
- 1 unique variation in each variation_group. The unique variation must have an allocation of 100.
The targeting configuration is made on each variation group and each visitor targeted will be allocated to the unique variation in 100% of the cases.
{
"project_id": "<PROJECT_ID>",
"name": "<NAME>",
"description": "<DESCRIPTION>",
"type": "toggle",
"variation_groups": [
{
"name": "New scenario",
"variations": [
{
"name": "Variation 1",
"allocation": 100,
"modifications": {
"type": "FLAG",
"value": {
"isEnabled": true
}
}
}
],
"targeting": {
"targeting_groups": [
{
"targetings": [
{
"key": "isVIP",
"operator": "EQUALS",
"value": "true"
}
]
}
]
}
}
]
}
Personnalisation use case
Personnalisation use case has the following architecture :
- X variation_group, one for each scene you want.
- 2 variation in each variation_group. The first variation must be a "Control variation", where you set no modification and an allocation you want. You can refer to the flagship platform to understand better how a personnalisation campaign works.
The targeting configuration is made on each variation group and each visitor targeted will be allocated to one of the variations.
{
"project_id": "<PROJECT_ID>",
"name": "<NAME>",
"description": "<DESCRIPTION>",
"type": "perso",
"variation_groups": [
{
"name": "Scene 1",
"variations": [
{
"name": "Variation Control",
"reference": true,
"allocation": 5
},
{
"name": "Variation 1",
"reference": false,
"allocation": 95,
"modifications": {
"type": "FLAG",
"value": {
"myColor": "blue"
}
}
}
],
"targeting": {
"targeting_groups": [
{
"targetings": [
{
"key": "isVIP",
"operator": "EQUALS",
"value": "true"
}
]
}
]
}
},
{
"name": "Scene 2",
"variations": [
{
"name": "Variation Control",
"reference": true,
"allocation": 5
},
{
"name": "Variation 1",
"reference": false,
"allocation": 95,
"modifications": {
"type": "FLAG",
"value": {
"myColor": "red"
}
}
}
],
"targeting": {
"targeting_groups": [
{
"targetings": [
{
"key": "isVIP",
"operator": "EQUALS",
"value": "false"
}
]
}
]
}
}
]
}
Progressive rollout use case
Progressive rollout use case has the following architecture :
- 1 unique variation_group
- 1 unique variation.
{
"project_id": "<PROJECT_ID>",
"name": "<NAME>",
"description": "<DESCRIPTION>",
"type": "deployment",
"variation_groups": [
{
"name": "New deployment",
"allocation_config": {
"start_date": "2023-01-01 10:00:00",
"start_allocation":20,
"timezone": "Europe/Paris",
"periodic_steps": {
"allocation": 20,
"step": 1,
"step_type": "day"
}
},
"variations": [
{
"name": "Variation 1",
"reference": false,
"allocation": 0,
"modifications": {
"type": "FLAG",
"value": {
"myColor": "blue"
}
}
}
],
"targeting": {
"targeting_groups": [
{
"targetings": [
{
"key": "isVIP",
"operator": "EQUALS",
"value": "true"
}
]
}
]
}
}
]
}
This payload will create a progressive rollout use case, with an allocation config of type periodic_steps. There is 2 different types of allocation config.
Allocation config : Periodic steps
In this type of config, you will define an increment value for your allocation, each X hour or day :
// allocation config with a step of 20% each day
{
"allocation_config": {
// ...,
"periodic_steps": {
"allocation": 20,
"step": 1,
"step_type": "day" // hour/day
},
// ...,
}
}
Allocation config : Custom steps
In this type of config, you will define each step manually. Each step allocation and step must be set relatively to the start allocation and start date.
// allocation config with 3 steps at day 1, 2 and 3 with an allocation of 40%, 60%, and 100%
{
"allocation_config": {
// ...,
"custom_steps": [
{
"allocation": 40,
"step": 1,
"step_type": "day"
},
{
"allocation": 60,
"step": 2,
"step_type": "day"
},
{
"allocation": 100,
"step": 3,
"step_type": "day"
}
],
// ...,
}
}
Allocation config : Rollback condition
You can set a rollback condition to automatically stop the use case when a goal is reached.
{
"allocation_config": {
// ...,
"rollback_condition": {
"goal": {
"type": "pageview",
"operator": "contains",
"value": "abtasty.com"
},
"operator" : "GREATER_THAN",
"value": 50,
"min_visitors": 1000
}
// ...,
}
}
If the goal is already created, you can set a goal id directly :
{
"allocation_config": {
// ...,
"rollback_condition": {
"goal": {
"id": "<GOAL_ID>"
},
"operator" : "GREATER_THAN",
"value": 50,
"min_visitors": 1000
}
// ...,
}
}
Adding options to a campaign
Setting a scheduler
To set a scheduler to a campaign, you can configure the scheduler attribute on the payload :
{
// ...,
"scheduler": {
"start_date": "2023-01-01 10:00:00",
"stop_date": "2024-01-01 08:00:00",
"timezone": "Europe/Paris"
},
// ...,
}
Setting goals to a campaign
You can set one main goal, and several secondary goals to a campaign. For more details about the goal architecture, please refer to the Goals section.
{
// ...,
"primary_goal": {
"type": "pageview",
"label": "<GOAL_LABEL>",
"operator": "contains",
"value": "<GOAL_VALUE>"
},
"secondary_goals": [
{
"type": "transaction",
"label": "<AFFILIATION>",
"metrics": ["uniqueConversions"]
}
],
// ...,
}
You can also link an existing goal to a campaign using its id :
{
// ...,
"primary_goal": {
"id": "<GOAL_ID>"
},
"secondary_goals": [
{
"id": "<GOAL_ID>"
}
],
// ...,
}