# Seeing both sides of your own A/B test > Testing tools put each visitor in one variant by a cookie or id and keep them there. To see every variant, keep one browser profile per variant for the test. Source: https://mosaicbrowser.com/blog/seeing-both-ab-variants ## Seeing both sides of your own A/B test Testing tools put each visitor in one variant by a cookie or id and keep them there. To see every variant, keep one browser profile per variant for the test. ![One profile per variant, kept for the length of the test](https://mosaicbrowser.com/covers/seeing-both-ab-variants.webp) To see both variants of an A/B test you need two browsers the testing tool has never met, and you need to keep them. Optimizely, VWO, GrowthBook and the rest put each visitor in a variant by an id, usually stored in a cookie, and send that visitor to the same variant on every later visit. So the way to check every side of a test is one browser profile per bucket, kept for as long as the test runs. ## Why you keep landing in the same variant A testing tool's first job is consistency. If a visitor saw the new checkout on Monday and the old one on Tuesday, neither number would mean anything. So on the first visit the tool gives the browser an id, and from then on the variant is a function of that id. On the client-side platforms that id lives in a first-party cookie. Optimizely Web stores it as `optimizelyEndUserId`. VWO keeps a visitor id in `_vwo_uuid` and records the assigned combination for each test in a cookie named after the test, `_vis_opt_exp__combi`. GrowthBook hashes an attribute you choose, usually an `id`, together with the experiment's key into a number between 0 and 1, and the traffic split decides which range is which variant. Different mechanics, same consequence: same id in, same variant out. Server-side tests on logged-in pages use the account's user id instead of a cookie. There the variant follows the login, and two browsers signed in as the same test account will always agree. Mosaic is a desktop app Email yourself the link and open it on your computer. [How it works: REST API](https://mosaicbrowser.com/features/rest-api) ## What does not get you the other variant Reloading does nothing, by design. A different IP address, from a VPN or a proxy, also does nothing on its own: the cookie travels with the browser, and the tool reads the cookie. The address only matters for tests targeted by country or region, where it decides whether you are in the test at all. Clearing cookies or opening a private window does get you a new id, and so a new draw. That is a coin toss, and it costs you the state: the moment you close the window, the variant and everything you did in it are gone, and the next private window may draw the same variant again. With a 50/50 split, three fresh browsers all land on the same side a quarter of the time. Five still do one time in sixteen. Every one of those fresh draws is also a new visitor in your results. ## One profile per bucket The method that holds up is the dull one. Create a few profiles, open the page in each, see which variant each one drew, and keep the profiles that cover every side. Name each after what it showed ("Pricing test · B", "Pricing test · control"), so nobody has to work it out again tomorrow. Then keep them, because most of what is worth checking happens after the first page view: - The variant should survive a return visit a day later, which only a kept profile can show. - The rest of the funnel (signup, cart, checkout, the confirmation page) should stay on the same side of the test. - A follow-up email or a logged-in dashboard sometimes carries the test on, and you want to see it from the same visitor. - When the test ends, the profile should fall back to the winner, and a profile that drew the losing variant is the one that shows it. This is the opposite of what we recommend for automated tests, where [a fresh profile for every run](https://mosaicbrowser.com/blog/fresh-profile-per-test-run) keeps leftover state from making a run flaky. A one-time profile that trashes itself when its browser closes is exactly wrong here: the leftover state is the thing you are testing. ## Forced variants are for the page, buckets are for the test Most platforms also give you a way to skip the draw: a preview link from the dashboard, or a URL parameter that forces a variation for QA. Use it to check that a variant renders. It shows you the page without testing the assignment, so it cannot tell you that targeting excludes the right people, that the split is the one you configured, or that a visitor stays put across sessions. Real buckets can. Tests targeted by country add one more variable. A profile with a proxy in that country, and the timezone and language that go with it, is a visitor from there as far as the tool can tell; the date-and-deadline version of the same problem is in [testing in another timezone](https://mosaicbrowser.com/blog/testing-in-another-timezone). ## Keeping QA visits out of the numbers A team checking a test by hand can add dozens of new visitors to a small test. Most platforms let you exclude traffic by IP, and the office address is the usual filter. That filter stops working the moment a profile browses through a proxy, because the tool sees the proxy's exit, not your office. Exclude by something the test profiles carry instead: a query parameter on the first visit that your setup turns into an exclusion, or a cookie your platform recognises as internal traffic. In Mosaic each profile has its own cookie jar, so you can put that cookie into the test profiles once, from the Cookies tab of the profile editor, and it stays in those profiles and nowhere else. Giving each profile a clear name and a tag for the test it belongs to is the same habit described in [keeping twenty QA test accounts straight](https://mosaicbrowser.com/blog/qa-test-accounts-naming). When the test is a checkout, the profile that has never seen your store is also the right customer for [testing your checkout as a new visitor](https://mosaicbrowser.com/blog/test-checkout-as-customer). ## Questions ### Why do I always see the same A/B test variant? Because the testing tool gave your browser an id the first time you visited, usually in a cookie, and hashes that id into the same variant on every visit. That stickiness is deliberate: a visitor who flipped between versions would ruin the result. ### Does a VPN or a different IP show me the other variant? Not on its own. Most tools bucket by the visitor id in a cookie, not by address, so a new IP with the same cookies gets the same variant. A new address only matters when the test is targeted by country. ### Can I force a specific variant instead? Usually, yes. Most platforms have a preview link or a URL parameter that forces a variation for QA. It shows the page, but it skips the bucketing, so it will not tell you whether assignment and targeting work for a real visitor. ### Will my test visits skew the results? They can, because each fresh browser counts as a new visitor. Exclude QA traffic by a cookie or a query parameter you set in the test profiles, since an office IP filter stops working once a profile browses through a proxy. ## Related [A fresh browser for every test run, and why it should be cheap](https://mosaicbrowser.com/blog/fresh-profile-per-test-run): Leftover cookies and storage are where flaky browser tests come from. A one-time profile gives each run a clean jar and trashes itself when its browser closes. [Keeping twenty QA test accounts straight](https://mosaicbrowser.com/blog/qa-test-accounts-naming): Managing test accounts for QA goes wrong when the state lives in people's heads. Give each persona a profile with its login, role and state beside it. [Testing date and deadline features in another timezone](https://mosaicbrowser.com/blog/testing-in-another-timezone): Midnight cut-offs and "ends today" banners break in zones you don't live in. Test a website in a different timezone without touching your computer's clock. [Testing your own checkout as a customer who has never visited](https://mosaicbrowser.com/blog/test-checkout-as-customer): To test a Shopify checkout as a customer, pay with a test method from a browser that has never seen your store: no admin login, no saved address, no cart. [How to test a metered paywall as a new visitor](https://mosaicbrowser.com/blog/metered-paywall-new-visitor): A meter can count by cookie, by login, by address or by fingerprint. To test yours as a new visitor you need a browser that is new to every one of them. [Checking your cookie banner from the countries that require it](https://mosaicbrowser.com/blog/cookie-banner-by-country): Consent tools pick the banner by the visitor's IP location, so your office sees one version. Test each region from a fresh profile with an exit there. [Testing a site in another language means more than one header](https://mosaicbrowser.com/blog/accept-language-testing): Set Accept-Language alone and the page still formats dates for your own machine. A real language test moves the header, navigator.languages and Intl. [A retired bot test can still answer 200 and look like a pass](https://mosaicbrowser.com/blog/dead-detector-returns-200): Antoine Vastel's fp-scanner demo now serves his homepage with HTTP 200, which a challenge reader scores as a pass. His tests moved; here is where. ## Mosaic, on your own computer The browser this blog is about: its own Chromium, fingerprints from real machines and a proxy exit per profile. Free holds 3 profiles. Pro is $49 a month for any number. Mosaic is a desktop app Email yourself the link and open it on your computer.