Scott Reed
Feb 13, 2026
  81
(5 votes)

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!

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.

Project Overview

This is a standard project with the following

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

Features

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.
To note on the above image, I set it to return archived projects as well because I needed to do some testing. However, when running this project, it would be better to adjust it to be just active and running projects. 

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

Feb 13, 2026

Comments

Andreas Ylivainio
Andreas Ylivainio Feb 13, 2026 10:57 AM

It’s always helpful to have a simple starter app that demonstrates how to use an API and makes it easy to try things out. Nice work!

Scott Reed
Scott Reed Feb 13, 2026 12:32 PM

Thanks Andreas, yeah this POC should help an issue my client is facing but thought it was an idea worth throwing out for people to play with. 

Mike Malloy
Mike Malloy Feb 13, 2026 03:41 PM

To summarize this approach. You are saying we could pass in the current page Url and determine if the Experiment script should be on the page. Is that correct?

That's really cool because I had to move the script to Google Tag Manager and create a bunch of triggers to only fire when a Url matched. Thanks for sharing.

FYI:
based upon the past in status flags = based upon the passed in status flags

Please login to comment.
Latest blogs
Install the new AI Assistant Chat for Optimizely

AI Assistant Chat is a revolutionary feature introduced in version 3.0 of Epicweb.Optimizely.AIAssistant that brings conversational AI directly int...

Luc Gosso (MVP) | Feb 12, 2026 |

Building a TwoColumnWideLeftSection in Optimizely CMS 13 Visual Builder

This post walks through a practical “66% / 33%” section built for Visual Builder using the composition tag helpers: , , , and . Visual Builder is...

Francisco Quintanilla | Feb 12, 2026 |

Advanced Form Submissions for Optimizely CMS 12

Managing form submissions in enterprise Optimizely CMS installations can quickly become inefficient. While the default Optimizely Forms submission...

Adnan Zameer | Feb 12, 2026 |