topic Re: Clarification on CI360 Exclusion Event Occurrence Behavior for Real-Time Messaging Tasks in SAS Customer Intelligence

Clarification on CI360 Exclusion Event Occurrence Behavior for Real-Time Messaging Tasks

subbu005 — Fri, 15 May 2026 09:36:13 GMT

Hi Team,

I need clarification regarding how Event Occurrence-based Exclusions work in SAS CI360 Real-Time Messaging tasks.

Business Requirement:
We want to suppress API/message execution if a customer has already performed more than 5 qualifying transactions within a rolling 24-hour window.

Example:

Allow first 5 qualifying transactions
Suppress from 6th transaction onward
Customer should become eligible again after the rolling window expires

Current Configuration:
Task Type: Real-Time Messaging Task

Exclusion Configuration:

Event: ESP
Occurrences: > 5
Date Range: Relative
Time Period: Previous 1 day
Attribute Condition: TranAmt > 50

Observed Behavior / Doubts:

Does CI360 evaluate occurrence counts based on:
- historical matching events only?
- or current incoming event + historical events?
Are occurrence counts evaluated per:
- Customer + Event?
- or Customer + Event + Task ID?
If a new task is created using the same event, will old historical event occurrences still be considered?
In UAT, we continuously reuse the same customer IDs for testing. Could previously processed matching events from earlier tasks or tests affect exclusion evaluation in newly created tasks?
If exclusion threshold is already satisfied due to historical matching events, is it expected that the first incoming event itself gets suppressed?
Is there any way to reset or isolate occurrence history per task during UAT testing?

Observed Example:
When attribute condition TranAmt > 50 is configured, sometimes API calls are immediately suppressed even for newly created tasks. However, after removing attribute conditions, some API calls are triggered before suppression starts.

We are trying to understand:

how CI360 internally evaluates occurrence history
how rolling windows are calculated
whether exclusion evaluation is task-specific or event-specific

Please find the attachment of screent of ci360

Could someone please clarify the expected behavior and best practice for implementing transaction-frequency suppression in CI360 real-time tasks?

Thanks!

Re: Clarification on CI360 Exclusion Event Occurrence Behavior for Real-Time Messaging Tasks

SudheeshWarrier — Thu, 11 Jun 2026 03:37:04 GMT

Hello!

All rolling‑window criteria in tasks are normalized by converting the specified time period into seconds. During rule evaluation, the effective time window spans from the current evaluation time (now) back to the specified duration expressed in seconds.
Example:

Event: event_ABC
Frequency condition: At least 2 occurrences
Time window: Past 1 hour

In this case, the one‑hour window is converted to 3,600 seconds. When the rule is evaluated, it verifies whether event_ABC has occurred at least two times within the interval starting at the current time and extending back 3,600 seconds.
The time window may be defined in hours, days, or months; regardless of the original unit, it is always converted to seconds .

Re: Clarification on CI360 Exclusion Event Occurrence Behavior for Real-Time Messaging Tasks

SudheeshWarrier — Thu, 11 Jun 2026 03:41:57 GMT

1. Historical events
2. Customer + Event
3/4. Please see the explanation in my earlier comment to know how and from when the events will be counted.
5. Yes.
6. Unfortunately no. It will be better to use different Indetity for different tests.