Skip to main content

Triggers

A Trigger is the entry point for a user data activation request to Kevel Audience. It holds the basic activation configurations, as well as the list of User Data Destinations that should be triggered on an Activation request.

There are three types of triggers: reactive, scheduled, and user update.

  • A reactive trigger will activate users based on a realtime request, typically generated from an user's browser.
  • A scheduled trigger runs on a defined cadence and can only be associated with destinations that support offline activations. It is best suited to recalculate segments that change purely with the passage of time (for example, "purchased in the last 7 days") or to serve as a fallback if other triggers fail.
  • A user update trigger activates users whenever their profile is modified by tracking activity or data imports, keeping destinations in sync by sending only the new or updated user data instead of refreshing everything. Like scheduled triggers, it is reserved for destinations that support offline activations.
info

Choosing between scheduled and user update triggers

  • Use user update triggers as the default for propagating profile changes created by tracking events or imports; they react as soon as new data lands.
  • Use scheduled triggers when you have time-based segment rules that can change without any underlying event (for example, a user naturally aging out of a "last visit date" window).

Activation Triggers can be configured using the Dashboard under Activate > Triggers, by clicking on the New Trigger button.

dashboard new trigger

Reactive Triggers​

While creating a new reactive trigger, the following fields are available:

  • Name: Name for the Trigger.
  • ID: The key or ID that identifies this trigger. It is used later to issue requests for this specific trigger.
  • Active: Enables or disables the trigger. A disabled trigger does not provide responses for activation requests.
  • Enabled Destinations: The list of Destinations to activate on request.
  • Activate on Match Requests: Defines if this trigger should fire when a match request is issued.
  • Browser Cache Duration: Defines the period that a browser should cache the response.
  • Referrer Validation Domains: If enabled, evaluates the referrer domain, only responding when the request is issued from a website of a valid referrer.
  • Redirect Activation Strategy: Defines the destination to be triggered when a redirect activation is requested. Since the browser can only redirect the client to one location, redirects can either be configured to point to a specific destination or choose a random destination for each request.

After creating the trigger, you can use the Setup JS Tag button to get the JavaScript code that executes the trigger.

activated parameters

Alternatively, you can use the HTTP API to execute a reactive trigger.

Scheduled Triggers​

For scheduled triggers, the following fields are configurable:

  • Name: Name for the Trigger.
  • ID: The key or ID that identifies this trigger. It is used later to issue requests for this specific trigger.
  • Active: Enables or disables the trigger. A disabled trigger does not provide responses for activation requests.
  • Enabled Destinations: The list of Destinations to activate on request. For scheduled triggers, the destinations you can select are restricted to the ones that support offline activations.
  • Triggering schedule: The schedule on which to activate users.

Kevel Audience evaluates every hour if there are scheduled triggers pending execution. A recently created trigger should execute on the hours following its creation. As the schedule is assessed at the date level, ignoring time, triggers typically execute on the first hours of the day, once the configured number of days since the previous execution has passed.

If a trigger is disabled and then re-enabled, it resumes following its cron schedule.

A scheduled trigger always attempts to run at the exact times defined by its cron expression. If the next scheduled time arrives while a previous run is still in progress, that scheduled run is skipped and the system waits for the next cron window.

Scheduled triggers allow the system to run through the user profiles trying to find activation opportunities according to the associated destinations. This is useful when there is no external signal to activate a user profile such as an online event or a bulk import that updates a user profile, or when we are interested in activating segments that rely on time-based rules such as 'purchased in the last week'.

User Update Triggers​

Users update triggers do not have any specific configurable behaviours, requiring only:

  • Name: Name for the Trigger.
  • ID: The key or ID that identifies this trigger. It is used later to issue requests for this specific trigger.
  • Active: Enables or disables the trigger. A disabled trigger does not provide responses for activation requests.
  • Enabled Destinations: The list of Destinations to activate on request. For user update triggers, the destinations you can select are restricted to the ones that support offline activations.

Any user whose profile is updated, whether through a tracking event, an onsite visit, or an offline import, will be activated for the destinations associated with this trigger. This ensures that downstream platforms receive fresh user data as soon as it becomes available, often reducing the need for additional scheduled runs.

Keep in mind that user update triggers only act on profiles that receive an explicit change. If your logic depends on time-window rules, such as 'purchased in the last 7 days', many users who should enter or leave that segment might not produce any new updates for the system to react to. A scheduled trigger fills that gap by evaluating all profiles on its own, without relying on an outside signal.

Last updated on