Price & SERP Monitoring: Multi-Accounting for Market Research
How to track competitor prices and search rankings across regions without skewed data, bans, or captchas, using isolated browser profiles.
Why monitoring prices is harder than it looks
The simplest way to check what a competitor sells and at what price is to open their site in a regular browser. That works fine until the task turns into regular monitoring — dozens of SKUs, several regions, daily rank checks. At that point, a regular browser starts handing you distorted data or blocks access outright.
Several reasons stack on top of each other:
- Personalization. Search engines and marketplaces tailor results and prices to browsing history, geolocation, and cookies from previous visits. If you searched for a similar product yesterday from a personal account, today's result is no longer what an ordinary shopper from another region sees.
- Geo-blocks and local pricing. Flights, subscriptions, SaaS plans, and marketplace items often cost differently depending on the exit IP's country. Without a proxy in the right location, you simply can't see the price a buyer in Germany or Brazil sees.
- Rate limiting and captchas. Sites track request frequency from a single IP and a single browser fingerprint. Ten checks in a row from one device, and you get a captcha, then a temporary IP ban, sometimes a session cookie ban too.
- Different user states. Price for a new visitor, a logged-in user, and a newsletter subscriber can differ by 10–30%. Seeing all three at once requires three different browser states, not one account with tab-switching.
An antidetect browser with a set of isolated profiles covers all four points with the same tool: each profile has its own fingerprint, its own proxy in the right location, its own cookie history — and none of them overlap.
What's legal and what isn't
Monitoring public prices and search rankings is standard practice for marketing teams, price aggregators, and SEO teams. It's not hacking and not bypassing a paid subscription — you're looking at the same page any visitor sees.
But legality has boundaries, and they're worth stating plainly:
- Check robots.txt and the site's terms of service. Some platforms explicitly prohibit automated data collection in their ToS. If a platform states that, large-scale automated scraping via scripts will violate platform rules, even if it isn't always legally pursued.
- Don't impersonate a real buyer where that's specifically prohibited — for example, if a platform requires registration with real data to access pricing (B2B price lists, closed catalogs). Creating dozens of fake accounts specifically to bypass that restriction isn't market research, it's a ToS violation.
- Use official APIs where they exist. Many marketplaces and ad platforms offer APIs for partners and analysts — faster and more reliable than scraping, and explicitly allowed.
- Don't overload a competitor's infrastructure. Even legal monitoring at dozens of requests per second from one address is effectively a load test on someone else's server. A reasonable request rate is good practice regardless of formal limits.
If a task is borderline — say, you need to see a price inside a closed B2B partner account — that's a conversation with your company's legal counsel, and there's no universal advice here.
How the profile scheme is structured
The working unit in this scheme isn't a single "competitive intelligence" profile — it's a pool of profiles organized along three axes: region, device, user status.
Region. Each profile gets a proxy exiting from the needed country or even city, through proxy selection tailored to the task — residential or mobile addresses for platforms with strict anti-bot protection, datacenter ones for simple public pages without captchas. Timezone, interface language, and browser geolocation are pulled from the proxy's IP automatically, so the site sees a consistent picture instead of a browser physically in New York with a Ukrainian locale.
Device. Some platforms show different prices and different results on mobile versus desktop versions of a site. A profile's fingerprint — OS, browser, screen resolution, GPU and font set — is configured separately for desktop and mobile scenarios without needing a physical fleet of phones.
User status. Three states, three profiles:
- "new visitor" — a clean profile with no history, showing the base price without loyalty discounts;
- "registered but never purchased" — a profile with warmed-up cookies and browsing history, but no orders;
- "repeat customer" — a profile with purchase history, subscriptions, saved loyalty cards.
Warming up the second and third scenarios requires a scheduled cookie run and browsing history — without it, a zero-history profile behaves like a bot and may get a stripped-down version of the page. The detailed mechanics of warming up are covered in the piece on warming up accounts before launch — the principles there apply just as well to analytical profiles, not only advertising accounts.
Example: monitoring prices for 40 SKUs across 5 countries
Take a hypothetical task: track prices daily for 40 products across three competitors in five countries, accounting for the fact that price can differ for new versus logged-in users.
| Parameter | Value |
|---|---|
| SKUs | 40 |
| Competitors | 3 |
| Countries | 5 |
| User scenarios | 2 (new / logged-in) |
| Checks per day | 1,200 (40 × 3 × 5 × 2) |
| Profiles in the pool | 10 (2 per country: new + logged-in) |
| Proxies | 10 (residential, per country) |
Ten profiles cover the entire matrix, provided you automate the SKU crawl inside each profile with a script instead of opening the browser manually 1,200 times a day. For that, profiles connect through a local API via Puppeteer or Playwright — the script logs in, sequentially opens product pages, captures the price, and closes the session. The details of that kind of automation are covered separately in the piece on automating profiles with Puppeteer and Playwright.
Request frequency inside a single profile stays at a reasonable level — a few seconds' pause between product pages instead of a parallel burst of requests. That's not only about courtesy; it's direct protection against captchas: a sudden spike in requests from one IP is the most common trigger for anti-bot systems, even with a flawless browser fingerprint.
SERP monitoring: a different logic
Tracking search engine rankings by region is a related but not identical task. What matters here isn't cookies and purchase history, but geo-binding and the absence of search personalization.
The rules differ slightly:
- a profile for SERP checks is kept "clean" — no search history, no login to a search engine account, otherwise results will adjust to past queries;
- each region gets its own profile with that country's proxy and matching timezone, because local results depend not only on IP but also on the browser's interface language;
- SERP profiles don't need a long warm-up history — on the contrary, the "younger" and more neutral a profile is, the closer its results are to what an anonymous user sees.
A similar geo-binding logic applies when checking ads by region — that scenario is covered in detail in the piece on geo-testing and ad verification, useful when the task goes beyond organic results and includes checking targeted ads.
Team workflow: who owns what
When monitoring is run by a team of three to five people rather than one analyst, the profile pool quickly turns into chaos unless the structure is set up in advance.
A working model for a team of 3–5 analysts:
- Owner/admin sets up the profile pool by region and assigns access — which analyst covers which countries or product categories, through roles and profile limits.
- Member gets access only to their own profiles — an analyst covering Europe can't see or accidentally break a colleague's profiles for Asia.
- When a check needs to be handed off to someone else during a vacation, the profile is transferred between teammates without resetting cookies or history, instead of being recreated from scratch.
- A manager can use live view to quickly confirm an analyst set up a profile correctly before launching regular monitoring, without asking for screenshots or interrupting someone's work.
- lev opened Airdrop zkSync 07
- artem closed FB · US · BM-14
- maya is watching artem
- lev transferred TikTok Shop 03
If a team runs dozens of profiles across different workstreams — not just price monitoring, but SEO analytics, ad verification, UX testing in parallel — it's worth planning a group and tag structure up front, so you're not hunting for the right profile among two hundred identical-looking ones three months later. The principles behind that kind of structure are covered in the piece on organizing large profile pools.
Common mistakes
Using the same proxy for every check. If five different product categories are checked from one IP, the site quickly sees an abnormal request pattern and either shows a captcha or just bans the address for a couple of hours — derailing the whole day's check.
Logging into a personal search engine or marketplace account during monitoring. Results get personalized instantly, and you end up with distorted data while thinking you're seeing the public picture.
Running all profiles in parallel from one device without resource limits. Ten simultaneous browser sessions is a noticeable load on CPU and network, and if the profiles are also running scripts at the same time, some requests may hang or time out — which later gets misread as "the site is down."
No logging of check time and IP. After a month, discrepancies pile up in the data, and without a record of which IP and what time a price was captured, it's hard to tell whether it was a site anomaly or a flaw in the monitoring setup itself.
Ignoring the platform's ToS. Even if scraping technically works without issues, it's worth understanding the risk level upfront — some platforms ban accounts and IP ranges for violating data collection rules, regardless of how clean the traffic looks.
Proxies: where not to cut corners
For public pages without aggressive anti-bot protection, datacenter proxies work fine and cost less. But platforms with serious protection — large marketplaces, flight booking systems, some search engines — distinguish a datacenter IP from ordinary residential internet fairly quickly, and either show a captcha or serve a stripped-down version of the page.
For those cases you need residential or mobile proxies — pricier, but they give a picture as close as possible to what a real shopper sees. The trade-offs in approach and cost are covered in detail in the piece on proxy types for different multi-accounting tasks — it also covers where you can save money and where cutting corners costs you a whole day of monitoring lost to bans.
Checking proxies before launch is a habit worth building: a dead proxy, or one already banned on the target site, silently ruins a full day's data if it isn't tested beforehand.
What you need to get started
A minimal setup for launching monitoring across 3–5 regions and a couple of competitors:
- an antidetect browser supporting the needed number of profiles — a small team can get by on a plan with a hundred profiles, with room to grow as regions and categories expand;
- proxies for each region — residential for complex platforms, datacenter for simple ones;
- a basic Puppeteer or Playwright script to automatically crawl product pages or search queries;
- a policy on request frequency and logging, so that a month in, you can tell a real price change from a monitoring glitch.
Estimating the cost of such a setup — profiles, proxies, analyst hours — is easier using the model from the piece on calculating a team's budget for profiles — the logic there applies just as well to regular work with a large number of profiles as it does to media buying.
If the task is still small — a couple of competitors, one or two regions — you can start on the free plan with three profiles and scale up as the check matrix grows.
FAQ
Is it legal to monitor competitor prices automatically? Yes, as long as you're looking at public pages without bypassing a login and not violating an explicit ban on automated data collection in a specific site's ToS. For closed sections (like B2B price lists behind registration), the rules differ — creating fake accounts specifically to bypass access isn't recommended.
How many profiles are actually needed to start? For one region and one scenario (new visitor), one or two profiles are enough. A matrix of five regions and two user scenarios needs roughly ten profiles — the number grows linearly from there with regions and scenarios.
Can I use a personal browser instead of an antidetect one? You can, but you'll quickly run into search personalization from your own browsing history, IP bans from regular checks, and the inability to hold several geos and scenarios at once without mixing up tabs and Chrome profiles.
Do all checks need residential proxies? No. For simple public pages without anti-bot protection, datacenter proxies work reliably and cost less. Residential proxies are needed where a platform aggressively filters traffic — large marketplaces, booking systems, some search engines.
How often should a profile's fingerprint be updated? If a profile hasn't been flagged and isn't getting captchas more often than usual, there's no need to change the fingerprint. Frequent rotation without cause tends to hurt more than help — the site sees a "new" user every time and may show incomplete results instead of a personalized history, which is sometimes the exact thing being studied.