Linking Session Replays to A/B Test Variants Without Custom Engineering
When a VWO variant loses, you want to watch the replays of users who saw it — but Hotjar doesn't know which variant fired. Here's how to bridge the two without a dev sprint.
Quick answer
There is no native Hotjar ↔ VWO integration. To watch replays filtered by A/B test variant, you push the variant ID into Hotjar as a User Attribute (via Hotjar Identify API) and as a tag at the moment VWO assigns the user. Then filter replays by that attribute. No backend work — but you do need ~15 lines of JavaScript in your VWO variation code, and the linkage breaks the moment either tool changes its API.
Linking Session Replays to A/B Test Variants
The workflow of tagging session replays with the A/B test variant a user saw, so you can watch behaviour for winners and losers separately.
Linking session replays to A/B test variants is the practice of attaching the variant identifier (control, B, C…) from your testing tool onto each session recorded by your replay tool, so you can later filter replays by experiment outcome. It's the difference between knowing variant B lost and actually seeing the 40 users who rage-clicked the new CTA.
In fragmented stacks — typically Hotjar for replays and VWO, Optimizely or AB Tasty for testing — this linkage isn't built in. Teams hand-roll it with cookies, URL parameters, or JavaScript bridges that fire on variation assignment. The workaround works until a tool updates its API.
If you've run an A/B test in VWO and watched the conversion bar tick down on variant B, your next instinct is to open Hotjar and watch what those users actually did. That instinct is correct. The execution is where the stack fights back.
Why this breaks in a fragmented stack
Hotjar records sessions based on its own snippet. VWO assigns variants based on its snippet. The two scripts run independently in the browser and have no shared session identifier — Hotjar doesn't know that visitor 8a3f saw VWO's variant B, and VWO doesn't know which Hotjar recording corresponds to that visitor.
The result: when your test concludes, you have a winner in VWO and a pile of unfiltered recordings in Hotjar. Searching for the right replays means scrubbing through hundreds of sessions hoping to spot the variant by the visual difference on screen — fine for a banner colour test, useless for a copy or pricing test.
The hidden cost
Most teams give up after one or two tests and stop watching replays altogether. The result is a culture of running experiments without ever investigating WHY a variant lost — which is exactly the behavioural insight replays were bought to provide.
The three manual workarounds teams build
Workaround 1 — Hotjar User Attributes via JS API. Inside each VWO variation's custom JavaScript, call hj('identify', null, { vwo_variant: 'B', vwo_campaign: '47' }). Hotjar then lets you filter recordings by that attribute. Works on Business plan and above; fails silently if the Hotjar script hasn't loaded yet.
Workaround 2 — URL parameter tagging. Append ?vwo_v=B to internal links inside the variation. Crude, breaks SEO-sensitive pages, and only works for users who navigate. Workaround 3 — first-party cookie. Set a cookie on assignment, read it in a Hotjar Events trigger. Most reliable, but requires cookie-consent updates in the EU.
Implementing the Hotjar Identify bridge — the realistic option
In VWO's Visual Editor, open the variation, add a Custom JavaScript step, and paste a small wait-then-identify block: poll for window.hj every 100ms up to 3 seconds, then call hj('identify', visitor_id, { experiment_id: VWO_ID, variant_id: 'B', assigned_at: Date.now() }). Repeat the same call once per page-view inside that session in case Hotjar starts a fresh recording.
Then in Hotjar, build a saved filter — Recordings → Filter → User Attributes → variant_id is B — and bookmark it. You'll get a clean stream of replays from that variant. Expect a 5-10% data loss versus VWO's own count, because Hotjar samples sessions and the identify call sometimes loses races with page-unload events.
What breaks this setup
Hotjar API changes (the last one was the v6 → v7 rewrite in 2022), VWO snippet changes, single-page-app route changes that re-run VWO but not Hotjar, and consent-mode flips where Hotjar loads late. Audit the bridge after every quarterly tool update.
Why a unified platform removes the problem
When replays and experiments live in the same platform, the variant assignment IS a property on the session — no bridge, no JS API, no race condition. Click a losing variant in the experiment report and the filtered replay list opens beside it. This is the core argument in the GA4 + Hotjar + VWO vs Unified CRO Platform comparison: the integration tax disappears.
For Shopify and WooCommerce teams running 4-8 tests a month, that's an hour of dev plumbing saved per test plus a meaningful jump in how often the team actually watches loser-variant replays. Watching the loss is where the next hypothesis comes from.
Frequently asked questions
No. As of 2024 there is no official Hotjar ↔ VWO connector. Both vendors document the JS-bridge workaround in their help centres but neither ships it as a one-click integration. Optimizely has a slightly tighter Hotjar partner page but the underlying mechanism is the same Identify API call.
User Attributes (the cleanest method) require Hotjar Business or above. On Plus, you're limited to URL-parameter tagging or filtering by Hotjar Events, which works but is coarser — you can confirm a variant fired, but not segment recordings by variant ID.
The identify call itself is ~1ms. The real performance cost is running Hotjar + VWO + GA4 snippets together, which typically adds 200-400ms to Largest Contentful Paint on mid-range mobile. That cost exists with or without the bridge.
Clarity has a similar custom-tags API — clarity('set', 'vwo_variant', 'B') — and it's free, which is why more teams are switching. The bridge logic is identical; you replace the hj() call with clarity().
VWO fires the same assignment callback for control as for variants — you tag the control session the same way, with variant_id: 'control'. If you skip control tagging, you can't compare behavioural patterns between control and treatment, which is half the point.
Yes. The visitor_id you pass to Hotjar Identify must not be a personal identifier, and the cookie-tagging variant needs to sit behind your consent banner's analytics category. In the EU, run it through your CMP (Cookiebot, OneTrust) like any other tracking script.
Google Optimize was sunset in September 2023, so this is now a legacy question. The same pattern works with its replacements — GA4 + a third-party tester like Convert or AB Tasty — but you lose the GA-native experiment dimension Optimize used to provide for free.
Across the teams we've audited, 5-15% of sessions don't get tagged correctly — usually because Hotjar's script loads after VWO's variation code runs, or because the user leaves the page before identify completes. Build the analysis assuming the tagged set is a sample, not the population.
Probably yes for the first test, because the qualitative insight from watching one losing variant usually rewrites your next three hypotheses. After that, ROI depends on whether you're getting enough learning per test to justify the maintenance — most teams running fewer than two tests a month let the bridge rot.
Variant assignment writes the experiment_id and variant_id directly onto the session record at the database layer, not via a browser-side API call. That means zero data loss, zero race conditions, and one-click filtering from the experiment report into the replay list — covered in the GA4 + Hotjar + VWO vs Unified CRO Platform comparison.
Get an AI expert review of your site
Paste your URL — Metricuno's AI runs the same heuristic checks a senior CRO consultant would, scoring your page and prioritising the fixes that'll move conversion fastest.