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.

The campaign architecture is the following :

{
    "project_id": "<PROJECT_ID>",
    "name": "<NAME>",
    "description": "<DESCRIPTION>",
    "type": "<TYPE>",
    "variation_groups": [
        {
            "variations": [
                {
                    "name": "<VARIATION_NAME>",
                    "allocation": 50,
                    "reference": true,
                    "modifications": {
                        "value": {
                            "color": "blue"
                        }
                    }
                },
                {
                    "name": "<VARIATION_NAME>",
                    "allocation": 50,
                    "reference": false,
                    "modifications": {
                        "value": {
                            "color": "red"
                        }
                    }
                }
            ],
            "targeting": {
                "targeting_groups": [
                    {
                        "targetings": [
                            {
                                "operator": "CONTAINS",
                                "key": "<TARGETING_KEY>",
                                "value": "<TARGETING_KEY_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>"
    },
    "secondary_goals": [
        {
            "type": "<GOAL_TYPE>",
            "label": "<GOAL_VALUE>",
        }
    ]
}

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

🚧

Due to a more complex architecture (allocation, steps...), this type of campaign is currently not well fully supported. You can however update basic campaign information on this type of campaign with the RCA.

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>"
        }
    ],
    // ...,
}