How do you ensure consistent A/B test variants across sessions and devices?

WHAT THIS TESTS: The interviewer wants to know if you understand that an experimentation platform is only as good as its identity layer. Specifically they are looking for awareness of two distinct problems: how to prevent a user from flipping between variants when they return on a different device or session, and how to credit the correct variant when a conversion happens hours or days after the initial exposure. This is fundamentally about user ID stability, cross-device persistence, and event attribution in a stateless HTTP world.

A GOOD ANSWER COVERS: First, establish a single stable user ID for the life of the experiment. For logged-in users this is typically your existing account UUID. For anonymous users you generate a first-party cookie or device ID, but you must not change it when the user later authenticates. Second, pass that exact ID into the experimentation SDK when you create the user context, because the SDK uses that ID to hash and bucket the user into a variation. Third, persist the ID across devices by linking it to authentication state. When a user logs in on a new phone, your app should resolve to the same account-scoped identifier so the SDK returns the same variation. Fourth, attach that same ID to every conversion event you send back to the experiment platform. The attribution join happens on that ID, so if the purchase occurs three days later on desktop, the event still maps to the original bucket.

COMMON WRONG ANSWERS: A major red flag is suggesting you randomize on every page load or per device. That re-buckets users, inflates visitor counts, and destroys statistical validity. Another mistake is relying on third-party cookies or fingerprinting for anonymous identity, since Safari and mobile browsers block or limit these. Some candidates propose merging logged-out and logged-in IDs inside the SDK, but Optimizely does not alias them. Changing the user ID inside an existing user context also corrupts the data. Finally, do not suggest storing the variant assignment in your own database unless you can also guarantee the same ID resolution everywhere.

LIKELY FOLLOW-UPS: The interviewer may ask how you handle users who see the experiment on mobile web but convert in the native app. They might also ask what happens if you need to run mutually exclusive experiments and have mixed anonymous and authenticated IDs in the same project namespace. Another follow-up is how you would handle a user who clears cookies or uses incognito mode, and whether you would still count them. You should also expect questions about the trade-off between MAU billing and ID stability, since unnecessary ID churn increases monthly active user counts.

ONE CONCRETE EXAMPLE: Imagine a SaaS pricing page test. An anonymous visitor lands on the site from a Twitter ad on their phone. Your server sets a first-party cookie with anonymous ID anon_123 and the Optimizely SDK buckets them into variation B. Three days later they return on a laptop, click a login link, and authenticate as user UUID abc_789. Because you persist the anonymous ID across the login boundary and continue using it in the SDK user context, the SDK still returns variation B. They upgrade to a paid plan. Your backend sends a conversion event with user ID anon_123, and the experiment platform attributes the revenue to variation B. If you had instead generated a new logged-in ID and created a fresh user context, the user might have seen variation A and the conversion would be misattributed or counted as a new visitor.