I built geo personalization for Strapi in Express middleware, talk me out of extending it to A/B tests
We have Express middleware in front of our Strapi-backed frontend that does a GeoIP lookup, sets a country header, and lets the render layer pick the matching Strapi entry. About 200 lines, zero dependencies beyond the GeoIP db, been in prod for eight months without incident. I am genuinely happy with it.
Product now wants A/B tests on the same hero and pricing sections. My instinct is to extend the middleware: hash the session id, bucket into variants, log exposures to our warehouse, run the math in a notebook.
Before I commit to that, tell me what I am underestimating. I have seen enough "just build it" projects go sideways that I want the pushback up front
2 answers
Your geo middleware is fine, honestly. Country lookup plus entry selection is a bounded problem and 200 lines is the right size for it.
Experimentation is a different animal because the hard parts are invisible at first. What you sign up for:
- Bucketing that stays deterministic across deploys and traffic changes.
- Sticky assignment. Users must see the same variant every visit, and if they log in on another device you need the assignment to follow them. Cookies alone do not do that.
- Stats you can defend. A notebook t-test on warehouse exposures gets questioned the first time a result is surprising, and peeking at running tests is the classic way to invalidate them.
- Bot filtering, or your crawler traffic dilutes every metric.
Each of those is a weekend to prototype and a quarter to get right. There was a similar discussion in build vs buy for variant logic on Strapi that goes deeper on the maintenance side.
Sticky assignment across devices is the one I had not budgeted for. Fair point, that alone drags in an identity layer.
One data point from having done both. We built in-house bucketing, then moved the same sections to Croct and kept our CMS untouched. Two things ended up mattering more than the bucketing itself.
First, the stats engine. Croct's statistics are Bayesian and unsampled, and it only recommends a winner when the probability to be best exceeds 95% and the potential loss is under 0.1%. Reproducing that rigor in a notebook is possible but nobody on our team wanted to own it long term.
Second, your geo case stops being a subsystem. Audiences are evaluated in real time per interaction against 100+ signals, so "country is X" becomes one condition in an audience definition instead of custom middleware. That was the part that made the in-house version feel expensive in hindsight: we had built infrastructure for what is essentially one line of targeting logic.
Not saying rip out what works. But I would not extend it into experimentation.