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.

Growth solution:

To enable Conversion Rules (and Event Rules) for your account, please contact sales@adjust.com.

Before you begin

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

Requirements

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.
Note:

You can also configure event rule checks during the initial event creation process.

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.

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.
  • 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.
See also:

Add custom callback parameters

Important:

The Preceding event required condition works only for events sent from the SDK.
Do not configure this check for events sent server-to-server (S2S), as it will not be evaluated correctly.


Source check

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.


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
See also:

Set up purchase verification for your app


Data sharing

Rejected events are reported as:

  • Callbacks and CSV exports when a Rejected Event trigger is configured. The {rejection_reason} placeholder is evaluated as post_install_activity_rule.
  • Rejected events metrics in Reports.