How autopilot gathers evidence

Connect GA4, and Search Console if you use it, at organisation level, then save the journey’s evidence period and select Start autopilot. The evidence checkpoint explains what each source adds and what the report cannot measure without it. GA4 is required: every finding in a journey is ranked by it. The checkpoint also asks whether this website has heatmaps. If you answer yes, your agent adds Microsoft Clarity collection to the journey; if you answer no, the journey continues without it. There is no manual heatmap upload step. The server collects and saves the connected reports as the first resumable stage of the run.

1. Autopilot collects the GA4 report set for the exact saved period, including coverage and data-quality metadata.
2. When Search Console is connected, it collects web search plus image, video, Discover, Google News, and News evidence when Google returns rows, with page-and-query detail for detected search appearances.
3. Each source is saved as a durable task. A temporary API or network failure can be retried without repeating completed collection.
4. If the connection or property is wrong, correct it under Data Sources before starting a fresh run.

Search Console and Clarity are optional. Without them the journey continues and the report states which insights could not be calculated. Google can return only the top rows for large Search Console queries, so a report that reaches its row limit is marked as potentially incomplete. See Journey analyses for how each source is used in the report.

When the journey fieldwork finishes, UX Robot’s server measures the pages the journey actually reached, on the locked device, while your agent carries on. Core Web Vitals comes from the Chrome UX Report API: current URL and origin field data plus origin history, with the exact collection periods. Third-party pages, such as a payment provider at the end of a journey, are not measured. An unavailable CrUX snapshot means Google does not have enough eligible real-user data for that target and device. It is an evidence gap, not a passing result.

At the same step, when the brief names competitors, UX Robot reads each competitor’s whole-website real-visitor speed for the same device, so the report can compare it with yours, website with website. For every journey, it also reads from DataForSEO the searches its visitors make before they arrive, in the journey’s market: the searches the evidence plan says someone with the journey’s goal would type, kept only when Google shows monthly searches for them, the searches that bring people to the journey’s pages in your Search Console and, when the journey starts deeper than your home page, the searches that page ranks for. Each comes with its monthly volume and what advertisers bid, and Google’s results page is read for the first five: where your website ranks, who else ranks, who advertises, the questions Google suggests and whether an AI Overview appears. See Compare with competitors.

Accessibility problems are usability problems. A form field with no label, text that does not contrast with its background, or a link that reads only “click here” will stop some people completing a journey, and analytics can show you the drop-off without ever telling you the cause.

UX Robot runs automated Lighthouse accessibility, best-practice, and performance checks through PageSpeed Insights on the same reached pages. Results are grouped by problem rather than by page, with the pages and example elements affected. Google renders each page before scoring it, so the checks run in the background; a page that times out is tried again automatically, and one that still cannot be checked is marked as failed while the rest complete. When your team completes a step such as signing up or signing in, only the pages before it are measured, because Lighthouse cannot use your team’s session.

The same checks return performance diagnostics: which stylesheet or script blocked rendering and for how long, which images are larger than the space they fill, and how the largest content paint divides between server response, resource discovery, download and rendering. These are laboratory measurements from one rendered page load, not what your visitors experienced. The report has a dedicated Performance section that separates Core Web Vitals field status from Lighthouse laboratory coverage, including not collected, unavailable, failed and still-running checks. It draws each page’s Lighthouse score and timings on the good, needs improvement and poor bands Lighthouse uses for the device, and real-visitor figures on Google’s published thresholds. Every failing speed and best-practice diagnostic becomes an issue in the report’s fix list, with the files behind it, what fixing it saves and a severity from Lighthouse’s estimate, and is tracked like any other issue. Lighthouse performance diagnostics are supporting laboratory evidence and are labelled that way.

Your agent then checks every journey page against every WCAG 2.2 level A and AA success criterion in the browser, such as keyboard access, visible focus, contrast, zoom and narrow screens, labels and error messages, and records a result for each one on each page; see Every page is checked the same way. Each issue lists the pages it appears on and example elements such as input#email, so the work can be handed to a designer or engineer without them repeating the check.

At the evidence checkpoint, answer Yes — collect them from Microsoft Clarity when heatmaps are available. After the browser fieldwork establishes the journey’s URLs, your agent reviews relevant click, scroll, attention, error and recording evidence for those pages. It saves the page, device, date filters, sample context, observed pattern, and limitations instead of asking the engineer to upload heatmaps manually.

Recordings are read in groups that matter for the journey’s goal: sessions that completed the goal, visits from the page’s main traffic source that left without acting, and sessions that reached the goal’s step but did not finish it. For each group the agent asks Clarity to summarise the recordings, then treats every claim in that summary as a lead, not a finding: it opens at least two of the recordings the claim cites, reads their timelines and records whether the claim holds, naming the exact element, such as a heading visitors click although it is not a link. It records every session it reads: where the visit came from, how long it lasted, how far it got, what was clicked and where it ended. UX Robot counts the patterns from those records itself, so the report says “3 of 8 visits from Google Ads clicked the heading” instead of repeating an AI summary. At least five recordings are read for each page, or all of them when there are fewer, and UX Robot refuses recording evidence in any other form.

Clarity records UX Robot’s own test visits like anyone else’s, so the agent is given the times UX Robot’s agents had your website open during the evidence period in earlier runs, with the device and screen size. It leaves out any recording that starts at one of those times on the same kind of device, says how many it left out of each group, and does not count, summarise or cite them as visitors. When a claim in Clarity’s summary cites one of those test visits, the agent judges the claim from the other recordings it cites, and a claim that cites only test visits is marked not supported, because it says nothing about your visitors. Heatmaps and Clarity’s dashboard totals still include those visits, and the report says so as a limitation.

Bots and your own team’s testing are left out of the counts too. For every recording it reads, the agent says whether it was a person, a bot or crawler, such as a visit from a data centre that opens pages seconds apart without a click, or your team’s own testing, such as a visit to a test account’s pages, and why. Only people visiting your website are counted in What visitors did, and the report can say how many bots and team tests were left out of each group.

In the report, each stage shows What visitors did: up to four of these patterns, each with its count, who those visitors were and the priority that addresses it. When the journey is run again, the report compares the same group of visitors with the previous run, for example dead clicks on a heading falling from 3 of 8 to 0 of 9 after the fix shipped. A group is compared only when both runs read at least five of its recordings: a change between smaller samples, such as 2 of 2 to 0 of 12, means nothing. A change like that is consistent with the fix working; only a screenshot of the live page marks an issue fixed.

If Microsoft Clarity is signed out when that collection step begins, Autopilot saves its place and asks the engineer to sign in. If you answer that no heatmaps are available, UX Robot does not add a Clarity task or show Clarity instructions; the journey continues and the report explains the behavioural evidence limitation.

Browser inspection shows what the interface does; Clarity shows how observed visitors used it. The report keeps those evidence types separate and does not turn a small recording sample into a claim about the whole audience.

Each desktop task saves structured observations in bounded chunks. An observation records the URL, page area, device or viewport, action, expected and observed result, applicable UX principle, confidence, limitation, and a location screenshot. Every failed visual or interface observation must include a screenshot of the exact tested viewport and the affected element bounds so UX Robot can add the highlight deterministically. Highlighted finding images in the report remain the captured screenshot with that overlay rather than an AI-generated recreation.

The agent must not submit personal, authentication, payment, or confidential information. When a useful screenshot would contain sensitive content, show a signed-in third-party tool, describe an issue that cannot be shown in one viewport, or cannot be captured with the available browser, it must save the explicit reason, record the location in words, and leave the image out. The server rejects a failed observation that silently omits both the capture and the reason.

When the screenshot already exists as a local JPEG, PNG, or WebP file, the agent marks the capture as pending and checkpoints the observation. It then uploads the binary file through a short-lived one-use link by running the supplied command in its shell. This avoids copying large Base64 image data through the MCP conversation. UX Robot can verify the local SHA-256, confirms the stored checksum, and refuses to finish the task until every pending upload succeeds.

One observation records one interface state and one screenshot. A second state is saved as supplementary evidence rather than replacing the first. While fieldwork is active, your agent can also correct factual observation text; UX Robot retains the correction reason in the evidence history.