Use cases · Data teams

See what iPhone users see

Many sites serve mobile Safari a different site than desktop browsers: different layouts, different flows, different prices. For price monitoring and market research, you want the version iPhone users get.

The problem

The mobile web is a different web

Point a desktop collector at a mobile-first site and you get the desktop version: different prices, a different layout, sometimes a full-screen "please use our app" page instead of the content. Changing only the browser's name so it claims to be a phone is not enough either: the layout, fonts and rendering still come from a desktop engine, so what you record is not quite what iPhone users see.

Driftstack starts from Safari's engine instead. Every session runs a build of Apple's own WebKit — the engine family behind iPhone Safari — set up to present an iPhone model and its screen. So your collector records the mobile layout, the mobile flow and the mobile prices.

Why the data is right

The page iPhone users get

Websites choose which version of a page to serve from what the browser reports: its engine, its screen, its fonts. Driftstack's answers come from Safari's engine, so the page you collect is the page an iPhone visitor gets; they are checked against a real iPhone where we have one to test.

The mobile page itself

What a website measures to choose a page — engine, screen, fonts, graphics — comes from Safari's own engine and is checked against a real iPhone where we have one to test

Consistent from run to run

The fixed answers — screen, hardware, audio settings — stay fixed, and the ones Safari deliberately varies are varied the way a real iPhone varies them, so repeat collections compare like with like

The country you need

Each profile goes out through your own proxy or VPN (SOCKS5, or OpenVPN and WireGuard on paid plans), so you see that location's prices and offers; the session's time zone follows that country

Want the detail? The comparison page goes signal by signal: what a website measures, and what each side returns.

Which plan

Every plan includes the API and the SDKs

Collectors are written in code, and every paid plan runs them. Billing turns on one number: how many sessions run at the same time — think browser tabs. Paid plans have no hour limit (fair use). Run as many sessions as you like, up to your plan's number at the same time.

Your own code drives the sessions. We publish an SDK — a ready-made code library — for TypeScript, Python and Go. Any program that can make an HTTPS request can drive a session too. A session takes a short list of actions: navigate, interact, capture, extract.

The AI agent is on every paid plan on offer. Webhooks are messages Driftstack sends to your own system. They tell your job when a session hits a challenge or could not save its profile; an agent session (the kind that runs the AI agent or a list of steps) sends no completed or failed webhook, so your job reads the session's status to see that it ended.

See plans and prices →

Switching from a Chrome-based tool? The FAQ below covers what changes.

Collect responsibly. This page is about market research and price monitoring. Scraping that gets around logins (authentication) or past a site's reasonable rate limits is not allowed. The Acceptable Use Policy draws that line in plain words.

Questions data teams ask

Questions before you switch

Migrating from another vendor

Migrating from Browserless / Bright Data / ScrapingBee / Browserbase?

Plan to reshape your scripts, not swap a URL. Scripts built for them can't connect directly, so you rewrite each one as Driftstack actions. Anything tied to Chrome, like Chrome-only commands or page-styling quirks, needs changing. Step-by-step guides: from Browserless, from Puppeteer. Want a hand? Email [email protected] before you switch.

Can I run a side-by-side comparison before committing?

Yes. That is what the 7-day trial is for, and no card is needed to start it. Run sessions through Driftstack alongside your current vendor and compare the results on your own flows. Some teams subscribe after watching how their flows behave; some find their current setup already does what they need and stay where they are. Either outcome is fine: we would rather you make the right call.

Acceptable use

Is X allowed? (sneaker bots / scraping / ad fraud / etc.)

Legitimate automation, yes. Fraud, attacks, and anything unlawful, no — and scraping only within a site's own terms. Use it for testing, research, agency work and AI agents. Never for attacks, fraud, breaking into logins or past rate limits, or illegal content. Using our check handling to create accounts in bulk is not allowed (Acceptable Use Policy, Section 2, item 8). Abuse leads to a review under our Acceptable Use Policy; repeat abuse closes the account.

Is it allowed to use it for multi-account work?

Yes, to keep accounts apart, inside each service's own rules. Section 2.2 of our Acceptable Use Policy says: “Where Customer lacks authorisation from the target operator and the target operator's published terms prohibit programmatic account creation, Customer may not use the Service to create accounts at scale.” It adds: “"At scale" means more than the rate a single ordinary human user could plausibly create through the target's intended interfaces.” Using our check handling to create accounts in bulk is not allowed either (Section 2, item 8); read the whole Acceptable Use Policy before you start if you are unsure.

What happens if Driftstack as a business goes away?

Two protections. Data portability: Export your audit log as CSV or JSON, and each profile's settings as JSON through the API, any time. Self-hosted option: Self-Hosted Enterprise contracts include source escrow, set up with your contract. How self-hosting works.

Everything else is on the full FAQ.

Ready when you are

Collect the web your users see

Start a free trial next to your current vendor, and compare what each one collects on your own pages. No card needed.

Start free trial See pricing