At a glance: Series of events in validation rules allows advertisers to define an event sequence a real user should go though. The series of events must be met in your defined order and if not met, the user will be marked as fraud.
Intro
Advertisers can define an event sequence a real user should go through in your app. Each event has a 30-day window. Meaning, that we look back and start the 30 days from the first event and not the install day. If the event sequence is performed out of line, the user will be considered fake and:
- The install will be blocked in post-attribution - if it’s in the post-attribution window (7 days)
- The in-app event that broke the sequence will be blocked in real-time or post-attribution
- All in-app events performed before will also be blocked in post-attribution - if the install is within 7 days
- Every event has a 30-day window. Meaning, that we look back 30 days from the first event and not from the install.
- All following events from the same user will be blocked in real-time
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.
- 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 event rule
- Name the rule
- Under the Rule type section, select Post attribution
- Choose your unique identifier - CUID or GAID
- Select the app you want to set the rule for
Note: you can only select one app for each rule - Define the traffic for the rule to run on
- Choose the conditions. Currently, the options are:
- Geo
- Device model
- Define the sequence of events
Important!
Don't select all your app's events. Only select the events where there usually could be fraud
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
Defined rule
The user should perform events in this order:
- Event A
- Event B
- Event C
Actually performed
The install happened in the past.
The user does the events in this order:
- Day 0: Install occurred
- Day 100: Event A sent
- Day 1001: Event B sent
- Day 1002: Event C sent
Result:
Not fraud. The user performed the series of events in the defined sequence, with the install happening before the rule.
Example 4
Defined rule
The user should perform events in this order:
- Event A
- Event B
- Event C
Actually performed
Events are performed more than 30 days apart
The user does the events in this order:
- Day 0: Install occurred
- Day 1: Event A sent
- Day 2: Event B sent
- Day 33: Event A sent
- Day 34: Event B sent
- Day 35: Event C sent
Result:
This series is considered valid. Since after every event we look back 30 days. For example, with Event A (day 33), we look back 30 days and see that Event B (Day 2) is outside of the 30-day window; therefore, we don't see it, and we consider it valid.
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
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 31: Event C sent
Result:
Not fraud. Since we don't presume fraud if the data is not available in the 30 day time frame.
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.
Traits and limitations
- Up to 100 events can be defined in each rule.
- the minimum time that can be set between events is one second. Less than that, and the sequence won't work, and the events will be blocked.
- The time frame for the series of events is 30 days from the first defined event to the last one. Events that break the sequence but are outside the 30-day time frame will not be blocked. See example 4.
- Up to 5 active rules can be set per account.
- Series of events rules can only be used for NOI traffic.