Learn More: The Datafile

In Optimizely Full Stack, you configure experiments and variations in a web interface hosted on app.optimizely.com. Then, you implement an SDK in your application to bucket users into the right variations based on that configuration. The link between these two systems is called the datafile. Note that you will typically not need to access the datafile.

To access the datafile, locate the “settings” tab and select “datafile”.

The datafile is a JSON representation of your Optimizely SDK project. It contains all the instructions needed to run your experiments. The Datafile includes everything the SDKs need to know to execute experiments.

Whenever you make a change in Optimizely's interface like starting an experiment or changing its traffic allocation, Optimizely automatically builds a new revision of the datafile and serves it on cdn.optimizely.com. To incorporate this change, your application needs to download the new datafile and cache it locally to make decisions quickly. We call this process datafile synchronization.

There are several different approaches you can take to datafile synchronization, depending on your application’s needs. In general, these approaches trade off latency and freshness. Finding the right balance ensures that your datafile stays up to date without slowing down your application.

There is no one right answer for managing the datafile because every application has different implementation and performance constraints.

Let’s consider the following: Every time an experiment runs, you fetch the latest datafile from the CDN, then use it to initialize an Optimizely client and make a decision. This approach guarantees you the latest datafile, but it comes at a major performance cost. Every decision requires a round-trip network request. In asynchronous contexts like SMS or chatbots, this can work. But we don’t recommend it for synchronous use cases like a web server or API.

Instead, we recommend caching a local copy of the datafile within your application, then synchronizing it periodically. This lets you make experiment decisions immediately without waiting for a network request, while still keeping the configuration up to date.

For example, you can set up a timer to re-download the datafile every five minutes and store it in memory, then read from there every time you make a request. Or, you could use a webhook to keep a centralized service in sync and then make internal HTTP requests for the datafile. As these examples illustrate, there are several choices to consider when implementing datafile synchronization:

When considering where to store the datafile, consider locally in memory, on the filesystem, or on a separate service

When considering when to update the datafile, consider doing it via a “pull” model that polls for updates on a regular interval, or by listening for a “push” from a webhook

When considering how to fetch the datafile, consider fetching it directly from the CDN, or a private authenticated endpoint.