1. What Happened? – Adobe Bot Detection Exceptions
Adobe has made a small change to bot detection in Edge Data Collection with the Web SDK, and it is more consequential than its wording suggests.
Two things changed:
You can now create bot detection rules that identify exceptions — traffic that would otherwise be treated as bot-generated. Existing and future rules continue to default to marking matching traffic as bot-generated, so the behaviour you have today is unchanged unless you opt in.
Custom bot rules now run before IAB bot detection rules. Adobe is explicit that this does not affect bot scores, but that the bot rule names associated with an event may change.
The update applies only to Edge Data Collection implementations using the Web SDK. It does not apply to older libraries such as AppMeasurement.
On its face: a configuration refinement and a processing-order tweak. In practice, the first is the interesting one, because for the first time Adobe’s tooling acknowledges that traffic matching a bot signature might not be traffic you want to throw away.
That assumption — non-human equals worthless — is the foundation every analytics bot filter has been built on for twenty years. It is now wrong, and the exception rule is the first piece of tooling to admit it.
What bot detection actually does, in two separate systems
Before anything else, there is a structural confusion in Adobe’s stack that catches a great many teams, and the documentation states it plainly without anyone noticing.
Edge Network bot detection scores but never removes. When a request to the Edge Network matches a bot detection rule, the XDM schema is updated with a bot score, always set to 1. Adobe is explicit: “Bot detection does not drop any bot requests. It only updates the XDM schema with the bot scoring, and forwards the event to the datastream service you configured.”
Adobe Analytics bot rules remove. Traffic matching those rules “is not collected in the report suite and is not included in traffic metrics”. It is stored separately for the Bots and Bot Pages reports.
And critically, the two do not talk to each other. Adobe’s documentation states that the bot detection process used in Adobe Analytics “is separate and does not reference the bot score included on data arriving through the Edge Network”, though both use the same IAB bot list.
So you can configure Edge Network bot detection meticulously and change nothing about what appears in your Analytics reports. You can tighten Analytics bot rules and change nothing about the bot score reaching your other destinations. Two systems, one shared list, no shared configuration.
Establish which one you are actually talking about before any other conversation in this article.
2. Why Does Adobe Bot Detection Exceptions Matter?
The bot/human binary has stopped describing reality
Bot filtering was designed for a world in which non-human traffic was crawlers, scrapers, uptime monitors and scripted scanners — traffic with no commercial value that distorted your numbers. Filtering it was straightforwardly correct.
That world has changed. A growing share of non-human requests are AI agents acting on behalf of a real person with real intent.
The behavioural data makes the point better than argument does. Reporting by HUMAN Security on agentic traffic through 2025 found that 87% of agent requests targeted product pages, with 2.2% of interactions involving shopping carts, checkout and payment functions. That is not the shape of a scraper. That is the shape of someone shopping.
The same reporting notes agentic traffic rising 1,300% between January and August 2025, and cites a Semrush finding that users arriving via AI-generated answers convert 4.4 times better than those from traditional search.
Here is the part that should make an Adobe customer sit up. The same body of research cites Adobe’s own finding that 38% of consumers have used generative AI for shopping.
Adobe’s research says a significant minority of consumers now shop with AI assistance. Adobe’s default analytics configuration treats the resulting traffic as noise to be filtered. Both statements are reasonable in isolation. Together they describe a measurement gap that nobody has been given the tools to close — until, modestly, now.
Denominator drift: your conversion rate is being distorted in both directions
Adobe states the consequence of filtering directly: “Removing bot traffic typically reduces the volume of traffic and conversion metrics. Many customers find that removing bot traffic results in increased conversion rates.”
Read that as an equation. Filtering reduces the denominator, conversions stay roughly flat, conversion rate rises. That is correct and desirable when the filtered traffic genuinely had zero chance of converting.
It becomes a measurement failure the moment some of that filtered traffic was an agent researching a purchase for a human who later bought. Then you have removed sessions that contributed to a conversion while keeping the conversion, and your attribution quietly reassigns credit to whatever channel the human arrived through afterwards.
Neither over-filtering nor under-filtering gives you a true number. The difference is that under-filtering is visible as noise and over-filtering is invisible as absence.
You pay for the traffic you filter
A line in Adobe’s documentation that almost nobody surfaces to finance: “Hits marked as bots are billed as server calls.”
Bot filtering is a data quality control, not a cost control. Filtering more aggressively improves your reporting and does nothing whatsoever to your Adobe bill. Any business case that promises cost savings from bot filtering is wrong, and any CFO who has been told otherwise should see that sentence.
The processing-order change will break dashboards silently
Custom rules now running before IAB rules does not change scores. It may change which rule name is attached to an event.
If your reporting segments, groups or attributes anything by bot rule name — and mature Adobe implementations frequently do, because that is how you distinguish search engine crawlers from scrapers from your own monitoring — those segments may shift without any change in the underlying traffic.
This is the same class of problem as a reporting change masquerading as a performance change. The score is identical, the label moved, and a dashboard built on labels now disagrees with itself across the change date.
The privacy setting that silently breaks your IP rules
This is the sharpest operational trap in the documentation and it sits at the intersection of two teams who never speak.
Adobe explains that the IAB list is based solely on user agent, so IP obfuscation does not affect it. Custom rules are different: if the last-octet-removal setting is enabled, that removal happens before IP filtering. Adobe’s instruction is explicit — “the last octet is replaced with a 0, and IP exclusion rules should be updated to match IP addresses with a zero on the end. Matching * should match 0.”
So: your privacy or legal function enables IP obfuscation for GDPR reasons. Nobody tells analytics. Every custom IP-based bot rule written against a full IP address silently stops matching. Bot traffic reappears in your reports, gradually, with no error anywhere.
We have now written about this pattern four times in different systems — security teams blocking crawlers, paid media consuming organic crawl capacity, legal blocking AI training and taking Search with it. The shape is always the same: a correct decision by one function, implemented through a system another function depends on, with no review gate between them.
Exception rules are holes, and holes get exploited
The new capability deserves one warning before anyone uses it.
An exception rule tells your analytics to trust traffic it would otherwise distrust. If that rule can be satisfied by a forgeable signal, you have built a bypass that anyone can walk through — and the traffic that most wants to look legitimate is precisely the traffic you least want in your data.
The Edge Network rule design is sensible here: rules are built on IP addresses and ranges, with request headers available as additional granularity. IP is hard to forge; headers are trivial. Building on IP and refining with headers is the right order.
Adobe Analytics custom bot rules are more permissive — User Agent, IP Address or IP Range, with multiple conditions matched using OR, and AND matches not supported in the CSV import path. A user-agent-only rule is a string match on a value the client controls. Use that for filtering, never for exceptions.
3. Who Is Affected?
Enterprise Adobe Analytics and AEP customers on the Web SDK. The update applies only to Edge Data Collection implementations using the Web SDK and not to AppMeasurement. If you are mid-migration — and most large Adobe estates are — you have two different sets of behaviour across your properties right now.
Retail and ecommerce. Where agent traffic concentrates. If 87% of agent requests hit product pages, product and category reporting is where distortion lives, in both directions.
Any business with an agentic commerce strategy. If you are investing in being discoverable and transactable through AI assistants — and anyone who read our pieces on ChatGPT restaurant reservations or Search Console multimodal reporting should be — you need to be able to see whether it is working. Filtering the traffic makes the investment unmeasurable.
Organisations with IP obfuscation enabled. Which, in Europe, is most of them. Your custom IP rules may already be silently broken.
Teams with reporting segmented by bot rule name. Directly exposed to the processing-order change.
Publishers and media businesses. Audience numbers underpin commercial rate cards. Changes to what counts as a human visit are commercially material, not merely analytical.
Finance and procurement. The server call billing point. Filtered bot hits are billed hits.
Anyone about to turn bot filtering on for the first time. Adobe’s own warning applies to you most of all: communicate with stakeholders before removing bot traffic so they can adjust KPIs, and consider testing on a small report suite first to estimate impact.
Who is less affected: low-traffic B2B sites with little automated attention and no agentic commerce exposure. Even there, the IP obfuscation interaction applies if you have custom rules.
4. What Should Businesses Do?
Resist the urge to start writing exception rules. The first work is establishing what your current configuration actually does, because in most organisations nobody knows.
4A. Everyone: establish the baseline before changing anything
Determine which system you are configuring. Edge Network bot detection scores and forwards. Adobe Analytics bot rules remove. They do not share configuration. Write down which one each of your properties uses, and for what.
Confirm your implementation path. Web SDK with Edge Data Collection gets the new exception capability. AppMeasurement does not. In a mixed estate, document which properties are on which.
Check the schema prerequisite. For bot detection to work on a datastream, the Bot Detection Information field group must be present in your schema. A missing field group means the whole thing is inert.
Export your current rules before touching anything. Adobe Analytics supports exporting bot rules to CSV. Do that, date it, and archive it. The UI supports 500 manually defined rules before bulk management becomes necessary, so mature estates frequently have rule sets nobody fully understands.
Audit the rules you find. For each: who created it, when, why, and is it still valid? Expect to find rules written against infrastructure that no longer exists and vendors you no longer use.
Size the problem with the Bots and Bot Pages reports. Bot traffic is retained there even though it is excluded from your metrics. That is your evidence base for how much traffic is being filtered and what it is doing — including whether it is behaving like a scraper or like a shopper.
Check whether your IP rules still match. If IP obfuscation is enabled with last-octet removal, any custom rule written against a complete IP address has stopped working. Rewrite to match a trailing zero. This is the single highest-value hour in this article for any European enterprise.
4B. For the analytics and marketing team: manage the discontinuity
Treat any bot rule change as a reporting change and annotate it. Adobe’s guidance is unambiguous — communicate with stakeholders before removing bot traffic so they can make the necessary adjustments to KPIs, and where possible test on a small report suite first to estimate impact.
Specifically, brief stakeholders that after a filtering change they should expect:
- Traffic volume down
- Conversion volume down
- Conversion rate up
- Year-on-year comparisons across the change date invalid
Every one of those is an artefact of the configuration, not of performance. Say so before the numbers land, not after someone has built a quarterly narrative on them.
Never ship a filtering change mid-quarter without a dated annotation. This is the discipline that prevents an unresolvable argument three months later.
Decide your position on agent traffic explicitly, and write it down. This is a commercial decision, not a technical one, and it has three defensible answers:
- Filter it entirely. Cleanest reporting, and you are blind to a growing channel.
- Filter it but segment it. Excluded from headline metrics, visible in a dedicated view. For most businesses this is the right answer today.
- Include it with a flag. Fullest picture, noisiest headline numbers, and it requires every downstream consumer to understand the flag.
The wrong answer is not choosing, which is what “we use the defaults” means.
Build the agent segment before you need it. Whatever you decide about headline reporting, you want the ability to answer “how much of our product page traffic is agentic, and is it growing?” The businesses that can answer that in 2027 will be the ones that started segmenting in 2026.
Watch the rule-name change. If any report, segment or classification depends on bot rule names, re-validate it against the new processing order. Scores are stable; labels may not be.
4C. For the development and data engineering team: design rules that cannot be spoofed
Build exceptions on IP, refine with headers — never the reverse. The Edge Network rule model supports IP addresses and ranges, optionally combined with request header conditions including user-agent, referer, content-type and the sec-ch-ua client hint family.
Understand the boolean logic before writing anything, because it is not intuitive:
- IP conditions are OR. A request matches if it matches any IP condition.
- Different condition types are AND. All must be satisfied.
- Multiple conditions of the same type are OR. Any one satisfies that type.
So a rule with two IPs, a referer condition and a sec-ch-ua-mobile condition matches when: (IP A or IP B) and referer matches and mobile flag matches.
# Exception rule shape — IP is the anchor, headers add specificity
IP range: <your verified monitoring egress range>
AND user-agent: contains "<your synthetic test identifier>"
AND referer: <where the traffic should originate>A rule that can be satisfied by headers alone is a rule anyone can satisfy. In Adobe Analytics custom bot rules, where conditions are matched with OR and AND is not supported in CSV import, a user-agent-only rule is a pure string match on client-controlled data. Acceptable for filtering. Not acceptable for exceptions.
Verification beats string matching, and allowlisting a forgeable header is a hole, not a fix.
Candidate exceptions, in order of defensibility:
- Your own synthetic monitoring and performance testing, from known egress IPs — you may want these visible in a dedicated segment rather than discarded.
- Verified partner integrations operating from known ranges.
- Accessibility tooling where it is being misclassified.
- Verified AI agent traffic — the hard case, and the one worth the most. Only where you can verify the source by IP, not by user-agent claim.
What should not be an exception: anything identified only by a user-agent string, anything from an IP range you do not control or cannot verify, and anything added “temporarily” during an incident.
Fix the IP obfuscation interaction properly. If last-octet removal is enabled, rewrite every custom IP rule to match a trailing zero, and note that a wildcard should match zero. Then add a test so this is caught next time rather than discovered a year later.
Respect propagation and processing order. Edge Network bot detection rules can take up to 15 minutes to propagate; Adobe Analytics bot rule changes take effect within about 30 minutes. VISTA rules are applied after bot rules, so VISTA never sees filtered traffic — which may be exactly what you want, or may be removing data a VISTA rule depends on.
Know the authentication boundary. Bot detection applies only to unauthenticated requests sent to edge.adobedc.net. Authenticated requests to server.adobedc.net are not evaluated, because authenticated traffic is treated as trustworthy. Any analysis of bot volumes that does not account for that split is comparing different populations.
Account for High-Hit Visit Processing when sizing bot activity. Where more than 100 hits occur in a visit and the visit duration in seconds is less than or equal to the hit count, reporting starts a new visit. Intense automated sessions are therefore split into multiple visits, which inflates visit counts and understates hits per visit. Worth knowing before you quote a number.
Manage rules as code. With a 500-rule UI ceiling and CSV import and export available, bot rules should live in version control with a review process, not in a settings screen edited by whoever had access last. Each rule needs an owner, a date and a reason.
4D. Rolling it out
- Export and archive current rules from every report suite and datastream, dated.
- Document which system and which library each property uses.
- Verify the schema field group is present where Edge bot detection is expected to work.
- Fix broken IP rules caused by obfuscation. Highest value, lowest risk.
- Audit the Bots report to size and characterise what you are currently filtering.
- Decide the agent traffic position — filter, segment, or include — and record the decision.
- Test on one small report suite first, as Adobe recommends, to estimate impact before touching your primary.
- Brief stakeholders on the expected metric movements before any change reaches a reporting property.
- Ship changes at a period boundary, annotated, never mid-quarter.
- Re-validate any reporting that depends on bot rule names against the new processing order.
- Review after 30 days against the Bots report and the agent segment.
4E. Governance
Give bot configuration a named owner. It sits between analytics, data engineering, security and privacy, which in most organisations means nobody owns it and everybody assumes someone else does.
Add bot rules to privacy change review. The IP obfuscation interaction is the proof that privacy settings and analytics configuration are coupled. A change to one requires a check on the other.
Review the rule set quarterly. Rules accumulate, infrastructure changes, vendors come and go. An unreviewed rule set degrades silently.
Record every change with a date and a reason, and keep the annotation in whatever system your stakeholders actually read.
5. What We’re Watching Next
The bot taxonomy splitting into categories that matter commercially. “Bot” is no longer a useful single category. Crawlers, scrapers, monitoring, AI training crawlers, AI retrieval crawlers and user-directed agents have completely different commercial meanings. Adobe’s exception rules are the first crack in the binary; we expect analytics vendors to move towards native agent categories within two years, because customers will demand to see what they are losing.
Verified agent identity becoming the enabling technology. Exception rules built on IP ranges work only while agent operators publish stable ranges. Cryptographic bot authentication approaches are emerging precisely because user-agent strings are not evidence. Whichever standard wins, it will make agent exceptions safe in a way that string matching never will.
Agentic conversion attribution becoming a board question. When a meaningful share of research happens through an agent and the purchase completes elsewhere, last-click attribution misreports the channel systematically. Businesses currently filtering agent traffic out cannot even see the problem.
The billing conversation. Filtered bot hits are billed as server calls. As automated traffic grows as a proportion of total requests, the gap between what you pay to collect and what you are permitted to analyse widens. We expect that to become a commercial negotiation rather than a documentation footnote.
Measurement becoming the constraint on agentic commerce strategy. The strategic work — being findable and transactable by assistants — is ahead of the measurement work by roughly a year. The organisations that close that gap first will be able to fund the strategy properly. Everyone else will be arguing about whether it works.
6. About Szymaniak Digital
Szymaniak Digital is an enterprise AI SEO consultancy working with senior marketing teams and the engineering teams who ship for them. We audit how organisations classify and measure non-human traffic, build the segmentation that makes agentic channels visible, and design the controls that keep analytics honest when the definition of a visitor is changing underneath it.
If a growing share of your customers research through an AI assistant, and your analytics is configured to discard that traffic as noise, the strategy and the measurement are pointing in opposite directions. Book a measurement review.
