What is server-side testing? A store owner's definition What is server-side testing? A store owner's definition

The verdict

The three decisions hiding inside “server-side”

Vendors sell “server-side” as one thing. It's three, and a tool can move the first without moving the second or the third. Ask which of them you're buying; almost nobody does.

A vendor who moves decision 1 and calls the product server-side testing has not removed the flash. A vendor who moves 1 and 2 has not fixed your data. The mechanics of the flash — every major vendor's default page-hiding timeout, read from their own code — are on client-side vs server-side A/B testing. This page stays on the definition.

Server-side testing vs server-side tracking

These two get used interchangeably and they are not the same purchase.

Server-side tracking, concretely. Meta's Conversions API is “a connection between an advertiser's marketing data … from an advertiser's server, website platform, mobile app, or CRM to Meta systems” (developers.facebook.com, read 26 Jul 2026). Google's equivalent is a server container: “You can set up a tagging server using GCP or a platform of your choice,” and for production, “We recommend that you provision it as a cluster for better availability, scalability, and performance” (developers.google.com, tag-manager server-side docs and manual setup guide, both read 26 Jul 2026).

Read that twice. Server-side tracking is infrastructure you run and pay for. Server-side testing is a decision you move. Most stores that say they've “gone server-side” have done one of them, not both.

The rest of the vocabulary, in shop English

What you can test on the server that you can't test in the browser

This is the whole reason to care. A browser script can repaint anything on the page. What it can't do is change what your backend decides — and on a store, the backend is where the money is.

Optimizely's glossary draws the same boundary in engineering language — server-side testing is “a form of experimentation where the variations of a test are rendered directly on the web server, before it is delivered to the client,” useful for “website elements that are handled by the back end, such as pricing, subscription offers and product discounts” (optimizely.com, read 26 Jul 2026). The table above is the version you can price.

What it costs, and who should not do this

Server-side testing is not an upgrade from client-side. It's a different job with a different bill. Four costs, none optional:

1. The variant has to exist in code before the test runs. Every test is a release.
2. Caching gets harder. Any full-page cache now has to vary on the assignment, or every shopper gets whichever variant was cached first.
3. It's engineer-owned. That reintroduces the exact dependency most operators bought a testing tool to escape.
4. It fixes nothing about experiment design. Sample size, novelty effects and peeking are identical problems on both sides.

VWO sells server-side harder than anyone and still says “a dedicated development team is required to run an end-to-end server-side test” (vwo.com/server-side-testing, updated 24 Feb 2026). The full bill, including the caching answers from Vercel and Cloudflare, is on what each side of the trade actually costs.

Who should not go server-side this quarter:

• Your last ten tests were copy, images and layout. Client-side ships those today with no engineer. Moving them to the server makes them slower to run and no more true.
• You don't have an engineer, or yours is building something else. Every vendor here, Mtrix included, needs one for the rendering step.
• Your traffic can't power the tests you already run. Traffic decides how many tests you can read; architecture doesn't. Removing the flash from a test that will never reach significance changes nothing about the result.
• Free is a hard constraint. See the last two rows of the table below. Mtrix is not one of them.

One case flips the rule, even for a cosmetic test: a storefront built in React, Vue or Svelte. GrowthBook's own docs warn that “heavily client-side-rendered apps (React, Vue, Svelte) may flicker or fight the SDK when the framework re-renders the DOM” (docs.growthbook.io, read 26 Jul 2026). On a headless storefront a client-side test can be unstable, not merely visible.

Where you can actually buy it

All read 26 Jul 2026 from each vendor's own pricing or docs pages.

If free is the constraint, three routes are genuinely free and none of them is Mtrix: Shopify Rollouts (included with your plan), GrowthBook (free Cloud tier and a free self-hosted build), and Statsig, whose Developer tier carries 2M events a month, unlimited seats and no credit card. Saying that costs us a click and saves you a month.

Server-side testing on Shopify: what Rollouts does, and where it stops

The answer changed this year. Anyone still telling you Shopify can't A/B test server-side is working from a page written before 5 June 2026.

Shopify Rollouts does it natively. Since 31 March 2026 it swaps whole themes; since 5 June 2026 it swaps whole “checkout and customer account configurations,” including “an A/B test between two entirely different themes or checkout setups” (Shopify changelog, both posts). Rollouts need the Basic plan or higher, experiments need Grow or higher, and they cover online-store checkouts only — headless and custom storefronts aren't supported. It's free, it's native, and for a small brand testing one checkout configuration against another it's a genuinely good deal.

Where it stops — all from Shopify's own Rollouts help pages, read 26 July 2026:

• The unit it swaps is a whole configuration, not an element. You can change a single block inside a rollout variant — “any customizations that you make in the theme editor apply to only that rollout” — but you do it by building and swapping a second configuration, so you can't run two element-level variants inside one setup.
• Targeting is percentage and market. Create-a-rollout offers “the percentage of visitors to launch the rollout to,” plus specific markets when you replace the main theme. No behavioural, referrer or segment targeting is documented.
• The metric set is fixed, and the checkout test gets the thinnest one. A launch rollout reports gross sales, AOV and orders; a checkout experiment reports checkout conversion rate and nothing else. “You can't customize the available metrics for your rollout.”
• No significance reporting is documented. Significance, confidence, probability and sample size appear on none of the four Rollouts help pages. The changelog frames it as “find the winner.” You look at the number and decide.
• Reverting cuts both ways. The default is safe — “by default, the rollout reverts. No changes are applied permanently to the affected resource.” Applying is the one-way door: “after you apply a rollout, you can't revert the changes.” And “you can't change Liquid templates as part of a rollout.”

What no testing tool can do on a Shopify store, Mtrix included: server-render its own variant inside a Liquid theme. That's a property of the platform, not a gap in anyone's product — and it's why price and bundle tests on Shopify are run by apps that change the cart, not by testing tools that change the page. The full ladder, tool by tool, is on Shopify checkout A/B testing.

What the glossary entries leave out

They define the term and never price it. The vendor selling server-side hardest is also the one that published the cost, in the sentence quoted above. Read the glossary and the sales page together.

“Server-side” gets sold as a fix for ad blockers. It isn't. Moving the decision to your server says nothing about where the result is sent, and most tools still beacon it from the browser to a vendor's domain. That's decision 3, and it's a separate purchase — here's what actually gets stripped.

“No developer needed” is the claim to interrogate hardest — including when we make it. Ask any vendor which half they mean. Assignment and rendering are different jobs. Mtrix's variant assignment needs no developer, on every install. Rendering that variant on the server is a one-time integration a developer does once, and then never again. Anyone telling you server-side rendering costs no engineering time is selling you decision 1 and staying quiet about decision 2.

Where Mtrix sits, precisely

Mtrix moves decision 1 for everyone and hands you decision 2. Here's the boundary rather than the pitch.

• Assignment is server-side on every test, on every install. The allocation is computed in Mtrix's backend, not in the browser. No configuration, no tier that withholds it.
• The assignment isn't in a browser cookie. It's a record in Mtrix's database against your visitor ID, with a 30-day server-side lookback, and Mtrix sets no third-party cookies at all — identity travels in the request body. One boundary worth having straight: the visitor ID that keys that record is a browser-written cookie on a plain CDN install, so Safari's seven-day cap applies to it, and the SDK integration guide documents setting it from your own server instead. The rule and the same fix Optimizely and VWO publish for their own tools are on client-side vs server-side A/B testing.
• Server rendering — decision 2 — needs a developer once. Roughly 35 lines calling getPageDetails() from a server load function, documented for Hydrogen, Next.js and SvelteKit. There's no dashboard toggle, and it isn't possible on a Shopify Liquid theme. Called from the browser instead, a Mtrix test behaves like any other client-side test. And one caching fact, stated plainly: under a server-side experiment the response is not cached per variant — it's marked uncacheable, so the variant is rendered per request rather than served from the edge cache.
• Decision 3 is yours to point. By default, events are a browser request to Mtrix's API. Route them through your own domain — an /api/events route on your server — and nothing is stripped.
• Two server-side details that rarely appear on a page like this. Mtrix captures first-touch fbclid, gclid, gbraid, wbraid and ttclid with a 90-day window and reads the ad platforms' own cookies on every event, with no vendor SDK loaded — it rebuilds the conversion signal a blocked pixel loses. And on Shopify, purchase attribution runs on a server-side Admin webhook (orders/paid, HMAC-verified) rather than a checkout script, so Shopify's 26 August 2026 checkout changes don't touch it. That one needs a _mtrixSession note attribute on the cart.

Three concessions, in the order they'll matter:

• Mtrix is web only. No native iOS or Android SDK. Holding one assignment across a website and a native app is among the strongest reasons to go server-side at all, and it's the reason to pick Optimizely or VWO over Mtrix.
• On a store that stays on Shopify, Mtrix gives you replay, analytics, experiments, error tracking and Core Web Vitals — not the builder, not price testing, not the checkout. Price is the headline server-side use case, so read that twice: price and offer testing are reasons to build on Mtrix, not to bolt it onto a theme.
• Session replay and error data are kept for one month. Events and purchases, three years.

What the developer's afternoon buys: no cap on experiments on any plan, 100% of sessions captured, overlapping tests bucketed so they can't collide via audience targeting, and a losing arm you can hand to session replay and watch.

FAQ

Next. If the flash is what you're solving, the mechanics and every vendor's page-hiding default are on client-side vs server-side A/B testing. If you're on Shopify, the ladder from Rollouts up through the paid apps is on Shopify checkout A/B testing. And if you want the decision on the server from your first test, with the session and the revenue report attached, that's Mtrix.