Primary topic Mobile Publishing and Monetization
Automated tracker audits can give sharply different answers about the same webpage. In a preprint posted November 4, 2026, researchers found that two AI-directed browsing agents recorded roughly 1.5 to 1.7 times as many tracker organizations as conventional crawls visiting the same URLs. But the agents also recorded substantial activity absent from a small sample of human visits.
For a mobile publisher, that makes the audit’s itinerary part of the result. A scan that opens a homepage, leaves the consent banner untouched, and stops cannot describe what happens after a reader accepts, rejects, or continues to another article. Equally, an agent that clears every obstacle and keeps exploring may produce an extensive inventory without accurately representing an ordinary visit.
The study, Beyond the Landing Page: Website Blocking, Tracker Visibility, and Human Alignment in Automated Web Crawls, offers evidence for checking those differences. It does not report a dedicated smartphone benchmark: its numerical results should not be presented as measurements of iPhone, Android, or mobile publishing traffic.
What “the same page” actually controlled
The researchers, affiliated with the University of Texas at San Antonio and Google, assembled a corpus of 2,000 sites from the Tranco and Chrome UX Report rankings. They compared four conventional crawler configurations with two agents, browser-use and their research system SuperScraper. Both agents used the same Qwen3-VL-8B model. Collection ran from July through October 2026, with each main configuration aiming to visit up to ten pages per site.
Because independent crawlers can choose different links, the team added a more revealing comparison: a conventional Chromium crawler revisited the URLs each agent had reached. In the paper’s matched-page analysis, browser-use recorded an average of 6.00 tracker organizations per page, against 4.01 for its conventional counterpart, across 11,435 matched pages. SuperScraper recorded 7.24 against 4.29 across 3,759 matched internal pages. Those produce the reported ratios of 1.50 and 1.69.
The unit matters. A tracker organization was an owner of third-party domains observed in captured responses and classified through DuckDuckGo’s Tracker Radar as advertising, analytics, session replay, or social tracking. Several domains belonging to one organization could count once on a page; that organization could count again on another page. These are ratios of summed page-level organization counts, not numbers of cookies, requests, or globally unique companies.
Both visits needed network capture to qualify. SuperScraper’s landing pages were excluded because its network recording failed extensively there. The two agents’ figures also come from different page sets, so 7.24 versus 6.00 is not a direct ranking of their effectiveness.
Most significantly, each conventional revisit began as a separate one-page task in a fresh browser context. Matching the URL did not match the visit. Previous navigation, saved consent, interactions, and observation duration could differ. The result shows that visiting identical addresses does not guarantee identical tracking observations; it does not isolate an AI model’s contribution while holding everything else constant.
A banner click can change what the audit sees next
The agents were instructed to dismiss obstructing overlays. A separate interaction-recording crawl shows why that seemingly practical instruction needs scrutiny. Of 445 sites with usable logs, 140 produced 273 consent-related clicks. These included 201 explicit accept actions, 47 weaker acceptance signals such as “OK,” 23 openings of settings, one rejection, and one unclassified action.
Those are actions by a particular agent following a particular task. They are not counts of consenting people or evidence that all browsing agents make the same choices. They do show how a crawler’s effort to get through a site can select a consent state that a passive scan never reaches.
The interaction analysis then examined what loaded after a confirmed consent change. On the 69 sites where the researchers could compare confirmed consent clicks with ordinary page-loading clicks, consent actions were followed by a mean of 9.2 newly observed third-party script domains within ten seconds, versus 1.0 after ordinary page-loading clicks. These were averages of site-level means, not an average across all 445 sites, and the unit here was script domains rather than tracker organizations. Windows interrupted by another click were excluded.
The largest increases appeared when a consent action was followed by a reload or navigation. That gives publishers a specific reason to continue the recording after the banner disappears: the next page may be where the changed state becomes most visible.
This was not a controlled accept-versus-reject experiment. The human participants’ consent decisions were not recorded, and the paper does not establish that consent explains the entire gap between agents and people. The defensible conclusion is narrower: an audit’s consent behavior can materially change its observations and needs to be recorded explicitly.
Finding more trackers and resembling readers are different goals
The human reference consisted of 26 adults whose logs contained 4,353 pages across 415 sites. Their assignments came from a selected 450-site subset suitable for measurement, rather than a representative sample of the web; the logs also included sites reached beyond those assignments. Participants used Chrome with initially cleared browsing data and a measurement extension. The authors describe the pooled observations as a reference for comparison, not an estimate of population-wide browsing behavior.
The comparison with participants asks two questions with different denominators:
- How much of the participants’ observed activity did the crawler recover? Browser-use recovered 82% and SuperScraper 87%, compared with 58–68% for conventional configurations. This is recall: the denominator is participant-observed page–organization pairs on eligible shared URLs.
- How much of the crawler’s own activity also appeared in the participant visits? Only 48–49% of the agents’ observations overlapped, compared with 65–70% for conventional configurations. This is precision relative to that reference: the denominator is the crawler’s page–organization observations.
Neither percentage uses 2,000 sites or 26 people as its denominator. Each comparison includes only shared URLs with network capture on both sides; SuperScraper’s comparison includes internal pages only. An organization observed on two pages contributes a page-level observation on each.
The agents therefore recovered more of what participants encountered while also recording many additional observations. Calling the additional half “false positives” would be misleading. The activity may have occurred during the automated visits; it simply did not appear in the corresponding participant observations. Different actions and timing can produce a real difference in exposure.
Timing was consequential. When the researchers cut each agent’s recording to the corresponding participant’s observation span, browser-use’s organization-count ratio against participants fell from 1.71 to 0.95; SuperScraper’s fell from 1.76 to 1.28. The browser-use excess was no longer evident under that restriction. Those spans measured time from page start to the last recorded event, not precise reading time. Nevertheless, the analysis shows why a long exploratory visit cannot automatically stand in for a shorter reader visit.
For publishers, a broad inventory answers which organizations can appear under the tested conditions. Estimating what readers typically encounter additionally requires evidence about their actual paths, consent choices, browsers, and visit durations. Increasing the inventory alone does not supply that evidence.
A quiet result may also be an incomplete visit
Homepage checks can conceal a second problem: whether the crawler successfully continues through the site. In the study’s Chromium configuration, among 879 sites with at least six recorded pages, the denial rate was 0.2% on landing pages and 10.4% on pages two through six. These figures concern that restricted cohort, not every site in the 2,000-site corpus. The denial analysis counted matching first-party HTTP 403 or 429 responses, so it did not capture every possible form of blocking.
Improving access did not automatically increase observed tracking. A separate change to the automation framework reduced denials without raising tracker counts. Reaching the page, recording it correctly, and representing a reader’s visit are separate checks.
A publisher should therefore mark a blocked page or failed capture as incomplete rather than count it as a clean page with zero trackers. Verify that the expected document appeared and that recording began before its requests. SuperScraper’s missing first-page network data illustrates how a collection failure can otherwise look like absence of activity.
The research also leaves room for variation outside its setup. Non-proxy crawls originated from one U.S. vantage point, collection was spread across months, and Firefox’s tracking protections were disabled for comparability. These conditions limit what the numbers say about ordinary browser defaults or other regions. There is no mobile multiplier to apply to a publisher’s traffic.
How to compare equivalent mobile visits
The following is a proposed publisher workflow informed by the findings, not a mobile experiment reported in the paper. Its purpose is to make each observation answer a specific question: what happened before a choice, after that choice, and on the next page carrying it forward?
Start with the actual entry and browser
Choose an exact entry URL and a specific link to follow next. Include a directly opened article if that is a route readers use; a homepage-only test cannot establish its behavior. Keep the device, browser and OS versions, region, login status, privacy settings, and observation windows fixed within each comparison. Record the consent-platform configuration or deployment version so a later repeat has a meaningful reference.
Test the mobile browser itself. Chrome provides remote inspection of pages running on Android devices, while WebKit documents inspection of iPhone Safari from a connected Mac. Desktop device emulation is useful preparation, but Chrome’s own Device Mode documentation describes it as an approximation. A narrow desktop window does not establish what the phone’s browser will send.
Give each consent choice its own fresh start
Run three independent visits from the same defined starting state: leave the banner untouched, explicitly accept, and explicitly reject using the available controls. Capture the initial period before any action in each run. If rejection requires opening settings, record that path and its timing rather than treating the menu opening as the rejection itself.
For automated checks, isolated browser contexts keep cookies and local and session storage separate. On actual devices, verify the starting state with a dedicated test setup. Keep ordinary and private browsing as distinct conditions. A fresh context provides repeatability; it does not reproduce a returning subscriber with an established consent record.
After the choice, follow the same next-page link while retaining that visit’s storage and consent state. Follow it in the untouched-banner control too, if the interface permits. Do not reset between pages within a journey. Conversely, accepting and then rejecting in one session tests a change of mind, not two equivalent first visits; check withdrawal separately if needed.
Record the transition, not just the banner’s disappearance
Start network recording before the entry load and keep it running through the choice and navigation. Chrome’s Network panel reference documents Preserve log for retaining requests across page loads and initiator information for tracing the code behind a request. Mark action times, use the same observation windows, and record any reload.
Verify the underlying consent update as well as the visible interface. For sites using Google tags, Tag Assistant’s consent checks expose defaults, updates, and tag behavior. Google’s implementation guidance specifically calls for consent updates on the page where the choice occurs, before a page transition. That makes the next-page check a test of whether the decision was carried forward.
Compare destinations and their owners, request parameters, initiating scripts, consent signals, and storage changes separately. A cookie inventory alone is insufficient. In Google’s documented basic and advanced consent modes, basic mode holds Google tags back until consent, while advanced mode can send cookieless pings when consent is denied. That is a concrete reason to inspect outbound requests even when no new analytics cookie appears; it does not describe every vendor’s behavior. An unchanged organization count can still conceal a change in the information being sent.
Save enough evidence to reproduce a discrepancy. Chrome’s default sanitized HAR export omits headers including Cookie, Set-Cookie, and Authorization, so the exported request log alone cannot establish all cookie behavior. Record the relevant storage observations during the test.
Make the result explainable
Repeat the same journeys and note which observations recur. Compare accept with reject within the same browser and region before comparing browsers or regions. Keep a returning-reader test separate from the clean-start runs, and label blocked pages, missing captures, unavailable controls, or failed consent updates explicitly.
A useful finding identifies the exact entry URL, choice, next-page transition, browser environment, and request or storage change that needs investigation. If behavior differs from the site’s configured consent policy, that evidence gives the responsible team a reproducible problem. If extra organizations appear only during a deliberately broad exploratory crawl, report the conditions that activated them before drawing conclusions about readers.
The November preprint gives publishers a reason to demand that context from an audit. A tracker count becomes useful when the team can explain which visit produced it—and can repeat that visit on the mobile browsers its readers actually use.