Fullstack experiments

With the browser snippet, ABlyft decides in the visitor's browser which variation to show. FullStack is for cases where the decision, or the change itself, must happen elsewhere: on your server, in your backend templates, or in your own app. Typical examples are search ranking, pricing or sorting logic.

For this, ABlyft publishes a config file with your running experiments, variations and targeting. Your application reads this file, applies your own variation code, and reports conversions back.

How it worksCopy Anchor Link

1. You enable FullStack for the project and for each experiment that should use it.
2. You create variations of type FullStack and give them properties (key-value pairs).
3. When you publish, ABlyft writes the config file to a public URL.
4. Your application loads the file, decides which variation a visitor gets, and applies the variation's properties.
5. Your application sends goals back to ABlyft, so results appear as for any other experiment.

Step 1: Enable FullStack for the projectCopy Anchor Link

Go to Settings → FullStack in your project. The menu entry appears only if your plan includes FullStack.

The right side of the page shows the Config File Implementation: the Config file URL (click to copy), the Project ID, File size, Project revision and Last published. If you have environments with Create a sub-snippet enabled, Sub Config Files lists one additional file per environment. Each contains only the experiments of that environment.

The URL has this form:

https://fullstack.ablyft.com/c/{secretPrefix}-{projectId}.json

For an environment file, -{environment API name} is appended before .json.

Step 2: Enable FullStack for an experimentCopy Anchor Link

1. Open the experiment and its settings (cog icon).
2. In the section General, switch on Enable FullStack for this experiment. The toggle is only visible if FullStack is enabled for the project. The experiment is added to the config file and the variation type FullStack becomes available.

Step 3: Create FullStack variationsCopy Anchor Link

1. In the experiment, create a variation and choose the type FullStack.
2. In the section FullStack, add Variation properties: key-value pairs that your application receives, for example color = blue or price_variant = premium.
3. Save.

The properties are delivered as data of the variation in the config file. A FullStack variation can also have JS and CSS code, see Custom JavaScript.

What the config file containsCopy Anchor Link

The file is regenerated every time the project is published. It contains all experiments of the project with the status running or preview, and for each experiment its variations, audiences, environments and pages.

{
  "project_id": 12345678,
  "project_name": "example.com",
  "debug_enabled": false,
  "published_at": "2026-01-15T10:30:00.000000Z",
  "stale_experiment_ids": [],
  "experiments": [
    {
      "id": 87654321,
      "status": "running",
      "api_name": "pricing-test",
      "name": "Pricing test",
      "traffic_allocation": 100,
      "audiences_match_type": "any",
      "metadata": [],
      "variations": [
        {
          "id": 11111111,
          "api_name": "original",
          "name": "Original",
          "baseline": true,
          "traffic_allocation": 50,
          "metadata": [],
          "data": {}
        },
        {
          "id": 22222222,
          "api_name": "premium",
          "name": "Premium price",
          "baseline": false,
          "traffic_allocation": 50,
          "metadata": [],
          "data": { "price_variant": "premium" }
        }
      ],
      "audiences": [],
      "environments": [],
      "pages": []
    }
  ],
  "exclusion_groups": [],
  "goals": [
    { "id": 33333333, "api_name": "purchase", "type": "revenue" }
  ]
}

The values are illustrative; the field names are the ones ABlyft writes. Notes:

• audiences contain the targeting definition of each audience, pages contain id and api_name.
• goals lists the goals used by the exported experiments, with id, api_name and type.
• exclusion_groups are exported with their entries (experiment_id, traffic).
• stale_experiment_ids lists archived experiments (archived within the last 6 months, with participants). It supports the cleanup of stored visitor assignments.

What your application doesCopy Anchor Link

ABlyft publishes the file, the logic around it lives in your application:

1. Load the config file (cache it for the duration of the cache expiration).
2. Decide for each visitor whether an experiment applies (pages, audiences, environments, traffic allocation) and assign a variation by the variation traffic allocation. Store the assignment per visitor, so that the visitor keeps seeing the same variation.
3. Apply the variation, using its data properties.
4. Report goals back to ABlyft.

For the last point and for the decision logic, contact ABlyft support to get the current integration options for your account. The documentation of the Feature Experimentation API describes two HTTPS endpoints for this: https://fe-api.ablyft.com/v1/decide (which variation does a user get?) and https://fe-api.ablyft.com/v1/track (send goals). Calls are authenticated with an API token (Authorization: Bearer [token]) and the visitor's current assignment is passed as user.bucketing. This API is offered on request, so confirm availability with ABlyft support before you build on it.

Mixing FullStack and browser experiments (hybrid)Copy Anchor Link

You can run browser experiments and server-side experiments for the same visitors. What matters is that the visitor has one consistent assignment. In the browser, ABlyft stores it in ablyft_exps in the configured storage (see Storage & privacy). On the API side, the same information is user.bucketing. If both match, tracking and the visitor experience stay correct. You can read the assignment in the browser with ablyft.get('bucketing'), see the get() reference.

Next stepsCopy Anchor Link