Advanced event settings allow you to define validation rules for event order and timing. These settings are commonly used in rewarded flows to ensure that users complete events in a valid sequence and within expected timeframes.

If the configured conditions are not met, the conversion will still be accepted in Swaarm, but the postback decision will be marked as Failed, meaning the postback will not be sent to the publisher. In rewarded setups, this typically means the user will not receive a reward for that event.

If you are looking for information on how to create or edit events and configure the basic event fields, see Configuring Events on an Offer.

To activate this validation:

When this rule is enabled, Swaarm checks the advanced event conditions for incoming conversions. If a condition is not met, the postback decision is set to Failed, meaning the postback is not sent to the publisher. For more details about Optimization rules, see Optimization Tool Overview.

Advanced event settings allow you to control the sequence of events and the allowed time between events. These settings are configured in the Advanced Settings section when creating or editing an event.

Defines the position of the event within the event flow. Events with a higher order value are expected to occur after events with lower values.

When enabled, this setting ensures that an Install event must be received before the current event.
​

If the system does not detect a previous install for the user - postback decision will be marked as Failed.

This helps prevent events from being attributed when no installation has occurred.

When enabled, the system checks whether the previous event in the defined order has already been received.

Example: if the event flow is
​

In this case if a Purchase is received without a Registration, the condition is not met, so the postback decision will be Failed.

Defines the minimum amount of time that must pass between the Install event and the selected event. This setting helps prevent events from being triggered unrealistically quickly after an installation. If the event is received sooner than the configured threshold, the condition is not met, postback will have decision Failed and will not be sent to the publisher.

Example: If Min. Time Since Install is set to 60 seconds and a Registration event arrives 20 seconds after the Install, the condition fails and the postback will not be sent to the publisher.

Defines the maximum time allowed between Install and the event. If the event arrives later than the configured threshold, the postback decision will be Failed.

Example: Max Time Since Install=7 days, if the event arrives after 7 days, the condition fails and postback will have decision Failed.

Defines the minimum required time between the previous event and the current event.

Example: If Registration is order 20 and Purchase is order 30 and Min Time Since Previous Event = 5 minutes. If Purchase arrives 1 minute after Registration, the postback will have decision Failed.

Defines the maximum allowed time between the previous event and the current event.

Example: Max Time Since Previous Event = 24 hours If the next event arrives later than this threshold, the postback will have decision Failed.

You can extend event validation by using the Banned User optimization rule. This rule allows you to block further conversions from a user once they violate defined conditions on Offer/Advertiser/Global level.

How it works:

This allows you to prevent users from continuing a flow after violating key conditions. For more details, see Postback Decision Optimization Rules.

1) Start with minimal validation

Begin with basic rules such as:

Avoid enabling all timing rules at once. Add additional validation gradually after reviewing real traffic.

​2) Use spaced order values

Set event order using increments (for example, 10, 20, 30) instead of sequential values. This allows you to insert new events later without restructuring the entire flow.

3) Be cautious with timing thresholds

Avoid overly strict time limits, especially for:

Real users may complete events faster or slower than expected. Start with broader thresholds and refine based on actual data.

4) Always monitor decision outcomes

After enabling advanced event settings, monitor:

This helps ensure that valid traffic is not being unintentionally blocked.

5) Use Banned User rule carefully

The Banned User rule blocks all subsequent postbacks from affected users. Enable it only when you are confident that failed events indicate invalid or fraudulent behavior.

6) Validate setup before scaling

Before applying these settings globally:

If advanced event conditions are not met, the conversion will still be accepted in Swaarm, but the postback decision will be marked as Failed, meaning the postback is not sent to the publisher. The impact of these validations can be reviewed directly in reports.

You can analyse postback decision outcomes in the following reports:

In reports, pay attention to the following metrics and dimensions:

Let’s say you configured advanced event validation for an offer 26 and want to understand why some postbacks were not sent to Publisher 66.

Step 1: Open the report

Go to: Reports → Custom Report (or Explorer). Apply filters such as:

Step 2: Add decision fields

Add the following dimensions to the Custom report or Explorer:

And such metrics such as:

Custom report:

Explorer:

​Step 3: Interpret the data

In the report, check:

This shows:

Step 4: Take action if needed

Based on the results, you can:

Conversion-level data can also be analysed in Superset (Reports → Studio) using SQL queries. Utilising Superset is optional and typically required only for advanced or custom analysis. In most cases, Conversion Report, Custom Report, or Explorer provide sufficient visibility into postback decision behaviour.