Isolated Browser Profiles for Academic and Audit Research: Collecting Web Data Cleanly
Separate browser profiles solve a problem many researchers don't notice until the data is already collected.
Consider a study of how a retailer's pricing responds to different user signals — location, browsing history, device type. This is classic algorithm audit research. The methodology: visit product pages as "different users" and log what is shown.
If all of those "different users" are the same browser, the dataset is compromised. Same canvas fingerprint, same WebGL renderer, same installed fonts, and the same cookies and local storage carried from one visit to the next. The site is responding to one browser, not several.
A VPN doesn't fix this. Changing IP addresses changes one signal, but personalization systems can use many browser signals. Keeping each simulated user in its own profile, with its own cookies, storage, proxy and identity parameters, is what keeps the samples independent.
This isn't an edge case. It's what happens when researchers underestimate how much state a browser carries.
What This Workflow Covers
A controlled data collection setup for academic research and algorithm audits. By the end:
- Multiple browser profiles, each with its own distinct identity parameters
- Proxy configuration for geographic research (pricing by location, for instance)
- A verification workflow confirming each profile is separate and consistent
- Clean methodology documentation for your paper's appendix
This applies to journalism teams investigating platform personalization, academic auditors studying discriminatory pricing, and anyone collecting web data where the site's response depends on who's asking.
Why Standard Research Tools Fail for Academic Data Collection
Before getting into the workflow, here is what doesn't give you independent samples.
Incognito mode — Clears cookies. Doesn't change the browser's identity parameters. The same canvas hash, WebGL renderer string and timezone are visible. You're the same browser with amnesia.
VPNs and proxy rotation — Changes your IP. Doesn't touch fingerprints. Better than nothing for geo-testing, but large platforms use more than IP. They may show "San Francisco pricing" if your IP is there, while other browser state still ties visits together.
Multiple browser installations — Chrome, Firefox, Edge, Safari. Different browser families, but your hardware signals leak through. Same GPU. Same screen resolution. Same installed fonts. Cross-browser tracking is real.
Virtual machines — Better isolation, but painful to scale. Spinning up 100 VMs for a pricing audit is technically possible but operationally miserable. And unless you configure each VM deliberately, they'll share the same defaults. VMs are a hammer when you need a scalpel.
Audit research of this kind, such as work by The Markup and AlgorithmWatch on platform personalization, relies on keeping simulated users apart. The methodology isn't new, but the tooling has become more accessible.
Prerequisites
- JustBrowser installed — the 7-day trial is full access with unlimited profiles, which is enough to run a pilot before you commit. After that it's $9.99/month.
- Residential or ISP proxies for geographic studies, from a reputable provider. Proxies aren't included in the subscription (bring your own or buy a proxy plan in the app), so budget for them separately.
- Research methodology documented — what you're measuring, how many profiles, which geographies
- IRB approval if your institution requires it for your study design
If you're not familiar with browser fingerprinting basics, spend fifteen minutes reading about canvas, WebGL, and audio fingerprinting first. Understanding what you're controlling makes the whole workflow make more sense.
Step 1: Define Your Research Profiles
Good research starts with methodology, not tools.
Example: Studying e-commerce pricing variation by US region
| Profile | Simulated User | Location | Browser | Purpose |
|---|---|---|---|---|
| A | Midwest suburban, Windows | Chicago, IL | Chrome/Win | Baseline midwest |
| B | Coastal urban, Mac | San Francisco, CA | Chrome/Mac | Coastal comparison |
| C | Southern suburban, Windows | Atlanta, GA | Chrome/Win | Southeast region |
| D | Northeast urban, Mac | Boston, MA | Chrome/Mac | Northeast comparison |
| E | Mountain region, Windows | Denver, CO | Chrome/Win | Midwest/mountain variant |
Why this level of detail? Because each profile's settings should be internally consistent. A "Chicago user" with a San Francisco timezone and German language settings is a confound in your data. Real users have coherent settings.
For a pricing audit, you probably want 3-5 profiles per region, 4-8 regions, and at least 3 visits per product per profile. That's potentially hundreds of profile-visits. Plan accordingly.
Many audits skimp on sample size. Opinion: if your n is under 100, you're writing an anecdote, not a study. This is tedious, but sloppy methodology is worse.
Step 2: Create Isolated Browser Profiles
In JustBrowser, each profile is its own browser. Different identity parameters, different cookie jars, different storage.
Creating the Chicago profile:
- Click "New Profile"
- Set OS to Windows
- Set timezone to
America/Chicago - Set language to
en-US - Leave identity generation on automatic — the engine generates internally consistent canvas, WebGL, audio, and font parameters that match the OS/locale combination
JustBrowser's native Chromium engine handles this at the C++ level. Each profile gets its parameters from the engine, not from a JavaScript overlay.
Critical for research:
- Cookie isolation prevents cross-profile contamination
- Storage isolation keeps localStorage and IndexedDB separate
- Cache isolation means no shared images or scripts
Name profiles descriptively: Research-Chicago-Win-A, Research-SF-Mac-B. You'll thank yourself when you're analyzing data from 50 profiles.
Step 3: Configure Geographic Proxies
Each profile needs a proxy in the location it represents.
Proxy selection for academic work:
| Profile | Proxy Type | Why |
|---|---|---|
| Chicago | US ISP/Residential | ISP proxies are more stable for repeated visits |
| San Francisco | US Residential | Shows what a home user on a local network gets |
| Atlanta | US ISP | ISP matches what a local visitor would see |
Major platforms often serve datacenter IPs differently from home users, which would distort results about what a local visitor sees. Residential or ISP proxies give you the view a local user gets. Stay within each site's terms and robots.txt, and don't use proxies to get around a block the site has placed on you.
Proxies are often the largest running cost in a study like this. Providers price static IPs and per-gigabyte residential traffic differently and change their prices often, so compare each provider's current pricing page against your study's visit count. Check whether your institution already has a proxy agreement for research.
In JustBrowser, paste the proxy credentials in each profile's settings and verify the connection. The proxy tester shows the exit IP, organisation, country, city, timezone, latency and flags for proxy, hosting and mobile. Confirm the country and timezone match the profile.
Step 4: Verify Profile Separation
Before collecting data, confirm your methodology is sound.
For each profile, independently:
- Launch the profile
- Visit BrowserLeaks — record the canvas and WebGL values
- Check that timezone, language and the proxy's country agree
- Document results
Expected outcome: Each profile reports its own distinct values. If two profiles report identical ones, they are not separate.
This verification step belongs in your methodology appendix. "Profile separation was verified with a public fingerprint viewer; each profile reported distinct values (see Appendix B)." Reviewers appreciate when you show your work.
Consistency check: Open the same profile on three different days. Its values should stay stable, because a longitudinal study depends on a profile being the same participant each time.
Step 5: Define Each Profile's History Deliberately
A brand-new profile has no browsing history, and a profile with history behaves differently on personalizing sites. That is a variable in your study, so decide on it.
- For a "new user" condition, use a fresh profile and record that it had no history.
- For an "established user" condition, give each profile the same scripted, documented browsing sequence related to your research category (shopping sites for e-commerce audits, news sites for media studies), and log it.
- Whatever you choose, apply it equally across profiles and write it into your methodology.
Controlling this explicitly gives you cleaner data than leaving it to chance.
Step 6: Data Collection Workflow
With verified profiles, you're ready to collect.
Manual collection workflow:
- Launch Profile A
- Visit target page (product page, search results, etc.)
- Record the data point (price, ranking, content shown)
- Close Profile A completely
- Launch Profile B
- Repeat
Automated collection (REST API):
JustBrowser's local REST API lets you script this. Launch profiles programmatically, connect via CDP (Chrome DevTools Protocol) to Playwright or Puppeteer, navigate, extract data, close.
# Pseudocode — actual implementation varies
for profile in research_profiles:
# The API starts profiles headless unless told otherwise; ask for a visible window
r = requests.post(f"http://127.0.0.1:36542/api/v1/profiles/{profile.id}/start", headers={"Authorization": f"Bearer {TOKEN}"}, json={"headless": False})
cdp_url = r.json()["data"]["cdp_url"]
browser = playwright.chromium.connect_over_cdp(cdp_url)
context = browser.contexts[0] # the profile's own context, never new_context()
page = context.pages[0] if context.pages else context.new_page()
page.goto(target_url)
price = page.query_selector('.price').text_content()
log_data(profile.location, price)
browser.close() # only disconnects
requests.post(f"http://127.0.0.1:36542/api/v1/profiles/{profile.id}/stop", headers={"Authorization": f"Bearer {TOKEN}"})
Automated collection scales better but requires engineering work. For a 50-profile audit with 500 data points, automation is practically necessary. For a 5-profile pilot study, manual is fine.
If you run a site yourself and want to understand automated traffic from the other side, ClickzProtect is our passive bot detection platform.
Common Errors and Fixes
Profile reports the same values as another profile
Cause: You're opening tabs in one profile, not launching separate profiles. Fix: Close everything. Launch one profile, test, close completely. Launch the next.
Platform serves cached or generic content
Cause: The site may not be personalizing for a profile with little history. Fix: Apply your documented history sequence from Step 5 (visit the site several times) and collect data on later visits, equally for all profiles.
Proxy tester flags the IP as hosting
Cause: Your proxy provider may have sold you datacenter IPs labeled as residential. Fix: Ask for a replacement or refund, and buy from a reputable provider.
Profile values change between sessions
Cause: The profile's identity settings were edited or regenerated. Fix: In profile settings, verify the identity parameters are saved and not being regenerated.
Ethical Considerations
A few things that matter for legitimate research:
Respect rate limits. Don't hammer servers. Insert delays between requests. Your institution's network relationships matter.
Follow robots.txt and the site's terms. If your study needs pages a site restricts, raise it with the site or your institution's counsel before collecting, rather than working around the restriction.
Document everything. Your methodology should be reproducible. Another researcher should be able to replicate your profile setup.
Don't impersonate real people. Fake personas are fine for research; fake identities that claim to be real individuals are not.
Consider disclosure. Some researchers publish detailed methodology; others keep it vague to prevent platforms from gaming future audits. There's no universal right answer. Transparency supports replication; some researchers also weigh the risk of platforms changing behaviour once they know the audit method.
For tracking your own analytics on research projects for your own sites, JustAnalytics provides privacy-first tracking. If your project needs email on its own domain to correspond with survey participants, JustEmails provides custom-domain mailboxes.
Next Steps
Scale carefully. Start with a 5-profile pilot. Validate your methodology. Then expand. Run the pilot inside the 7-day trial; at $9.99/month with unlimited profiles, production research costs the same as the pilot did.
Automate for large studies. The local REST API + Playwright combination can work through a large profile set unattended. Not glamorous work. But it beats clicking through profiles manually at 2 AM. See our Playwright integration guide for detailed patterns.
Contribute to methodology literature. Academic transparency about data collection methods helps everyone. If you publish, describe your profile isolation approach in enough detail for replication.
Consider longitudinal studies. Browser profiles can persist for months. Track how personalization changes over time, not just cross-sectionally.
Frequently Asked Questions
Why can't I just use incognito mode for research data collection?
Incognito mode doesn't change your browser fingerprint. Sites still see the same canvas hash, WebGL renderer, timezone, and dozens of other signals. If you're studying personalized pricing, the site recognizes you're the same person across sessions — your "fresh start" isn't fresh at all. Separate JustBrowser profiles each have their own identity parameters, cookies and storage, so each behaves as its own browser.
Is using a multi-account browser for academic research legal?
The browser itself is an ordinary tool; the legal questions are about what you collect and how. Collecting publicly accessible data without getting around access controls is the safer ground, but the answer depends on your jurisdiction, the site's terms and what you do with the data, so check with your institution's counsel. Follow your IRB's guidance, respect robots.txt, and avoid overwhelming servers.
How many browser profiles do I need for a statistically valid algorithm audit?
That depends on your methodology and the effect size you expect, so settle it in your study design and power analysis rather than by rule of thumb. The 7-day free trial (card required) is full access with unlimited profiles, so you can run a pilot before you commit; after the trial it's $9.99/month or $99.99/year, with no per-profile charge. Budget separately for proxies if you're simulating users in different locations, since JustBrowser doesn't include them.
How do I check that my research profiles are separate and consistent?
Each profile is its own browser with its own consistent identity parameters, set by native C++ engine patches rather than JavaScript overlays. Before collecting data, open each profile on a public fingerprint viewer such as BrowserLeaks and record what it reports, so your methodology appendix shows each profile had a distinct, stable configuration. Re-check periodically; we make no claim about how any particular site will treat a profile, and your study design should not depend on one.
Try JustBrowser
Native Chromium multi-account browser for teams — not extension-based. Real C++ engine patches at the canvas / WebGL / audio / font / screen layer, across 40+ identity parameters. Local REST API + CDP for Playwright, Puppeteer, Selenium. $9.99/month or $99.99/year. 7-day free trial, card required — cancel any time in the seven days and you are not charged. Unlimited profiles.
Get started → · How it differs from Multilogin / GoLogin / AdsPower
Ready to manage multiple accounts?
Seven days free, then $9.99/month — one plan, everything included.