You open the analytics dashboard and the story is tidy. Sessions, pageviews, users, a funnel that ends in signup. The numbers add up. They add up because they were designed for each other.
I compared that dashboard to our API gateway the same morning. Unique users said 1,400. The gateway had 48,000 requests from a short list of prefixes. I did not need a new category to see the mismatch. I needed a unit that could survive it.
Human analytics is still good at humans. It was never built for a caller that does not keep a cookie, does not render a page, and does not convert through a form.
The dashboard is internally consistent
That is the trap. Bounce rate, session duration, and unique users will reconcile with each other. The model is closed. If something does not emit the events the model expects, it drops out of the story without breaking the story.
You can stare at a healthy funnel while a second population uses the product through docs fetches and API calls. The funnel does not go red. It just fails to include them.
When people say the tools are "wrong," they usually mean this: the tools are right about the population they can see. That population is no longer the only one doing the work.
Sessions, pageviews, and users each assume a person
Read the metrics the way you read a schema.
A session assumes continuity. Someone arrived, stuck around, and the cookie held the thread. Agents do not owe you that. A job can be twenty requests with no shared session id, or one request that never executed your JavaScript. Without continuity, session analysis is a pile of short visits and empty rows.
A pageview assumes rendering. The tag fires because a browser painted a document. Headless fetches, spec downloads, and tool calls do not paint. You can have real use and a flat pageview line, or pageviews from humans rereading a guide while failed jobs never loaded a page.
A user assumes one person behind one identifier. Cookies, device ids, logged-in accounts. Pooled infrastructure breaks that. Many agents share egress. One operator can fan out many clients. Unique users then undercount, overcount, or both. The number still looks like a headcount. It is not.
Human assumption | What analytics does | Why it breaks |
|---|---|---|
The user has a browser | Cookies and JavaScript tags | Many callers never execute the tag |
A visit is a continuous sitting | Groups events by session id | A job arrives as disconnected requests |
One cookie is one person | Counts unique users | Shared gateways and rotation scramble identity |
Progress is a path of pages | Builds funnels from pageviews | The work happens on APIs and tools |
Conversion is a form or checkout | Fires signup events | The caller never submits a form |
The table is a list of load-bearing assumptions, not a reason to delete Mixpanel. When the caller violates them, the metric does not get slightly noisier. It stops answering the question you think you asked.
What those metrics still answer
Keep them for the humans.
Sessions still tell you whether the marketing site is doing the job you hired it for. Pageviews still tell you which documents people reread. Users still tell you, roughly, how many people came back with a browser. Signup still tells you how the human funnel converts.
Use them as scoped instruments. "Recorded browser attention on tagged properties" is true. "Demand" is not a synonym. The demand argument lives in why traffic is a broken proxy.
The upgrade is a second unit next to the first, not a bot filter you hope will reveal intent.
Agent Task Completion Rate
Agent Task Completion Rate (ATCR) is completed production agent tasks divided by production agent tasks started.
That is the whole formula. The work is in the nouns.
A task is a job with a defined outcome, not a request and not a session. "Create a sandbox key and list projects" is a task. "Hit /projects three times" is not. "Read the quickstart" is not, unless reading was the job, which it rarely is.
ATCR is a production metric. It is not an eval pass rate from a lab script, and it is not a confidence score on a reconstruction. Do not average those into a readiness number.
What counts as started
A task starts when evidence shows a concrete job entering an observable product path. The agent is not merely present. It is attempting something you can name.
Examples that qualify: an authenticated sequence aimed at creating a resource; a docs-to-API path that follows a published quickstart; a tool call that maps to a known capability.
Examples that do not: a changelog scrape; a health probe; a burst you cannot attach to an outcome. Presence is not a start. If you cannot name the job, leave it out of the denominator.
You will undercount starts at first. That is better than stuffing every unfamiliar prefix into the chart.
What counts as completed, blocked, or unresolved
Completed: the defined production outcome was observed. The meter exists and the test event incremented the invoice. The webhook acknowledged a signed payload. Pick the outcome in advance. Do not invent it after you like the number.
Blocked: the task reached a barrier and did not complete. Auth that cannot proceed. A 400 the caller cannot correct from the error body. A required human step. Blocked is a result.
Unresolved: the evidence cannot support a reliable classification. The trail went cold. Keep unresolved visible. Do not coerce it into completed to inflate the rate, or into blocked to create a villain. Unresolved is a data problem, not a product verdict.
Illustrative arithmetic: 20 started, 12 completed, 5 blocked, 3 unresolved. ATCR is 12 ÷ 20 = 60%. The three unresolved tasks stay in the denominator. They are not a footnote you drop so the slide looks cleaner.
How to read the rate
A low ATCR with real starts is a product signal. Something in the path stops the job. Fix the barrier, then see whether the rate moves. Volume without completion is not popularity.
A high ATCR on a tiny denominator means you measured a narrow path. Do not generalize it to "agents love us."
API success rate is the usual false substitute. A 200 tells you a hop worked. ATCR tells you the job finished. You can rack up successful calls while never creating the object the user asked for. That is how a gateway looks healthy while the task dies.
The failure scene behind a blocked task is agents failing without an alert. The stage model is the agent funnel. This post is the unit: started, completed, blocked, unresolved, and a rate you can defend.
The weekly habit is one defined task, one denominator you can explain, and a refusal to treat unique users as a stand-in.
If you want a structured look at where this demand disappears in conventional charts, the Agent Traffic Blindspot Report is the starting point.
Frequently asked questions
Why isn't API success rate a substitute for task completion?
Because the denominator and the outcome are different. Success rate is successful requests over requests. ATCR is completed jobs over started jobs. A caller can get 200s on list endpoints forever and never complete "create and verify a webhook." High success plus low ATCR usually means retries, exploration, or a missing last step. Treat the 200 as health of a hop. Treat ATCR as whether the job you named actually finished.
How should unresolved tasks sit in the denominator?
Leave them in. ATCR is completed divided by started, not completed divided by started-minus-unclassified. Dropping unresolved tasks makes the rate look better and hides a measurement gap. Report the unresolved share next to the rate so a 60% on 20 starts with 3 unresolved is not read as the same object as a 60% with none. If unresolved stays large, fix evidence before you celebrate or panic.