At a glance: Series of events in validation rules allows advertisers to define an event sequence a real user should go through. Any deviation from your defined order, or from the timing between events, is detected and blocked.
Intro
Advertisers can define an event sequence a real user should go through in your app. AppsFlyer evaluates this sequence using an evaluation window that starts the day the rule is saved: it grows daily up to 30 days, then becomes a rolling 30-day window that shifts forward every day. Events fired before the rule was created are never evaluated.
If the sequence breaks, either in order or in timing, the user is considered fake and:
- Any in-app events after the break are blocked immediately
- The install is blocked in post-attribution, if it falls within the post-attribution window (7 days)
- The associated in-app events inside the evaluation window are blocked as part of the post-attribution process
- Other in-app events that meet the rule's conditions elsewhere in the app are not affected
Note: editing the rule in any way, including app selection, conditions, traffic source, event sequence, or enabling/disabling, resets the evaluation window back to day 0.
Who is this for?
This feature is only suitable for:
- SDK events - Apps that will create rules with only SDK events.
- Non-repeating events - Apps that have an event sequence in which events will not happen more than once in the sequence. If the same event occurs more than once in the sequence (for example, Event C is sent twice), it's treated as a violation and the associated events are blocked.
- NOI traffic - This feature is only available for NOI traffic
How to set up a series of event rule
Follow these instructions to set up a Series of events rule:
- Go to Settings > Validation Rules
- Click + New rule
- Name the rule
- Select the Post attribution tab
- Select the app you want to set the rule for
Note: you can only select one app for each rule - Define the traffic source for the rule to run on
- Choose the conditions. Currently, the options are:
- Geo
- Device model
- Your unique identifier is set automatically based on the app you selected - IDFA for iOS, or Advertiser ID for Android. You can change this to Customer User ID instead, for either platform.
- Define the sequence of events - add at least 2 events, in the order a real user should complete them
- Optionally, set a minimum time gap between each event pair. If you don't set one, a 1-second minimum applies by default
- Review the Rule outcome section to confirm the evaluation window state and the minimum total sequence time
- Click Save
Important!
Don't select all your app's events. Only select the events where there usually could be fraud
Accessing data
When a Series of Events rule blocks an install or in-app event, the details are recorded in your raw data reports. Go to Raw Data > Protect360 & Validation Rules to find blocked events, and use the fields below to identify which ones were blocked by this rule.
| Report | Key fields |
|---|---|
| Post-attribution installs |
|
| Post-attribution in-app events |
|
| Blocked in-app events |
|
Examples
Below are examples of different series of events and if they would be considered fraudulent or not.
Example 1
Defined rule
User should perform events in this order:
- Event A
- Event B
- Event C
Actually performed
The user does the events in this order:
- Day 0: Install occurred
- Day 1: Event A sent
- Day 2: Event B sent
- Day 3: Event C sent
Result:
Not fraud. The user performed the series of events in the defined sequence.
Example 2
Defined rule
User should perform events in this order:
- Event A
- Event B
- Event C
Actually performed
The user does the events in this order:
- Day 0: Install occurred
- Day 1: Event A sent
- Day 2: Event C sent
- Day 3: Event B sent
Result:
Fraud. The user performed Event C before Event B which is out of the defined sequence. As a result:
- Event A will be blocked in post-attribution
- Event B will be blocked in real-time
- Event C will be blocked in real-time or post-attribution as this event broke the sequence
- All following events will be blocked in real-time
Example 3
User should perform events in this order:
- Event A
- Event B (minimum time to previous event: 1 hour)
- Event C (minimum time to previous event: 2 hours)
The user does the events in this order:
- Day 0: Install occurred
- Day 0: Event A sent
- Day 0: Event B sent 10 minutes after Event A
- Day 0: Event C sent 2 hours after Event B
Fraud. The user performed all events in the correct order, but the gap between Event A and Event B was only 10 minutes, which is less than the configured minimum of 1 hour. The timing constraint was violated, regardless of the correct sequence order. As a result:
- Event A will be blocked in post-attribution
- Event B will be blocked in real-time as it violated the minimum time constraint
- Event C will be blocked in real-time as it followed a violated sequence
- All following events will be blocked in real-time
Example 4
User should perform events in this order:
- Event A
- Event B
- Event C
The user does the events in this order:
- Day 0: Install occurred
- Day 1: Event A sent
- Day 2: Event B sent
- No Event C sent
Not fraud. The user completed Events A and B in the correct order but never fired Event C. Incomplete sequences are not flagged as violations. No events are blocked. The rule continues to evaluate future events within the 30-day evaluation window.
Example 5
Defined rule
The user was identified by the Customer User ID (CUID).
The user should perform events in this order:
- Event A
- Event B
- Event C
Actually performed
The user does the events in this order:
- Day 0: Install occurred
- Day 1: Event A sent
- Day 1: Uninstall occurred
- Day 1: Install occurred
- Day 2: Event B sent
- Day 3: Event C sent
Result:
Not fraud. Since the user was identified by the Customer User ID (CUID) and the events were performed in order.
Example 6
Defined rule
The user should perform events in this order:
- Event A
- Event B
- Event C
Actually performed
The user was identified by the Advertiser ID
The user does the events in this order:
- Day 0: Install occurred
- Day 1: Event A sent
- Day 1: Uninstall occurred
- Day 1: Install occurred
- Day 2: Event B sent
- Day 3: Event C sent
Result:
Not fraud. Since the user was identified by the Advertiser ID and the events were performed in order.
Example 7
User should perform events in this order:
- Event A
- Event B
- Event C
- January 1 (Day 0): Rule created. Evaluation window starts. Events fired before this date are ignored.
- January 15 (Day 14): Event A sent. Window is growing, now evaluating the last 14 days.
- January 30 (Day 29): Event B sent. Window is growing, now evaluating the last 29 days.
- January 31 (Day 30): Window reaches 30 days and becomes a rolling 30-day window, shifting forward every day.
- February 20: Event C sent. The rolling window now looks back 30 days to January 21. Event A (fired January 15) falls outside the window and is no longer evaluated.
Not fraud. By February 20, the rolling window looks back to January 21, placing Event A (January 15) outside the evaluation window. Only Events B and C are evaluated - both in the correct order, no violation flagged.
Example 8
Defined rule
The user should perform events in this order:
- Event A
- Event B
- Event C
Actually performed
The user does the events in this order:
- Day 0: Install occurred
- Day 1: Event A sent
- Day 2: Event B sent
- Day 3: Event B sent
- Day4: Event C sent
Result:
Fraud. Since the same Event (Event B) happened twice, we presume fraud, as you cannot have the same event twice in a sequenc.
Example 9
Defined rule
The user was identified by Customer User ID (CUID).
User should perform events in this order:
- Event A
- Event B
- Event C
The user fires events across two devices using the same CUID:
- Day 0: Install occurred on Device 1
- Day 0: Install occurred on Device 2
- Day 1: Event A sent from Device 1
- Day 2: Event B sent from Device 2
- Day 3: Event C sent from Device 1
Not fraud. Since the user was identified by CUID, the sequence evaluation spans all AppsFlyer IDs associated with the same CUID and rule id. Events A, B, and C were performed in the correct order regardless of which device fired them.
Traits and limitations
- Up to 100 events can be defined in each rule.
- At 80 events, a warning is shown. At 100 events, the limit is reached and the rule must be split to add more.
- The minimum time that can be set between consecutive events is 1 second. If no timing is configured for a pair, the 1 second default applies automatically.
- The maximum configurable time gap between events is 30 days, aligned with the evaluation window.
- The evaluation window starts at day 0 (rule creation date) and grows daily up to 30 days, after which it becomes a rolling 30-day window shifting forward every day. Events fired before the rule creation date are never evaluated.
- Any edit to a rule resets the evaluation window back to day 0.
- Up to 10 active rules can be set per account.
- Series of events rules can only be used for non-organic traffic.
- Only SDK traffic is supported. S2S traffic is out of scope for Phase 1.
- Incomplete sequences are not flagged as violations. A sequence is only evaluated once all defined events have been fired.
- The same event cannot appear twice within a single sequence.
- Only AND logic is supported between conditions. OR logic is not supported.
FAQ
What happens after a reinstall?
If the reinstall resets events the user already completed, it's treated as a violation. If the user resumes from where they left off, no violation is flagged.