System events

System events are automatic events fired by the Xtremepush platform, without any custom event tracking code in your app or website. They can be used as campaign triggers in the same way as custom events.

application_install

This event fires the first time a profile is created as a result of a device installing and launching your mobile application.

Available for: Mobile app campaigns (iOS and Android)

Use cases:

• Welcome push notification on first launch
• Onboarding campaign enrolment

📘

This event fires once per profile, on first install. Re-installs on the same device linked to an existing profile do not re-fire this event.

session_start

This event fires each time a user opens your mobile application and begins a new session.

Available for: In-app campaigns (iOS and Android only, not on-site)

Use cases:

• Re-engagement campaign triggered after a period of inactivity
• Contextual in-app message shown at app open

📘

session_start is available as a named system event in the campaign trigger selector. When selected, it bypasses the standard event validation check (which requires the event to have been recorded in the past year), since no event record is stored in the event history for session starts.

profile_create

This event fires when a new profile record is created in Xtremepush, typically via a profile import (CSV or API import).

Use cases:

• Welcome email or SMS triggered at the point of profile creation during a data import
• Initial segmentation or lifecycle entry campaign

🚧

profile_create is triggered by profile imports, not by a device app install. For app install behaviour, use application_install. Not all profile creation paths fire this event — it is specifically associated with the import pipeline.

preference_trigger

This event fires when a profile's consent preference changes, for example, when a user opts in or out of a named marketing preference.

This event is only available on projects that have the Subscription Preferences and Campaign Trigger by Consent Preference Events features enabled.

Use cases:

• Confirmation message when a user opts in to a specific marketing category
• Suppression or re-engagement logic driven by preference changes
• Double opt-in confirmation flow

Event payload

Unlike other system events, preference_trigger carries a structured payload that can be used for event filter conditions:

{
  "user_id": "u123",
  "customer_id": "c456",
  "preferences": {
    "marketing": [
      {
        "preference_id": 1,
        "name": "marketing",
        "display_name": "Marketing Emails",
        "channel": "email",
        "status": 1,
        "timestamp": 1713100000,
        "source": "manual",
        "metadata": { "channel": "branch" }
      }
    ]
  }
}

Filtering on preference payload

When Limit triggering on some events is enabled for a preference_trigger campaign, conditions are evaluated against the preference properties listed above. For example, you can trigger a campaign only when source equals manual, or only when channel equals email.

📘

Multiple preference changes for the same profile are batched into a single event firing with a short delay. The preferences object may therefore contain more than one preference entry per event. When event filter conditions are applied, only the preference entries that match the conditions are included in the payload passed to the campaign.

Targeting a specific preference

A preference_trigger campaign can be scoped to a specific named preference by setting the Trigger event field to the preference name. Setting it to 0 (or leaving it unconfigured for "any") will trigger for changes to any preference.