Feature Experimentation API
Get started
Our Feature Experimentation API allows you to run experiments outside or additionally to the (client-side) web, anywhere you like.
These can be server-side experiments and even experiments run in local commerce, etc.
Furthermore, it is possible to combine classic client-side experimentation with API-based experimentation and thus perform hybrid experiments.
On this page
What is the Feature Experimentation API?
The Feature Experimentation API consists of two endpoints:
- one
/decideto determine the eperiment/feature and the specific variant (and, if applicable, certain values to it) for the user - and the other
/trackto measure the events/goals the user has performed
Simplified, it's like this: you tell the API what the user and the current view/"page" is (and, if applicable, properties) and use them in the platform for targeting. When a user performs actions that should be tracked, you send them to the API.
The /decide API endpoint tells you whether or not to display a specific feature in your application (server-side, mobile app, etc.). So you can be as flexible with this decision as you want and need.
When and why to choose this API?
Using the Feature Experimentation API offers some benefits, especially if you ...
- want to experiment with things that are not possible client-side (e.g. algorithms and sorting of search results, scoring, pricing and others).
- create variants directly in your technology stack and have full control over them
- store data other than in browser storage (as cookies or localStorage, sessionStorage)
- want to experiment in an environment that does not use web technology (e.g. native apps on iOs, Android etc.)
What needs to be given on your side?
In order to use the Feature Experimentation API, we kept the requirements as low as possible. Basically, the only requirements are that ...
- you have access to the code, which should behave differently depending on the variant or feature you want to show/enable
- your code can execute an API call (POST)