--- title: "Agent journey analytics" description: "Agent journey analytics stitches one agent task across your website, docs, API, SDK, and MCP. The unit is the task, not the browser visit." canonical: "https://www.agentrail.co/blog/agent-journey-analytics" author: "Harsh Raj" published: "2026-10-17T00:00:00Z" last_updated: "2026-10-22T18:13:14.888Z" --- # Agent journey analytics Agent journey analytics stitches one agent task across your website, docs, API, SDK, and MCP. The unit is the task, not the browser visit. ![Bar chart icon in a rounded square on a warm brown blur](https://images.ctfassets.net/1htfyfnn1o5y/3xqa1llpzr12vVleG2MQvm/7148883abacdf888ed3a78e6ac9767a1/hero_image-5.png?w=1600&fm=webp&q=72) A docs pageview, an SDK fetch, a 401 from the API, and an MCP tool call can be one job. In four different tools they look like four unrelated events. The agent did not experience four visits. It experienced a task. Agent journey analytics is the practice of putting that task back into one record. The record crosses the website, the docs, the API, the SDK, and MCP. This page defines that record. It does not define every metric you might hang on it. > **Key Takeaways** > > Agent journey analytics is the analysis of one agent task across website, docs, API, SDK, and MCP. > > A web session is a visit held together by a cookie. An agent task often has no such cookie, and it does not persist like a returning customer. > > Person-level stitching, as in Adobe Customer Journey Analytics, joins events to a person. The join here is the task. > > The result of the journey is the [agent task completion rate](https://www.agentrail.co/blog/agent-task-completion-rate). The grouping that makes the journey possible is [agent fingerprinting](https://www.agentrail.co/blog/agent-fingerprinting). > > A useful record names the goal, the ordered steps, the surface of each step, where it broke, and the outcome. ## Agent journey analytics is the record of one task across surfaces Agent journey analytics is the reconstruction and analysis of a single agent task as it moves across a product’s public and programmable surfaces. The surfaces named here are the website, the docs, the API, the SDK, and MCP. A journey that never leaves one of them is still a journey. It is a short one. The case that breaks ordinary analytics is the task that touches several. The record is ordered. First the agent reads a quick start. Then it calls an endpoint that the quick start named. Then it retries with a token. The order is the experience. A bag of events from the same hour is not a journey, even when every event is real. [Anthropic’s December 2024 description of agents](https://www.anthropic.com/engineering/building-effective-agents) matches the shape of the record. An agent directs its own tool use and checks the environment after each step. Each check is a step you can place on a timeline if you share a task identity. Without that identity, you have logs. [Agent analytics](https://www.agentrail.co/blog/agent-analytics) is the category this record belongs to. Journey analytics is the part of that category concerned with the path, not with a single endpoint’s error rate. ## A web session is the wrong container Web analytics inherited a useful fiction. A browser keeps a cookie. Events that share the cookie, inside a timeout, are a session. Funnels, landing pages, and bounce rate sit on that fiction. For a person with one browser, it is often close enough. An agent task does not owe you a cookie. A docs host, an API host, and an MCP process do not automatically share storage. The client may be a script on one call and a hosted browser on the next. The timeout you set for human reading will either split a fast task into nothing or glue unrelated tasks together. [George and Choudhary](https://www.mdpi.com/2078-2489/17/5/453) argue the deeper break in a position paper published 8 May 2026 in *Information*. Conventional web analytics, they write, treats the human user as the unit, with preferences and patterns that last. LLM agents are instantiated for a task and dissolved when the task ends. Two agents from the same framework, minutes apart, can pursue unrelated goals and share no continuity you can recover. They call this identity discontinuity by design. Their paper presents no new traffic census. It is an argument about the unit. The argument is enough: a session built for a persistent person is the wrong box for a task that exists only while the goal exists. Do not rescue the session by stretching the timeout. You will merge neighbors that were never one task. Change the unit. ## Person-level stitching is a different join Customer-journey products already stitch. They stitch a different object. [Adobe Customer Journey Analytics](https://experienceleague.adobe.com/en/docs/analytics-platform/using/stitching/overview) describes identity stitching as a way to analyze several datasets on a common person ID. The page, last updated 28 September 2026, says stitching rekeys rows inside one dataset so a person ID is present on as many events as possible. It looks at authenticated and unauthenticated sessions to find that ID. If it cannot, the persistent ID stays. Combining datasets is a separate step: you align them in a connection because they already carry a person ID from the same namespace. That is cross-channel analysis for a person. A desktop ad click and a later call-center conversation can meet because both are about Bob. The feature is explicit that it does not, by itself, merge datasets, and that the identifier match is case-sensitive. An agent journey asks for a join Adobe’s stitching does not claim to do. The events may never carry a person ID, because the actor is not a logged-in customer of yours. The events may not even be about one person-shaped identity across the week. George and Choudhary’s point lands here. Techniques that rebuild a fragmented human can attach two task instantiations that were never the same actor. Use person stitching when the question is the human’s relationship with you over time. Use a task record when the question is what this agent was doing in this attempt. Many products need both. They are not substitutes. Reporting “journeys” from a person-ID graph will count returning humans and miss the agent that never authenticated. ## One task can cross five surfaces without a shared cookie The concrete pattern is ordinary once you look for it. An agent is told to integrate a product. It opens the marketing site or, more often, the docs. It copies an install line for the SDK. It requests the API and receives an auth error. It finds the token docs, creates a credential, and calls again. Somewhere in that sequence it may also call an MCP tool that wraps the same API. To the agent, this is one task. To your properties, it is a docs referrer, a package download, two API clients, and a tool name. Agentrail’s product description is written for that split. We reconstruct the task the agent was attempting across website, docs, APIs, SDKs, and MCPs, because those systems do not share the task. The description is the scope of the journey. It is not a measured conversion lift, and this article does not add one. Nothing in the pattern requires a trace header the agent was kind enough to forward. When a cooperating client does send a trace id, you should keep it. When it does not, the journey is still the object you wanted. Waiting for every agent to propagate W3C trace context will miss the traffic that never heard of your collector. The path itself, the choices and the retries, is [agent behavior](https://www.agentrail.co/blog/agent-behavior). Journey analytics is the record that makes that path one object you can count. ## The journey’s result is the task completion rate A path without an ending is a log. The ending is whether the task reached the outcome it required. That fraction is the [agent task completion rate](https://www.agentrail.co/blog/agent-task-completion-rate): completed tasks divided by started tasks. The journey is what makes “started” and “completed” refer to the same unit. If you score completion on the API alone, you will mark a task failed that actually finished in MCP, or the reverse. This page does not restate the inclusion rules. Partial credit, benchmark scores, and the difference between a transcript and an environment state live in that definition. What belongs here is the dependency. You compute the rate on journeys, not on raw hits. A journey with no outcome rule is a story. A rate with no journey is a guess about which hits were the task. Read them as a pair. The journey shows where the task broke. The rate says how often tasks of that kind finish. Fixing a step is justified when it moves the rate for the journeys that touched the step, not when it moves a blended pageview conversion. ## The journey exists only after requests are grouped Something has to decide that the docs fetch, the 401, and the MCP call are one task. That decision is [agent fingerprinting](https://www.agentrail.co/blog/agent-fingerprinting). Fingerprinting, in this sense, is grouping. It is not a score that says how human the client looked. The classes of signal used for the grouping are defined in that article. This one only needs the output: a set of requests that belong together, in time order, labeled as a task. Until the grouping exists, do not draw a journey by hand from a hunch about user-agent strings. You will join a crawler to a customer, or split one coding agent into five anonymous clients. The fingerprint article is also where the limit sits. There is no published accuracy rate for the grouping, and this page will not invent one. Treat a journey as a reconstruction with evidence, not as a courtroom identity. If a shared id is present and trustworthy, the grouping can be boring. Prefer the explicit id. Fingerprinting matters when the id is absent, rotated, or different on each host. That is the common case for an agent you do not operate. ## What a useful journey record contains A journey record should answer five questions, and then stop. What was the task? The goal as far as the steps reveal it, not a novel about motive. Which steps ran, in order? Which surface did each step hit: website, docs, API, SDK, or MCP? Where did the path break: an error, a retry loop, a missing page, an auth wall? What was the outcome against the rule you use for completion? Steps you cannot tie to the task stay out. A health check from the same IP during the same minute is not automatically a step. The fingerprint has to earn the attachment. A record that includes every coincident request becomes a session again, under a new name. The record is also the thing you can show a docs owner or an API owner without making them learn each other’s tools. The docs owner sees that the quick start was fetched immediately before a bad call. The API owner sees that the bad call used the parameter the quick start printed. Neither person had the whole task in their own product. We price the reconstruction by the journey, not by the seat. The public offer is 100 agent journeys per organization each month, then $0.10 per journey. Readiness scans and the recommendation list sit alongside that, and the current numbers are on [pricing](https://www.agentrail.co/pricing). The offer is a way to look at tasks you already have. It is not a claim about how many tasks the internet contains. [Agent analytics](https://www.agentrail.co/blog/agent-analytics) is where this fits: traffic tools show events, and the journey shows the task those events were part of. Start with one painful workflow. Require the five fields above. If the record cannot name the break, it is not a journey yet. It is a search result with extra steps. ## FAQs ### What is agent journey analytics? Agent journey analytics is the reconstruction of one agent task across your website, docs, API, SDK, and MCP, and the analysis of that reconstructed path. The unit is the task. ### How is an agent journey different from a web session? A web session groups events that share a browser cookie inside a timeout. An agent task often crosses hosts that do not share that cookie, and the actor may exist only for the goal. Stretching the session timeout does not create the task. ### Is this the same as Adobe’s identity stitching? No. Adobe Customer Journey Analytics rekeys events to a person ID so you can analyze channels for that person. An agent journey groups requests into one task. A person can send many tasks. A task may never carry a person ID. ### What should the journey be scored with? Score it with [agent task completion rate](https://www.agentrail.co/blog/agent-task-completion-rate): did this task reach the required outcome? Keep partial results as separate labels. Do not average them into the rate. ## Conclusion Agent journey analytics takes one task and keeps it intact across the website, the docs, the API, the SDK, and MCP. Sessions and person graphs answer other questions. They do not answer this one. Group the requests, name the outcome, and read the break. The grouping is [agent fingerprinting](https://www.agentrail.co/blog/agent-fingerprinting). The outcome is the [completion rate](https://www.agentrail.co/blog/agent-task-completion-rate). The category those records live in is [agent analytics](https://www.agentrail.co/blog/agent-analytics).