Reducing Web Experimentation MAU Using the REST API

Overview

Optimizely Web Experimentation counts an MAU based upon the script snippet rendering for evauluation of web experiement. Therefore when you globally install a snippet in a website you can be counting MAUs with pages that don't need to be counted. There could also be some page types that don't need web ex as there will never be an experiement on it. See https://support.optimizely.com/hc/en-us/articles/4410284235789-Monitor-monthly-active-users-MAUs for imformation around this consumption.

It's suggested in the article to not render the script or opt out using the following script

<script>
  window["optimizely"] = window["optimizely"] || [];
  window["optimizely"].push({
   "type": "optOut",
   "isOptOut": true
  });
</script>
<script src=”https://cdn.optimizely.com/js/{project_id].js”></script>

However how do we know!

I'm Scott Reed, a solution architect at Niteco https://niteco.com/. In this blog post, I'll set out a POC I've created to test resolving this decision. 

Solution

The REST API for web experimentation can return active experiments for a specific project using a user bearer token https://docs.developers.optimizely.com/web-experimentation/reference/list_experiments 

Therefore it's possible for us to plug in logic to know if a domain/subpage has an active experiment.

As a proof of concept (I have not used in a real project yet) I have created https://github.com/scottreed/Optimizely-Web-Experimentation-Evaluator/ 

This project is a POC around evaulating Optimizely Web Experimentation via the REST API using the bearer token for a web experimentaion user.

Web experimentation Counts its monthly active users based upon a script being just rendered into the page to evaluate if an experiment needs to be run. This means that whenever you render a web experimentation snippet, even if there is no need to run it, it will evaluate and for an unique user count as an MAU.

This can increase costs as you're counting users that don't need to run this is especially important with multi-site where you might not be running experiments on specific sections of pages or subsites.

This is a standard project with the following

• .NET 8.0
• ASP.NET Core 8.0
• Optimizely SDK
• Minimal API
• In Memory Cache

The project has the following features

• Return a list of experiments from the web experimentation REST API based upon the past in status flags.
• Filtering the list of experiments based upon multiple path criteria (e.g., a sub-path or the route of the website).
• A Boolean in the ExperimentFilterService service to allow returning experiments if they have no URL matching criteria.
• In-memory caching of experiments so they don't need to be constantly re-evaluated with a 15-minute window.
• A minimal API that matches the webhook JSON Post format. This webhook can be configured in the settings for a project and notifies you when a project has a change. This minimal API will clear the cache based upon the project ID.

Conclusion

Using this we can actively know from backend code if we need not render (or opt) the web experiementation script. This way we can specifically stop MAU counting and reduce cost to ONLY what's needed!

To note this is just the evaulator so if you need to override this and still render (for tracking / audience criteria or other features) you can adapt this.

As this is just a POC and a thought idea let me know if you have an concer