How to Actually Track AI Agent Traffic in Adobe Analytics and CJA

How agent traffic actually appears, or doesn't, in Adobe Analytics and CJA

Every hit Adobe Analytics or the AEP Web SDK ever records comes from something executing a beacon call, whether that's a browser running your Launch library or a server calling the Edge Network directly. Agent traffic breaks that assumption in two different ways, and they need two different fixes.

A browser-driving agent (OpenAI's ChatGPT agent, the Atlas browser, or a similar computer-use session) loads a real page, runs your JavaScript, and fires a real hit - so unless something specifically flags it, it lands in your report suite indistinguishable from a human visit. It isn't missing; it's silently misclassified as a person.

An API-acting agent (an MCP tool call, an agent completing a purchase through a commerce protocol, a script pulling your pricing page) never opens a browser at all. No JavaScript executes, so no beacon exists to send. This is the case behind the "~70.6% invisible" finding: the session the agent had with your site simply has no analogous event in Adobe Analytics or CJA, full stop, until you build one.

Bot rules will not do this job for you

Adobe Analytics ships two bot-filtering layers: the standard IAB/ABC International Spiders and Bots List (a user-agent-based list Adobe refreshes monthly from the IAB, enabled per report suite) and custom bot rules, which can key off user agent and other request conditions, up to 500 per suite. AEP datastreams carry an equivalent bot-detection configuration at ingestion. Both exist to strip known scraper and spam-bot noise out of your numbers - they were not built to separate a legitimate acting agent from anything else.

That leaves both failure modes open at once: an agent spoofing or omitting a recognizable user agent can dodge the IAB list entirely and land as unclassified traffic, while an agent running inside a real, well-behaved browser session can look plausible enough that no rule ever flags it as non-human. Neither outcome is "your bot rules are broken" - it's that bot rules and agent classification are two different jobs, and only one of them is built in.

Classify the agent before you can count it

Classification starts with telling training/indexing crawlers apart from agents acting live on a person's behalf - a distinction our AI agent user-agent directory maintains in full. The shape that matters for Adobe: GPTBot and ClaudeBot train models and should stay bucketed as crawlers, while ChatGPT-User, Claude-User, and Perplexity-User fetch a page because a live user or agent session asked for it right now - that's the traffic this page is actually about. A full browser-driving agent like the ChatGPT agent or Atlas is the hardest case: it can present a plausible browser user agent with no single reliable tell, which is why composite signals (headless flags, TLS fingerprint, request timing) matter more there than user agent alone - [hypothesis: no vendor has published a definitive detection method for this class as of September 2026].

Once you have a classification rule, Adobe Analytics processing rules can write it into a dedicated eVar or prop at collection time, and the same field flows into CJA through the Web SDK's XDM payload, ready to use in a data view or segment.

IF User Agent CONTAINS "ChatGPT-User" THEN SET eVar70 = "agent-acting-openai"
IF User Agent CONTAINS "Claude-User"   THEN SET eVar70 = "agent-acting-anthropic"
IF User Agent CONTAINS "Perplexity-User" THEN SET eVar70 = "agent-acting-perplexity"
IF User Agent CONTAINS "GPTBot" OR "ClaudeBot" OR "PerplexityBot"
  THEN SET eVar70 = "agent-crawler"
# Everything else keeps its default value - do not overwrite unrelated hits.

The server-side capture bridge

Processing rules and user-agent matching only help the cases where a beacon exists to classify. For a pure API-acting agent, there is no browser hit to intercept, so the fix isn't more client-side JavaScript - it's forwarding the event Adobe never saw. Adobe's Edge Server API accepts events sent directly to the AEP Edge Network without any JavaScript running, which is the same mechanism a server-side capture layer needs to hand off into.

Practically, that means the agent-classification work belongs upstream, in whatever server-side layer already sees the raw request headers before a beacon would ever have fired - exactly the pattern our server-side agent capture guide covers, and the classification logic itself (header/UA/signature rules run server-side rather than trusted from the client) is detailed in classifying agent vs human traffic in server-side GTM. Once that layer has a classified event, it forwards it to the Edge Server API carrying an explicit classification field, rather than asking Adobe to reverse-engineer one later from a request that may carry no trustworthy user agent at all.

How to verify it worked

• Pull a Data Feed (Adobe Analytics) or a CJA Data Feed for a recent window and confirm your classification eVar/prop or XDM field is non-null on a hit you know came from an agent - the cleanest way to get a known-good test row is to trigger one API call yourself and watch for it. An empty field on every row means the processing rule or server-side forward isn't writing the value, not that no agent traffic exists.
• Build a Freeform table or segment in Analysis Workspace broken out by that classification field. A passing result is a non-zero population that moves roughly in line with what your server-side layer independently logged as agent hits over the same window - a large gap between the two counts means the bridge is dropping events, not that the agent stopped acting.
• For a browser-driving agent, check the Bots report first, then the AEP Debugger. If the hit is missing entirely rather than merely unclassified, your IAB or custom bot rules likely stripped it before your own classification could ever run - the Bots report shows what got excluded and why. If the hit is present, the Debugger confirms the classification field carried the value you expect on that live request.
• For a server-side-forwarded API event, verify end to end, not just on the Adobe side. Confirm the event exists in the server-side layer's own log first, then confirm the matching event ID or timestamp reaches the report suite or CJA dataset via Data Feeds. A mismatch here almost always means the forward call to the Edge Server API is failing silently, not that the agent's action never happened.

Illustrative, not a measured result: a team forwarding one API-triggered checkout confirmation through server-side capture might see that single classified hit appear in Analysis Workspace within minutes of the call, instead of only discovering the sale happened by reconciling order records against a report suite total that never moved.

Adobe's bot rules, the AEP Debugger, and the Edge Server API's request shape change between releases - verify current behavior against Adobe's own documentation before relying on any of this at scale. This is also a fast-moving space estate-wide: the identity layer for verifying agents cryptographically (Web Bot Auth) is still a draft standard, and today's UA-based classification is an interim measure, not a permanent one.

FAQ

Does Adobe Analytics have a native way to detect AI agents?

Not as of September 2026 - Adobe has not published agent-specific detection tooling. The IAB Bot Filtering Rules and custom bot rules exist to strip known bad-bot noise, not to segment legitimate acting agents, so a classification field has to be built from your own user-agent and header logic, written in through a processing rule or a server-side forward.

Will building an agent classification field interfere with our existing bot rules?

No - they run independently. Bot rules decide whether a hit is excluded from the report suite at all; your classification field only labels the hits that survive that step. The two need to be reviewed together, though, because a hit your bot rules strip can never reach your classification logic in the first place.

Is this different for CJA versus Adobe Analytics?

The blind spot is the same in both - neither was built to distinguish agents from humans - but CJA gains one practical edge: because it ingests through AEP datastreams, bot detection and any classification field you add both live at the schema level, so the same XDM field is available across every data view built on that dataset, not just one report suite's variables.