Running a Server-side Experiment with Pertento

A Server-side experiment is one whose variants your own code shows. Use it for changes that cannot be made by editing a page in the browser, such as pricing logic, search ranking, what an API returns or a recommendation model, and for pages that should render correctly the first time rather than change after they load.

Pertento still holds the experiment, decides who sees which variant, counts the visitors and reports the results on the same Statistics page as every other experiment. What you choose is who picks the variant. That is the experiment's Assignment setting.

The two assignments

Choose it on the experiment's settings tab, under Assignment, while the experiment is a draft.

• Browser. The Pertento snippet picks a variant in the browser by weight, exactly as it does for a Multi Variant experiment, and counts the visitor. Your page code shows the variant. Nothing is needed beyond the snippet. See Showing a browser-assigned variant from your own code.
• Server. Your backend asks Pertento for the variant through the server SDK or the HTTP API, renders the page for it, and passes the decision to the page, where the snippet counts the visitor. The first render is already right. See Setting up an experiment with Assignment: Server.

Which one to choose

Browser is the quicker start. It needs no server key and no backend code, and URL, device, cookie and activation targeting work as usual. It suits a change your front end can switch on once the snippet has run.

Server suits a change that has to be decided before the page exists, or one that must not change after the page has loaded. It needs the visitor ID turned on for the website, a server key, a flag key on the experiment, a key on every variant, and a few lines in your backend.

What is different with Assignment: Server

• Page targeting does not apply. URL, device, cookie and activation targeting are ignored, because your server decides who is in. Use attribute rules instead. See Attribute rules and bucketing on a customer ID.
• Some settings are fixed once it runs. The assignment, the flag key, the variant keys and what the experiment buckets on can only be changed while it is a draft, because changing them mid-run would move visitors between variants. Attribute rules can be changed at any time.
• Changes take up to about 45 seconds to arrive. Your servers refresh their copy of the setup every 30 seconds, so starting, stopping or editing an experiment is not instant on your side.
• Deploying works as usual. Once you deploy a winner, every decision names the deployed variant, so your code serves it to everyone without a release.

Conversions

Conversions still come from the browser by default, through pertentoReportConversion or your analytics integration. To report them only from your backend, set the website's tracking method to Server-side. See Reporting conversions from your server.

Experiments set up before the SDK

Server-side experiments used to be run by allocating visitors in your own code and posting each exposure to the public /visitors endpoint, which is still documented in Reporting experiment exposures via the Tracking API. Use one of the two assignments above for new experiments instead. Pertento then splits the traffic, counts each visitor once, and keeps the browser and your server agreeing on who the visitor is.