Mystery Shopping & CX Testing: Clean Profiles for Honest Results
How mystery shopping and CX agencies use isolated browser profiles to test personalization, regional pricing, and loyalty flows without cross-contaminating data.
Why one browser can't play five different customers
A mystery shopping or CX research agency gets a brief: check how an online store treats a first-time visitor, a loyal customer, a shopper from another city, a mobile app user versus a desktop one. This is routine, legitimate work — it's how agencies test price personalization, loyalty program behavior, recommendation relevance, geo-targeting accuracy, and whether promotions are shown fairly across segments. Usually it's commissioned by the store itself or done with its consent; sometimes it's part of an independent market audit, but never a way to trick the system for personal gain.
The problem is that a regular browser on one machine physically can't impersonate different shoppers. A site recognizes a returning visitor through cookies, sometimes through device fingerprint, sometimes through IP — and if a tester opens five tabs on the same computer, the store sees the same person five times in a row. Instead of five distinct scenarios, you get corrupted data: the system mixes in leftover browsing history, retargeting pulls products from a previous session, and the "new visitor" actually sees personalization calculated for yesterday's "loyal customer."
This isn't about bypassing protection — it's about keeping the experiment clean. If profiles bleed into each other, the agency's report is wrong, and the client makes a decision based on bad data.
What needs to be isolated for a valid test
For a fair CX test, different buyer personas need to actually look different to the site:
- Cookies and local storage — a new visitor should have none at all; a returning customer needs their own order and browsing history.
- Browser and device fingerprint — OS, browser version, screen, GPU, font set. Otherwise the site can link "different" customers by technical signals even after cookies are cleared.
- IP and geolocation — the exit city and country must match the persona's story; testing regional pricing makes no sense if every request comes from the same IP.
- Behavioral history — a fresh visit with no warm-up looks nothing like a visit from someone who's been browsing categories and favoriting items for a week.
GetAntik gives each such profile a managed fingerprint — OS, browser brand and version, screen, core count, canvas/WebGL/audio noise, timezone and language pulled from the proxy's exit IP. A persona like "shopper from Austin on an Android phone" and "shopper from Chicago on desktop" look to the site like two completely different people, not one tester with a flipped user-agent string.
Which fingerprint parameters actually matter and how to avoid mixing them up between profiles is covered in detail in the post on fingerprint consistency — it also lists common mismatches that make "different" personas suddenly look suspiciously alike.
Building a persona set for the job
Before launching a test, an agency typically defines 5–15 personas depending on client size and audit depth. A sample set for a mid-sized fashion retailer:
| Persona | Geo | Device | History |
|---|---|---|---|
| New visitor | client's city | desktop | empty |
| New visitor | neighboring region | mobile | empty |
| Repeat customer, 5+ orders | client's city | desktop | warm |
| Abandoned cart 3 days ago | client's city | mobile | warm |
| International customer | overseas | desktop | empty |
| Newsletter subscriber, no purchases | client's city | desktop | warm |
Each row needs its own profile: a dedicated proxy matching the geo, its own cookie set, its own browsing history. The free plan's 3 profiles won't cover this kind of matrix, but Starter at 20 profiles for $5/month already handles a small agency with one active client; for running several clients in parallel, agencies usually move to Base at 100 profiles.
Warm-up: without it, a persona looks fake
The difference between "new visitor" and "loyal customer" isn't just cookies — it's behavioral history. If a profile meant to represent a "loyal customer" was created five minutes ago and immediately checks personalized pricing, many personalization engines simply won't have had time to apply logic based on interaction history, and the test will show a false result.
That's why profiles for "warm" personas are prepared in advance: a few sessions browsing categories, favoriting items, subscribing to a newsletter, maybe one or two test purchases — depending on the loyalty level being simulated. GetAntik supports manual and scheduled cookie warm-up, so an agency sets up a "visit every two days, browse 3–5 products" scenario once and gets a profile with a plausible history by the time the real test runs, instead of an artificially aged cookie jar.
https://www.youtube.com/
https://www.wikipedia.org/
https://www.reddit.com/
https://www.amazon.com/
The app opens the profile, browses the sites and closes it. Profiles in use are skipped.
A detailed breakdown of preparing profiles before putting them to work — and why a sudden burst of activity from zero often breaks a test — is in the post on account warm-up. It's written around ad accounts, but the underlying principle — history needs to exist before the profile starts doing its job — applies to CX testing just as directly.
Geo and proxies: without them, regional pricing tests are meaningless
If the task is to compare what a shopper in New York sees versus one in Phoenix, a browser fingerprint alone isn't enough — sites determine region primarily from IP. You need proxies that physically exit in the right city or at least region, with a timezone and language matching the persona's backstory.
GetAntik automatically sets the interface timezone and language from the proxy's IP, so a profile doesn't give itself away with a mismatch like "English-language browser, proxy exiting from a different country." The proxy manager lets you check proxies before a test starts and rotate them if a specific IP ends up on a client site's suspicious list — which happens when a store aggressively blocks datacenter ranges.
How to pick the right proxy type for a given task — residential for retail sites, mobile for app testing, datacenter for internal checks — is covered in the post on proxy types for multi-accounting, which also includes cost benchmarks useful for budgeting a test with dozens of personas.
If the scope is broader than one store — say, checking how ad creative and banners change by country — the logic largely overlaps with geo-testing for ads, which covers a country/language matrix approach that adapts easily to a buyer-persona matrix.
Team structure: who runs which profiles
A mystery shopping agency rarely has one person doing everything. Usually there's a researcher who designs scenarios, two or three field testers who log into profiles and record results, and a manager who compiles the client report. Each person should have access only to their assigned set of profiles — a tester running the "new visitor" scenario shouldn't be able to accidentally open the "loyal customer" profile and contaminate its history.
GetAntik handles this with roles and limits: an admin sees the client's full profile pool, a member sees only the personas assigned to them, and the finance role tracks proxy spend per project separately. Profile handoff between testers is a formal transfer, not a shared password in a chat app — important when an agency juggles several clients at once and doesn't want access to get crossed.
Live view is also useful here: a project lead can watch a tester's session in real time and confirm the scenario is running correctly before the result goes into the client report.
How to structure roles, limits, and handoff within a team is covered in the post on team roles and profile handoff, including common permission mistakes specific to agencies running multiple clients in parallel.
Scale: when personas number in the hundreds
A small agency testing one client across 10–15 personas quarterly can manage with a mental checklist. But an agency running ongoing CX monitoring for five or six retailers quickly accumulates 80–150 personas — each client with its own segments, regions, and check frequency. Without structure, profiles start to blur together; it's no longer obvious which profile belongs to which client or when it was last warmed up.
Grouping profiles by client, project, and persona type — rather than keeping a flat list — solves this. GetAntik lets you organize profiles into groups and tag proxies, so the list shows at a glance which profile serves which task, its status, and when it last ran.
Spend, 30 days
Principles for organizing a large profile pool without chaos are covered separately in the post on organizing hundreds of profiles. It's written around media buying examples, but the grouping structure and naming conventions transfer to a CX agency without changes.
Common mistakes
Using the same proxy for different personas. If "new visitor" and "loyal customer" connect from the same IP, the site can link them by that signal alone even with different cookies — especially if the store fingerprints at the session level, not just via cookies.
Running all personas in a single day. A sharp spike in activity from "different devices" within the same narrow time window can look suspicious to the store's own security system, triggering extra verification steps that skew the test result.
No documentation per persona. A month later, nobody remembers why "client-3" profile is configured the way it is or what backstory it represents. Geo, device, and history for each persona need to be logged in the profile card or a shared spreadsheet the whole team can see.
Testing without the client's consent, when it's not your own site. If an agency tests a store it has no audit agreement with, that's no longer CX research — it's unauthorized probing of someone else's business logic. The legality of a test depends on who commissioned it and why, not on what the browser is technically capable of doing.
Mixing up tester roles. One person testing both "new visitor" and "loyal customer" in the same browser session without switching profiles is a common reason test data later doesn't match reality.
Protecting client data
Agencies often get internal analytics access, test discount codes, or even admin panel access from the client to verify what the store sees on its own side. This data deserves the same care as client passwords in any other consulting engagement.
Profiles in GetAntik are encrypted on the device with the account password, and the server has no access to the contents — this reduces exposure if the agency's account is compromised or an incident needs investigating. For scenarios where a tester needs two-factor keys for the client's test accounts, a built-in 2FA vault inside the profile means codes don't need to be forwarded through chat apps.
More on encryption and access recovery is in the post on profile security. For a broader picture of team capabilities, the team features page covers roles and limits, and the security page covers profile data encryption.
FAQ
Is it legal to visit a site posing as different shoppers? Yes, if it's an agreed-upon audit of the client's own site or independent market research that doesn't manipulate someone else's system for illegal gain. The distinction from rule-breaking is that mystery shopping doesn't trick a site's security to steal discounts or data — it honestly records what the site shows different user segments.
How many profiles are needed to start with one client? Usually 10–20 personas cover a first audit of a mid-sized online store: a few geos, a couple of device types, three or four loyalty tiers. Starter's 20 profiles handle that comfortably.
Does every profile need warm-up? No. A "new visitor" persona needs none — warm-up would actually hurt it, since it should have an empty history. Only profiles simulating returning customers or subscribers need warming.
How often should the test be repeated? It depends on how often the client changes pricing and marketing policy. For active e-commerce brands, repeating the matrix every one to two months makes sense; for slower-moving niches, quarterly is usually enough.
Can data collection be automated instead of browsing by hand? Partially. For public data like prices and stock levels, scripts via Puppeteer or Playwright on top of a profile work well — covered in the post on profile automation. But for personalized experience checks (push notifications, personal discounts, chatbot behavior), a manual pass through the profile is usually more reliable — scripts miss nuances a live tester catches.
If you need to estimate how many profiles and proxies your agency will need for a given client volume, it's worth checking the plan options on the pricing page, and you can install the app for your first test from the download page.