Experimentation News: July 2026

This fortnight the biggest move is a full platform release rather than a single feature: GrowthBook 5.0 landed as a week-long rollout. Alongside it, Statsig tightened who can delete what, and PostHog cleaned up two survey targeting bugs. Here is what shipped and whether it matters for a small experimentation programme.

GrowthBook 5.0 lands as a week-long rollout

GrowthBook shipped its 5.0 release starting 20 July, and it is a broad one: the team rewrote feature flags from scratch, brought Product Analytics to general availability on 22 July, added feature-flag governance guardrails on 23 July, and made experiment setup and warehouse queries faster on 24 July. The Product Analytics piece is warehouse-native and built on the same metrics your experiments already use, with funnels, composable dashboards and experiment meta-analysis. For a small team the useful part is that your analysis and your tests now sit on one metric definition, so a funnel and an experiment readout cannot quietly disagree, and the new governance guardrails are meant to catch a badly scoped flag before it ships, whether a person or an AI agent wrote it. Because GrowthBook is open source, this is also a genuine option if you are pricing up paid tools; our Optimizely alternatives guide covers where it fits. The full breakdown is in GrowthBook’s 5.0 announcement.

Statsig splits config edit and delete permissions

On 14 July Statsig added granular role permissions for configs, letting you manage Edit, Archive and Delete as separate permissions on the Role Permissions page instead of bundling them together. It is opt-in, so you have to ask your Statsig account team to switch it on, after which the standalone Delete permission shows up under Project Settings. This is a governance detail, but a practical one: you can let a wide group edit and iterate on gates and experiments while keeping delete rights with a handful of people, which lowers the odds that someone removes a running config by accident. That separation of “can change” from “can destroy” is the same discipline a good CRO process applies to test setup. The change is logged in Statsig’s product updates.

PostHog fixes two survey targeting races in posthog-js

On 21 and 22 July PostHog shipped fixes to posthog-js that stop surveys firing when they should not. The 21 July fix makes the survey display loop wait for feature flags to load before it trusts the internal targeting flag, and forces a flag reload after a survey is completed, so a recurring survey stops re-showing off stale flag state. The 22 July fix scopes a shown-but-never-dismissed survey to its triggering session rather than persisting that activation indefinitely. If you use on-page surveys as the qualitative half of your testing, these matter, because a survey that pops for the wrong people pollutes the very feedback you are trying to read cleanly. Pairing survey feedback with your numbers is the habit we push in our CRO research methods guide. Both fixes are listed in PostHog’s posthog-js releases.