Next.js, Middleware, A/B Testing, Auth0, GTM
Nights Plus — A/B Testing Infrastructure
Implemented cross-repo A/B testing between two entirely separate Next.js applications for Nights Plus — gradually rolling out a redesigned events experience to a percentage of users while keeping URLs identical, with cookie-based session stickiness, feature flags, and GTM/GA instrumentation to measure conversion impact.
What needed to be solved
The existing Nights Plus platform had severe technical debt — duplicated logic, inconsistent data flows, and a UI that frustrated users. A full rebuild was the right call, but completing a replacement would take months. The risk of a big-bang launch was too high: ship too early and users hit a broken product; delay and the debt keeps compounding. The strategy was to rebuild incrementally — starting with events and event detail pages — and use A/B testing to serve the new experience to a percentage of users while the old site remained live for everyone else. Two completely separate repos with different Next.js versions and different infrastructure were involved — this was not same-repo variant testing but genuinely two different applications.
Key Decisions & Challenges
Next.js Middleware Over Cloudflare for Traffic Splitting
Situation
We needed to split traffic between two completely separate Next.js applications — different repos, different Next.js versions, different infrastructure — while keeping the URL identical for all users regardless of which app served them. Two approaches were evaluated.
Options Considered
- Cloudflare — route traffic at the CDN level, split between origins based on rules. Explored and confirmed working, but required a separate Cloudflare configuration layer, its own logic for cookies and flags, and an external dependency that neither app controlled directly
- Next.js Middleware on the old site — intercept requests in the existing application, proxy the response from the new site for a configured percentage of traffic, handle cookies and feature flags in-process without any additional infrastructure
Decision
I chose Next.js Middleware. Both approaches worked in testing, but Cloudflare introduced a separate configuration layer that lived outside either codebase. Middleware kept everything self-contained — the old site owned the routing logic, feature flags, and cookie state. No additional third-party service, no separate repo for traffic rules, and the kill switch was a single flag in the existing codebase.
Cookie-Based Session Stickiness for Consistent User Experience
Situation
With random traffic splitting on every request, a user could land on the new site once and then be served the old site on their next visit — creating a jarring experience of switching between two completely different designs mid-session or across visits.
Options Considered
- Stateless random split on every request — simplest implementation, but users see different versions unpredictably across visits and sessions
- Cookie-based stickiness — on first assignment, write a cookie that locks the user into their cohort for all subsequent visits
Decision
Cookie-based stickiness. Once a user is assigned to the new site, a cookie is written and all subsequent requests check it and serve from the new site. This guarantees a coherent experience — users don't bounce between two different designs. The cookie also made QA and targeted testing straightforward: force any specific browser into either cohort by setting the cookie directly.
Features
Middleware-Based Traffic Splitting
The old site's Next.js middleware intercepts requests for A/B-tested routes. Based on a configurable traffic ratio, a percentage of requests are proxied to the new site while the URL in the browser remains completely unchanged.
Cookie-Based Session Stickiness
On first assignment, a cookie is written to lock the user into their cohort. All subsequent visits check the cookie and serve the same version — users are never shown the old site after being assigned to the new one.
Feature Flag Kill Switch
A/B testing can be disabled entirely without touching code. A flag controls whether the middleware performs any splitting at all, allowing instant rollback in production without a deployment.
Env-Driven Traffic Ratio
The percentage of users routed to the new site (10%, 20%, etc.) is controlled by an environment variable. Traffic can be ramped up or down with a config change and redeploy — no code diff required.
GTM and Google Analytics Instrumentation
GTM and GA were configured to track which version each user was served and measure their behaviour — add-to-cart rate, purchase completion, and session engagement — to enable data-driven decisions on when to cut over fully to the new site.
Cross-Repo Auth Integration
Old site ran Auth0 v3, new site used Auth0 v4 with a different session structure. Rather than downgrading the new site, a dedicated auth route was added to the old site that the new site calls to retrieve session data. Cookie handling was updated on both sides to maintain consistent authenticated state across the two applications.
My Role
I was the sole developer responsible for the full A/B testing implementation — evaluating approaches, setting up the middleware, cookie management, feature flags, env-based traffic control, cross-repo auth integration, and GTM/GA instrumentation.
Tech Stack
Outcome
A/B testing went live for the events and event detail pages. A configurable percentage of users were served the redesigned experience while URLs remained identical across both cohorts. The feature flag and env-controlled traffic ratio allowed the team to ramp up safely and roll back instantly without any code changes. Auth worked seamlessly across both applications without requiring the new site to downgrade its Auth0 version.