Experimentation News: July 2026

This fortnight the changes are about how you build and govern tests rather than the statistics behind them. Optimizely opened a code-first path, Statsig extended its review workflow from feature gates to whole experiments, and PostHog wired its flags into the vendor-neutral OpenFeature standard. Here is what shipped and whether it touches a small programme.

Optimizely adds a code-first editor and a browser companion

On 8 July Optimizely’s Web Experimentation release notes added a Code Editor, a code-first development path that lets you write custom JavaScript and CSS without loading the Visual Editor, with changes kept in sync between the two. The same drop shipped Optimizely Web Companion, a Chrome extension that opens the Visual Editor straight from the browser and is handy for sites that strip the URL parameters the editor normally relies on, plus a JavaScript library version setting that runs the snippet on ES6 or ES11. Selecting ES11 makes the snippet smaller and faster but drops support for legacy browsers. The code path suits teams who have outgrown pointing and clicking, and the ES11 option is a genuine page-speed lever, since a smaller snippet blocks less of the render, but check your browser mix before you flip it. If you are weighing Optimizely against the field, our best A/B testing tools guide covers where it lands. The detail is in Optimizely’s Web Experimentation release notes.

Statsig extends approvals from gates to full experiments

A fortnight after opening feature-gate reviews over its Console API, Statsig did the same for experiments. Its 7 July update exposes the full experiment review lifecycle through eight Console API endpoints and nine MCP tools, so you can propose, edit, approve, reject, cancel or list a change to an experiment without opening the console. The same day it added an Audit Overrides endpoint that returns every override across a project in a single call. These are governance features: the review flow lets you wire experiment sign-off into a CI pipeline and keep an audit trail of who approved what, and the overrides audit is the quiet win, because a forgotten forced assignment is a common way a result gets biased. That is exactly the kind of slip a disciplined hypothesis and QA process is meant to catch. Both changes are logged in Statsig’s product updates.

PostHog ships an OpenFeature web provider

On 6 July PostHog published the first release of its official provider for the OpenFeature web SDK, backed by posthog-js, so you can read feature flags through the vendor-neutral OpenFeature API instead of PostHog’s own client. The same release added a disableAutofocus option for surveys that stops an open-text question grabbing the caret and scrolling the page when it loads, which is useful for surveys embedded inline. OpenFeature support lowers lock-in, since flag-driven experiments can now sit behind a standard interface you could point at another tool later, and the survey fix removes a small but real annoyance when you use on-page surveys as the qualitative half of a test. Pairing the numbers with that kind of qualitative read is the habit we push in our CRO research methods guide. The release is listed in PostHog’s posthog-js releases.