Name

experiments — Experiments without the branch juggling

Synopsis

experiments --client "subscription ecommerce, Shopify" --role "Research, design and build" --when 2026

--stack Vue 3, TypeScript, GrowthBook, Edge functions, Shopify

Description

Moved a storefront’s A/B tests from separate deployed copies of the site to feature-flag experiments, so a new test is a config change and every order records the variant it came from.

Context

The client is a subscription ecommerce brand on Shopify. Its team tests offers, prices and sign-up steps all the time, and each test used to be a separate build of the whole site, with a cookie deciding which one a visitor saw.

That worked for one test at a time. With several running at once, every experiment meant a long-lived branch to keep in sync, an extra deploy to watch, and fixes that had to land everywhere. It was also hard to say which variant a given order came from.

My role

I wrote the recommendation, agreed the approach with the client’s architect and data team, and built it.

What I did

• One build, many experiments. Variants became feature flags, evaluated at the edge before the page loads, so visitors don’t see the page change under them. If evaluation is slow, the visitor simply gets the default version.
• A registry, not branches. Each experiment is one entry that names its variants. Starting a test is a normal pull request.
• Every order knows its variant. The experiment and variant travel with the cart to the order, so the data team can tie results to variants directly.
• Consent first. A visitor who declines analytics keeps a stable experience for their visit, and nothing about them is stored or tracked.
• Easy QA. Any variant can be forced from the URL, so the client can review each version before it goes live.
• Cleaned up after myself. Once the old setup was no longer needed, I removed its tooling.

Trade-offs

Evaluating flags on the server adds a request before the page shows; evaluating them in the browser avoids it but ships every experiment’s rules to every visitor. I kept server-side evaluation with a short timeout and a safe default, so a slow network costs a visitor the experiment, never the page.

For visitors who decline analytics, dropping them from experiments entirely would have changed the page mid-visit for anyone who answered the cookie banner late. Keeping their variant, and leaving them out of the analysis, was the better experience and still respected their choice.

Outcome

• New experiments ship as configuration instead of branches and extra deploys.
• Results can be read straight from orders, checked end to end with real test orders.

What I’d do differently

Agree the analytics event design with the data team before writing client code. A late gap there cost a round of rework.

See also

one-codebase(1), faster-funnel(1), tiago(1)