Journey analyses

Every analysis is a Journey analysis for one website. UX Robot follows one complete visitor task from the supplied starting page to a safe stopping point, stage by stage, then reports useful patterns, friction, public performance, accessibility, and the changes to make first. Every finding is ranked by your connected GA4 evidence, so the report tells you which problems cost the most visits, not only which ones exist.

The journey is a controlled expert test of one task, not a whole-site score and not user research. Connected sources deepen that one task and say what the evidence shows about the website around it, such as who the traffic is and whether the measurement can be trusted. It does not become a whole-site analytics report.

1. Open the organisation, select Projects, then create or open the project that should hold the analysis.
2. Select New analysis to open Set up journey analysis.
3. Enter the website’s official public name and the exact Starting page. To test a page before it ships, turn on This page isn’t live yet and see Check a page before it ships.
4. Not sure which journey to test? Select Suggest journeys from GA4. It lists busy entry pages where fewer visits reach a key event than across your website, ranked by how many key events they miss at the website’s own rate, and the key events your visitors complete most. Select Start here to use one as the starting page. The visitor’s goal and what success means stay for you to write.
5. Define the visitor with As a…, their goal with I want to…, and the expected value with So that…. Add an optional starting context and a concrete Success means… criterion. If the criterion depends on something UX Robot never does, such as creating an account, paying, or filling in every field when the form asks for a password, a warning under the field suggests describing what the visitor should see just before that step. The warning never stops you saving.
6. Add a Safe stopping point, such as “Stop before payment or placing an order.”
7. Set the access market or location, device, viewport width, viewport height, and whether the journey requires an engineer-authorised signed-in session.
8. Choose a completed Connected evidence period. A website journey always uses connected GA4. If GA4 is not connected yet, the form shows Connect GA4 before starting this journey; you can still save the brief.
9. Optionally select Suggest from GA4 to see the device and market most of your visits use, then select Use beside a suggestion to apply it.
10. Select Save journey analysis, check the controlled brief, then start autopilot. The normal evidence checkpoint shows whether GA4 and Search Console are connected and asks whether Microsoft Clarity is available.

The structured user story gives every stage the same actor, goal, expected value and definition of success. Write the goal as an outcome rather than a prescribed click path: “As a first-time customer, I want to find an adult men’s running shoe, choose a size and continue towards checkout so that I can buy the right product confidently” reveals how the interface works, while “open the navigation, select Men, then click Running” hides it. The journey brief locks when autopilot starts; finish or cancel the active run before editing it.

A new or changed page has no evidence of its own yet, but the website around it does. Turn on This page isn’t live yet to test the page on a local or staging copy and judge it against the evidence from the live website.

1. Enter the Test address where the journey begins on the copy. A localhost address works because the desktop agent opens it on the engineer’s computer. If staging needs a login, sign in to it in that browser first.
2. Enter Where it will live: the page’s address on the live website once it ships.
3. Enter The live page it’s most like: the page it replaces, or the live page most like it. Select Suggest from GA4 to see the live pages whose addresses are most like the new one.
4. Choose How visitors will arrive, such as social media posts, search or email. GA4 suggests the channels most visits come from.

The desktop agent tests the copy as a visitor from that channel would, records which GA4 tag the copy loads and compares it with the live page’s, and runs Lighthouse on the engineer’s computer because Google cannot reach a test address. UX Robot’s server measures the comparable live page instead. The report says how visitors like these behave on the live page today, flags a test copy that sends visits into your live GA4 property, and adds Measure after launch: the figures the new page needs to beat once it has a few weeks of visits.

Once the page has shipped and has a few weeks of visits, open the approved pre-launch analysis and select Check after launch. UX Robot sets up the same journey on the live address, measured against that report’s launch baseline, with an evidence period of the last 28 completed days. Adjust the period so it starts after launch, then start autopilot. The new report compares each baseline figure with the same figure for the live page, from the same reports and arrival channel, and says whether the page beat, matched or missed it. A figure that cannot be compared fairly, for example because the live page has too few visits, is marked as not comparable rather than compared with an unlike figure. The baseline described the live page the new one was most like, so a different result can reflect a different audience as well as the page.

If GA4 is not connected, the checkpoint shows Connect GA4 to start this journey and autopilot cannot start until it is. Search Console and Clarity stay optional: without Search Console the checkpoint says so and the report names what it would have added. Optional technical, Search Console, or Clarity gaps remain report limitations when the required browser journey is complete. A journey saved for browser testing only before every journey needed GA4 keeps working as it was.

Each source has a different job. GA4 adds population-scale traffic, engagement, event, and outcome context; Search Console adds pre-arrival organic demand and intent; Clarity adds sampled click, scroll, attention, recording, and error behaviour; browser testing explains the interface mechanism directly. UX Robot matches URLs, dates, devices, and geography before combining signals, does not let analytics add journey stages, and does not claim exact step drop-off unless a dedicated ordered funnel was supplied. Search Console describes searches on Google before arrival; it is not evidence of what visitors typed into the website’s own search.

UX Robot also reads every row of those reports, not only the rows that stand out, to find the journey’s own pages and to answer three questions about the website as a whole. How much of the traffic reaches the journey’s pages, and what is the rest of it for? Does the GA4 property also record visits from localhost or another domain, or key events with no landing page? How much of the audience comes from the saved market? These become findings in their own right, for example that most visits land on a different kind of page or that conversion figures include test traffic. They never stand in for what was observed at a journey stage.

Turn on This journey requires sign-in when the journey needs a browser session that is already authenticated. Before desktop testing begins, open the website in the same browser profile the desktop agent will control, sign in yourself, and leave the first protected page available.

The desktop agent never requests, receives, stores, or enters credentials. Do not paste a password, recovery code, one-time code, payment detail, authentication secret, or confidential account information into UX Robot, the journey brief, or the desktop instruction.

If a session is missing or expires, the agent saves the current task, observations, and next step in a checkpoint with waiting_for: target_site_login and asks the engineer to sign in. After the engineer confirms that the protected page is open, the agent reclaims the same task and resumes from the checkpoint instead of repeating completed work.

Select Start autopilot. UX Robot first collects current-run GA4 and Search Console reports where connected, then turns relevant patterns into investigation questions for the locked journey. When Desktop step ready appears, open the desktop handoff, connect the trusted desktop AI if needed, and copy the run instruction.

The Starting page is an entry point, not a page boundary: the desktop agent assesses both the website’s primary navigation and its own on-site search from that same entry point. The first successful route does not end fieldwork. Each route is tested when available, while a missing search feature or navigation path that is unavailable for the task is recorded explicitly instead of being invented. A present search that returns irrelevant, outdated, or empty results is an available but unsuccessful route, not an absent feature. Google or another external search engine is not substituted for missing on-site search unless the saved brief explicitly permits it.

The agent also opens each prominent call to action on the starting page once, such as a demo, tour, pricing or example page, and records whether it delivers what its label promises, even when the task never needs it. After assessing both discovery routes, the agent follows relevant safe links, search results, forms, and other same-site steps needed to attempt the saved success criterion. Candidate or priority URLs from connected evidence are investigation leads rather than a navigation allowlist. When both routes converge on the same downstream page, the report keeps the navigation and search paths distinct but does not duplicate the shared destination evidence. When the website delegates a necessary final step to a task-relevant external destination, the agent may open that link only to confirm the handoff and reached URL, then stops without auditing the third party or entering personal, authentication or payment information.

The desktop run completes and documents the journey stage by stage, checks practical accessibility, optionally reviews Microsoft Clarity after the actual journey URLs are known, and completes an expert review against the Nielsen usability heuristics. It works as a usability evaluator and evidence collector from the intended visitor’s perspective and saves a checkpoint after each coherent chunk. This is expert evaluation, not user research: the agent does not claim what real users think, feel or do at population scale. If the desktop closes or work is interrupted, copy the same run instruction again: the next claim includes the saved observations and next step.

Page speed is measured by UX Robot’s server, not the desktop agent. When the fieldwork finishes, UX Robot reads Chrome UX Report field data and runs PageSpeed Insights Lighthouse checks through Google’s official APIs, for the pages the journey actually reached and on the locked device. It runs while the desktop agent carries on with the remaining tasks, so nothing waits for it. Third-party pages, such as a payment provider at the end of a journey, are not measured. On a signed-in journey only field data is collected, because Lighthouse cannot use your session. If no Google API key is configured, the desktop agent collects the performance evidence instead.

Completed journey fieldwork needs an evidence-backed route assessment that records both navigation and on-site search, followed by an evidence-backed journey completion record. That record identifies which saved observations prove the success criterion, safe stopping point, or an evidence-backed site dead end was reached, and the exact final URL. A site dead end means the tested path and every relevant safe route provided by the website were inspected, but the website did not provide the route, information, or handoff needed for the goal. That is a reportable negative journey outcome rather than failed fieldwork: UX Robot continues to the remaining technical, Clarity, and expert-review tasks, and the missing path becomes a primary report finding. A journey can also genuinely finish on its starting page—for example, an on-page calculator, configurator, or proven dead end—but the agent must explain how the evidence proves that single-page outcome.

The task is submitted as blocked only when access, screenshot capture, authorisation, safety, or another evidence-collection limitation prevents UX Robot from determining the website outcome. Required fieldwork blocked for one of those reasons stops before report synthesis and does not reserve an analysis unit. The project then shows Journey fieldwork needs attention and Retry journey fieldwork after the limitation is resolved. An evidence-backed site dead end follows normal report accounting: one unit is reserved when synthesis starts and consumed only after a valid report is stored.

Screenshots show useful patterns as well as problems. Every visible interface failure needs the exact viewport and affected element bounds, and the agent captures a safe representative screenshot for each meaningful journey stage, without collecting repetitive images merely to fill the report. browser_capture_unavailable is a retry checkpoint, not routine completion: when screenshot capability is expected, the agent retries the capture, and if it still cannot collect safe visual evidence it submits the fieldwork as blocked so the run shows that it needs attention.

When the desktop agent already has a JPEG, PNG, or WebP file, it marks the capture as pending and checkpoints the observation. UX Robot returns the observation ID, then the agent asks for a short-lived one-use link and runs the supplied binary upload command in its shell. The image is never copied through the MCP conversation as Base64. When a checksum is supplied, UX Robot rejects different bytes and confirms the stored SHA-256 after upload. The 15-minute link begins when it is prepared, is scoped to that observation, contains no connection token, and expires automatically. The task cannot finish while an upload is pending.

Each distinct interface state gets its own observation and screenshot. If later checking shows that saved wording is factually wrong, or another state such as an expanded panel is useful, the agent can amend the evidence while fieldwork is still active. Corrections retain their reason, and a second screenshot is added as supplementary evidence rather than replacing the first. A completed or blocked historical task does not need to be reopened to attach that pending supplementary screenshot. When one viewport cannot show both sides of a visual issue, the agent creates a labelled pair instead of omitting the evidence.

When the report is ready, select Read report to open the dedicated full-width editorial view. It opens with a 30-second assessment, conditionally explains the connected evidence behind the journey, then presents an Evidence-informed expert journey map before the detailed stages, public performance, accessibility, and a short implementation-ready list using What, Where, Why, and Measure. The map keeps the locked story visible and shows each objective, observed action, touchpoint, status, selected screenshot, opportunity and expert-inferred likely question over time. Likely questions are labelled as expert inference, not participant research.

The final synthesis agent acts as the lead UX analyst and report editor. It triangulates screenshots, direct observations, technical checks and connected GA4, Search Console and Clarity evidence, keeps measured, directly observed, visual and expert-inferred claims distinct, and does not turn correlation into causation. Where the evidence supports it, a stage also shows observed behaviour or intent, and a priority adds impact, confidence, and a measurable baseline. Empty analytics sections are not shown. The report leads with the most consequential finding and states what the evidence cannot show once, in its limitations, rather than on every recommendation.

Every priority is labelled Measured when your evidence shows its impact, or Observed only when it was seen in the browser with no evidence signal. Measured priorities come first, but a broken control or an accessibility blocker stays near the top even without data. The ten Nielsen heuristics remain part of the expert evaluation, but relevant principles and strengths appear inside the journey stages instead of in a detached checklist.

The section navigation remains available while reading. Drafts show when the report was Generated; an approved publication date is shown as Published. The test brief labels its regional setting as Test context: Accessed from …. Performance labels distinguish field evidence from a single lab run and show whether the evidence covers an exact URL, URL scope, or origin fallback. A recommendation may repeat a screenshot already shown in its stage, so the priority stays understandable where it appears.

Visual evidence is required. A draft with no finding-specific screenshots, or with uncovered report stages, remains in Needs visual evidence and cannot be approved. If a finding-specific screenshot genuinely fails but a generic page-experience image exists, the report may show it in a clearly labelled Page context block for orientation. It is not proof of the interaction finding and does not make an otherwise incomplete report ready for approval.

When a priority recommends a visible change, the report can show it on your own page, and it can offer two versions, A and B, for you to test against each other. A version is either a wording change, such as a headline, button label, form label, help text or error message, or a layout change that only moves, restyles, hides or reorders elements already on the page. After the report is written, the analysis shows Make the after pictures. Copy the same run instruction into the desktop agent. For up to three priorities, the agent opens the captured page at the locked viewport, takes a before screenshot, makes only the recommended change in its own browser tab, and takes an after screenshot, once for each version. Nothing on your website changes, and the agent never submits a form. The agent’s browser must be allowed to change pages in its own tab: in Codex, turn on Chrome DevTools Protocol (CDP) access; in Claude, connect Claude in Chrome. If it is not, the agent pauses, and the analysis shows Let the desktop agent change pages in its browser until you allow it and tell the agent to continue. New words must come from the evidence: words already on your website, a Search Console query, the journey’s user story, or a short plain label for a control. UX Robot never adds prices, dates, ratings or other facts nobody supplied. A layout change may set only size, colour, weight and spacing, and never adds or rewrites text, images, links or elements. The pictures go to the changes that matter most, such as a headline, the main button or the offer, starting with priorities your evidence measured. A change too small to alter what a visitor understands, such as adding “(required)” or changing capitals, gets no picture.

UX Robot then checks each picture. A wording picture appears beside its priority only when nothing outside the marked areas changed and the page shows exactly the recommended wording. Moving one element shifts much of a page, so a layout picture cannot be checked that way. Instead UX Robot checks the agent’s log of every step: that each was the planned kind of step on an element measured on the page, that its script added or rewrote nothing, and that the screenshots show the same view visibly changed. It is labelled a Layout illustration. A picture that fails its check is left out with a reason, and the priority keeps its written recommendation and evidence screenshot. After pictures are made only for pages on the tested website, never for a third-party payment or booking page. Approve the report once the pictures are in, or select Skip after pictures to approve it with its written recommendations only. Until you approve, Try the after pictures again reruns the step for the changes that have no picture, such as one that was left out or a step you skipped; the pictures already in the report stay.

When a priority has two versions, the report shows them together as Variant A and Variant B, followed by Test A against B: show half your visitors each version and compare the priority’s measure in GA4. The report does not say which will win; the test does.

When the draft is accurate and useful, approve it as the locked point-in-time report. Approval also prepares the stakeholder summary you can review and email. Use Download PDF or Copy for AI under the same review and data-sharing rules as other UX Robot reports; see Generate, review, and share reports.

Edit the brief before autopilot starts when a URL, task, stopping point, market, device, viewport, or sign-in requirement is wrong. Do not change the brief while fieldwork is underway: the journey must keep the same conditions for the evidence to stay consistent.

If a run is interrupted, use the existing desktop handoff and resume from its checkpoint. If the website becomes unavailable, protected access cannot be restored, or bot protection prevents a fair test, record that limitation rather than inventing or substituting evidence.

Create a new analysis in the same project when you need to rerun the journey after a redesign, a fix, or a materially different brief. This preserves the earlier approved report instead of overwriting the historical result. Record the exact URLs and conditions used for every run: changed content, inventory, personalisation, authentication state, experiments, and third-party services may explain a different result.