Set up event rules

Event Rules extend Conversion Rules to validate post-install events based on custom conditions that you define.
When an event fails these conditions, Adjust rejects it and reports the rejection in callbacks, CSV exports, and reports.

Before you begin

Here's what you need to know before getting started.

Requirements

• Users with Admin, Editor, or Custom Editor permissions in Adjust.
• A single or multi-platform app in Adjust.

Set up an event rule

To set up an event rule, follow these steps.

1. In your app view, open Events & subscriptions and select the event you want to validate.
2. Select Edit event.
3. Navigate to the check that you want to configure.
4. Choose one of the following status options:
   • Live - When the rule is saved, the check becomes active in the Adjust system. Events that do not fulfill the check are rejected.
   • Test - When the rule is saved, the check becomes active in the Adjust system. Events that do not fulfill the check are not rejected, but are flagged and reported.
   • Pause - The rule is not applied to any events. Use this status to save your changes without activating them.
5. Configure one or more checks (see Checks).
6. Select Save changes.

Remove an event rule check

To remove a check, simply set its status to Off.

Checks

You can apply multiple checks to your event rule.
If any check with the Live status fails, the event is rejected.

Target filters

Use target filters to narrow down the traffic each check applies to. Filters are configured per check and do not affect other checks in the same rule.

Channels

Restrict the check to specific traffic channels only. By default, the check applies to all channels.

Install app version

Restrict the check to users who installed a specific version of the app. Use this to ensure the rule logic is only applied to users for whom it is valid and meaningful — for example, users who installed a version where all events and flows referenced by the rule were already part of the app.

Source check

Use this to control which event source is accepted and to handle events that are no longer active in your app.

Accepted event source

Restrict which event source is accepted.

• SDK - Accept only SDK-originated events.
• S2S - Accept only server-to-server events.

If an event arrives from a non-allowed source, it is rejected.

Deprecated event

Reject the event if it has been removed from the app and is no longer being triggered. Use this to invalidate any remaining triggers for events that are no longer part of your app's event flow.

Flow check

Use this to control the expected sequence, timing, and required parameters of events.
You can select multiple conditions. In this case, all selected conditions must be fulfilled for the event to pass. Otherwise, the event is rejected.

Time from install

Require that the event occurs within or after a specific period since install.
Example: "Greater than or equal to 5 minutes after install".

Preceding event required

Require a specific event (for example, Level 1) to occur before this event. As an additional constraint, you can specify a minimum or maximum time window between the required preceding event and the current one.

Event cannot happen if... - mutual exclusion of specific events

Reject the event if a specified other event has already been triggered for this user. Use this to enforce mutual exclusion between two events — if one has occurred, the other is blocked.
Example: "purchase cannot happen if refund already happened".

Last trigger of event happened at minimum before — time-based event suppression

Reject the event if it was triggered less than a specified amount of time ago. Use this to limit how frequently the same event can be accepted for a given user.
Example: "Last trigger of purchase happened at minimum before 5 minutes ago".

Required parameters

Require that specific SDK parameters (for example, user_id, transaction_id) are present in the event payload. You can provide multiple parameters. When multiple parameters are defined, all must exist for the event to pass the check.

Revenue check

Use this check to validate monetized events for completeness and purchase verification.
The check passes or fails based on the Purchase Verification result.
Enable the toggle to also reject events that have missing transaction data.

Revenue check configuration

Purchase Verification configuration is managed under App view → Protection → Purchase verification.
To use Purchase Verification results in the Revenue check flow, you must switch from Legacy mode to Event mode first.

• Purchase Verification not configured for Event Rules

• Purchase Verification configuration example

Data sharing

Rejected events are reported as:

• Callbacks and CSV exports when a Rejected Event trigger is configured. The {rejection_reason} placeholder is reported with granular values per check:
  • post_install_activity_event_rule_source_check
  • post_install_activity_event_rule_flow_check
  • post_install_activity_event_rule_pv_status_check
• Rejected events and Rejected events rate metrics in Reports, with a Reason for rejection breakdown:
  • rejected_events_post_install_activity_event_rule_source_check (Event rule source check)
  • rejected_events_post_install_activity_event_rule_flow_check (Event rule flow check)
  • rejected_events_post_install_activity_event_rule_pv_status_check (Event rule PV status check)
  • rejected_events_post_install_activity_rule (Post install activity filters) — preserved for backward compatibility

Test mode results

Rules in Test status do not reject events, even if the rule fails. Rejected results are shared with customers only — they are not forwarded to partners.

To distinguish test vs. live results, add the {conversion_rule_status} placeholder to your callbacks or CSV export setup. The placeholder returns test when the rule is in test status and live when the rule is in live status.