Adobe Analytics segment date range limit and bot exception rules

Adobe Analytics' September 2026 notes add an option that holds Workspace results to the reporting date range, a way to carve exceptions out of bot rules for Web SDK implementations, and three Coworker Chat features dated October 2. The segment and bot changes can move numbers you already report, so check them before anyone trusts the next month-end deck. The remainder is API documentation and a Report Builder migration that should already be finished.

Key takeaways

• The new segment option limits Workspace results to the reporting date range, even when the segment contains date components. It applies to segments whose top-level container is Visitor.
• Bot exception rules apply only to Edge Data Collection with the Web SDK. AppMeasurement sites are unaffected.
• Custom bot rules now run before IAB rules, so bot rule names on events may change even though bot scores do not.
• The three Coworker Chat features (data analysis, root-cause analysis, opening a visualization in Analysis Workspace) are dated October 2, 2026, with documentation still to come.
• The API changes are documentation only, but they help if you are still moving off the deprecated 1.4 APIs.
• Spend testing time on segments and bot rules. Skim the long fixes list for your own feature areas and leave the rest.

What does the segment date range limit change in Analysis Workspace?

Some segments carry their own date logic. A segment might say visitors who converted in the last 30 days, or hits within a fixed window. When you apply a segment like that to a Workspace report, the data shown can reach beyond the date range you picked on the panel. Most analysts have hit this: you set a week, and the numbers include activity from outside it.

The release adds an option to limit results to the reporting date range regardless of any date components inside the segment. It is available when you create or modify a segment whose top-level container is Visitor. Rollout started August 26, 2026, and general availability was September 9, 2026, so it should already be in your environment.

The notes describe it as an option, and they don't say existing segments change on their own. Treat that as a reason to look, not to worry. Nothing in the release says your saved segments were rewritten, but anyone who edits one from now on can switch the behaviour.

The practical effect is on comparability. If two analysts build the same view with and without the option, the totals will differ, and neither is wrong. They are answering different questions. One asks what happened in this window. The other asks what the segment's own date logic says about these visitors.

Which segments should you review first?

Start with the segments that appear in shared dashboards and scheduled outputs. Those are the ones where a silent difference gets quoted in a meeting.

1. List segments with a Visitor container at the top level that also contain a date range, a time-since rule or a date-based dimension.
2. Mark which of those feed executive dashboards, scheduled reports or exports.
3. For each, decide what the report is supposed to say. If the question is about activity inside the selected window, the new option is probably what you want. If the segment deliberately looks back further than the reporting window, leave it alone.
4. Write the decision into the segment description. A one-line note saves the next analyst an afternoon.

Don't flip the option across the board. A cohort segment built to look back at earlier behaviour can lose its meaning if the window is clipped. Change segments one at a time, and compare the old and new views for a period you already trust.

What do the bot detection updates mean for Web SDK teams?

Two things changed, and only for Edge Data Collection implementations that use the Web SDK. You can now create bot detection rules that identify exceptions, meaning traffic that would otherwise be treated as bot-generated. And custom bot rules now run before IAB bot detection rules. General availability is listed as early September 2026; the notes give no rollout-start date.

Existing and future rules still default to marking matching traffic as bot-generated. So nothing starts letting more traffic through by itself. An exception is something you build.

The case for exceptions is familiar. A synthetic monitoring tool, an internal QA crawler or a partner's verification service can look like a bot, and you want that traffic counted, or at least handled on purpose. Before this, the options for that were blunter. Now you can describe the exception directly.

The ordering change deserves more attention than it will get. The notes say it does not affect bot scores, but the bot rule names associated with an event may change. If anyone downstream filters, groups or alerts on those rule names, that logic can break quietly. Check the places where rule names are used before assuming nothing moved.

If your sites still run AppMeasurement, none of this applies to them. Don't spend time on it there.

How should you test the bot rule changes before trusting them?

Test with a short list of known traffic sources, not with the whole site.

• Pick two or three sources you can identify: an internal monitor, a QA crawler, a known partner tool.
• Note how each is classified today and which rule name shows on its events.
• Check the same sources after the change and record any difference in rule names.
• If you create an exception, apply it to one narrow definition first, then confirm that only the intended traffic is affected.
• Keep an eye on the share of traffic flagged as bot-generated over the following weeks. A shift you can't explain is a prompt to review rule definitions, not a conclusion.

What not to do: write an exception broad enough to cover a whole user-agent family because it was quicker. Exceptions exist to protect specific traffic you understand. A wide one reopens the door the bot rules were meant to close, and it will inflate visits, conversion rates and any sample-based analysis that follows.

Bot handling is also a governance question. Decide who owns these rules, where changes are logged and who approves an exception. In many teams the analytics owner and the web security team each assume the other one handles it.

What are the Coworker Chat features, and who should care?

Three items concern Adobe CX Enterprise Coworker Chat, all with general availability on October 2, 2026. Coworker Chat can analyze data from your Adobe Analytics report suites and answer natural-language prompts, doing advanced analysis that was previously possible only in Analysis Workspace. The data analysis item was originally planned for September 25, 2026, so it slipped a week. A root-cause analysis skill explains why a metric changed, not just what changed. And you can open a Coworker Chat analysis as a visualization in Analysis Workspace to keep building.

The root-cause description is specific. Coworker Chat identifies the date a shift occurred, compares the data before and after, then breaks the change down by the dimensions driving it, with magnitude as both a percentage and an absolute value. If it finds no meaningful change, it says so rather than speculating. That last behaviour is the one to value. A tool that admits there's nothing there is more useful than one that always has a story.

The notes mark documentation as to follow, and they say nothing about licensing, limits or which report suites qualify. Check your entitlement and Adobe's documentation before promising anyone access.

Who should care? Stakeholders who ask for explanations of a dip in conversions and wait two days for an analyst to answer. For them, a faster first pass is real value. Analysts should treat the output as a lead to verify in Workspace, which the hand-off feature makes straightforward. The sensible position: pilot it on questions where you already know the answer, judge whether the breakdown matches, then widen use.

What do the API documentation updates change?

They change documentation, not behaviour. The Classification sets API documentation now has updated endpoint and parameter information for configuring requests (rollout September 5, general availability September 30, 2026). The Analytics 2.0 API date-trended report guides, the KPI report guide and the Advanced report guide, gained sections explaining how date itemId parameters and values are encoded, on the same dates.

The notes tie the second item to migration from the now-deprecated 1.4 APIs. Date itemIds are a common stumbling block when you move trended reports, because the way dates are identified differs from what older integrations expect. If you have scripts, ETL jobs or BI connectors still calling 1.4, this is the documentation to read before the next sprint.

A team that has already moved can ignore it. A team that hasn't should treat it as a prompt to schedule the work, because deprecated endpoints don't improve with age.

Is there anything to do about Report Builder and the long fixes list?

The fixes list is long, and spread across Activity Map, Analysis Workspace, Classifications, Data Feeds and Data Warehouse, Exports, Report Builder, Reporting, Report suites, Scheduled reports and Segmentation, plus a group labelled Other. Classifications and Analysis Workspace carry the most ticket references. The notes give identifiers, not descriptions, so you can't judge impact from the page alone. Scan for the areas you rely on, and if a ticket matches a problem you raised with Adobe, confirm it by retesting.

The end-of-life notice is more actionable. It says the legacy Report Builder add-in would be retired in June 2026 and that users should upgrade workbooks to the new Report Builder, which serves both Adobe Analytics and Customer Journey Analytics customers, has near feature parity and includes a workbook conversion feature. It is available only as an add-in through the Microsoft Store, and many organisations need an internal approval process before installing one. That is the real bottleneck.

If you still have workbooks on the old add-in, don't wait for a failure. Start the approval request now, convert a copy of your most important workbook, and compare outputs side by side.

Rollout checklist: who does what

Change	Who it affects	Action	Suggested owner
Segment date range limit	Analysts and dashboard owners using Visitor-container segments with date logic	Inventory segments, decide per segment, document the choice	Analytics lead
Bot exception rules	Web SDK sites on Edge Data Collection	Test known sources, build narrow exceptions, record rule names	Implementation owner with web security
Custom rules before IAB rules	Anyone filtering on bot rule names	Search reports and alerts for rule-name dependencies	Analytics engineer
Coworker Chat features	Stakeholders asking why metrics moved	Confirm access, pilot on known questions	Analytics lead
API documentation updates	Teams still on 1.4 or using Classification sets API	Read guides, plan migration work	Data engineer
Legacy Report Builder retirement notice	Workbook users	Request add-in approval, convert and compare	Reporting owner and IT

How do you measure whether these changes helped?

Pick a small number of checks and run them for a few weeks.

For segments, compare totals for a fixed window before and after you change a segment, and record both. The goal is a documented, explainable difference, not a match. For bot handling, track the share of traffic flagged as bot-generated and the volume attributed to any source you excluded from flagging. For Coworker Chat, count how many questions it answered correctly on a first pass compared with what an analyst later found. Ten honest comparisons will tell you more than a demo.

For the API and Report Builder work, the measure is finished migrations: how many integrations and workbooks remain on the old path.

Don't expect a metric that tells you the release was worth it. Most of this is hygiene, and the value shows up as fewer arguments about numbers.

Where does an implementation partner help, and where can you go alone?

You can do the segment review yourself. It needs someone who knows your definitions and a spreadsheet. Same for reading the API guides and converting a workbook; those are bounded tasks with a clear end.

A partner earns their fee on the parts that cross boundaries. Bot rules on a Web SDK implementation touch datastream configuration, tagging and sometimes security, and getting an exception wrong skews data for every report downstream. If your Edge Data Collection migration is recent, an experienced implementer can review the rules and the ordering effect in a short engagement. A partner also helps when 1.4 integrations are numerous or undocumented, since inventorying them is the slow part.

If you're weighing outside help, the Adobe Analytics partners directory is a starting point, and find-partners lets you narrow by need. When you do brief someone, the Adobe Analytics RFP template keeps scope specific: name the segments, sites and integrations in play rather than asking for a general health check.

What to ignore: pitches that bundle all of this into a large transformation. This release is a handful of contained jobs.

Sources

• Adobe Experience League — Current Adobe Analytics release notes, September 2026, last updated September 30, 2026