System events
Events recorded automatically by Nuxie and its SDKs.
Nuxie records system events for app launches, Experiences, purchases, and other SDK activity. Their names begin with $.
Use SDK methods and Experience actions to produce these events. Give your own app events names without the prefix, such as signup_completed.
App lifecycle
The iOS SDK captures these automatically. Its beforeSend hook can filter events; see Configuration.
| Event | Meaning |
|---|---|
$app_installed |
First launch after installation |
$app_updated |
First launch after the app version changes |
$app_opened |
App enters the foreground |
$app_backgrounded |
App enters the background |
Events include the app version, device, locale, and $session_id when available.
Identity
$identify records an identity change or customer-property update. For example, in Swift:
NuxieSDK.shared.identify(
"user-456",
userProperties: ["email": "user@example.com"],
userPropertiesSetOnce: ["signup_source": "organic"]
)The SDK includes the previous anonymous ID when linking a customer to their signed-in account. See Identity and users.
Customer-property actions inside an Experience also record $customer_updated. Its attributes_updated field lists the keys changed by the action.
Journey reports
Journey reports record progress through an Experience. The SDK sends them automatically; they cannot be used as app triggers or conversion goals.
| Event | Meaning |
|---|---|
$journey_leg_started |
A section of a Journey starts |
$journey_leg_completed |
A section ends and reports its outcome and outputs |
Reports include journey_id and leg_id. See Journey history for progress and conversion results.
Experience presentation
| Event | Meaning |
|---|---|
$experience_shown |
An Experience becomes visible |
$experience_dismissed |
The Experience is dismissed |
$experience_errored |
Presentation fails |
$experience_artifact_load_succeeded |
The Experience content is ready |
$experience_artifact_load_failed |
The Experience content failed to load or pass verification |
$screen_shown |
A screen becomes active |
$screen_dismissed |
A screen is dismissed |
These events include the Experience, Version, screen, and Journey IDs where applicable. $experience_dismissed includes a reason, such as user, goal_met, or host. $screen_dismissed includes the dismissal method.
| Property | Meaning |
|---|---|
experience_id |
Experience that produced the event |
experience_version_id |
Published Version used by presentation, screen, and Journey events |
journey_id |
Customer’s run through the Experience |
leg_id |
Section of the Journey being executed |
screen_id |
Screen involved, when applicable |
error_code / error_message |
Failure details, when supplied |
Artifact-load events use experience_version for the Version and also include artifact_build_id, artifact_source, and artifact_content_hash. They describe content loading; $experience_shown confirms actual presentation.
Experiment exposure
$experiment_exposure records when a customer reaches their assigned Experiment path. Experiment results use these exposures to count participants.
It includes experiment_key, variant_key, and is_holdout, along with the Journey and Experience identifiers. Its Version field is experience_version. assignment_source identifies an assignment from the customer’s profile or a fallback path. Assignment alone is not exposure.
Billing and Feature use
| Event | Meaning |
|---|---|
$purchase_completed |
Checkout records a successful purchase outcome |
$purchase_failed |
A purchase attempt fails |
$purchase_cancelled |
The customer cancels the purchase sheet |
$purchase_pending |
Checkout reports a pending purchase |
$purchase_synced |
Nuxie accepts a verified transaction |
$restore_completed |
Restore completes with purchases |
$restore_failed |
Restore fails |
$restore_no_purchases |
Restore completes without purchases |
$feature_used |
Nuxie accepts metered Feature usage |
$products_unavailable |
Products needed for a screen could not be loaded; product_ids identifies them |
$purchase_completed records the checkout outcome. $purchase_synced records Nuxie’s acceptance of a verified transaction. With Nuxie’s native checkout, verified transactions establish revenue and Feature access. With a purchase delegate, a successful outcome counts toward Journey completion, but it does not send the store transaction or change the customer’s Features. RevenueCat and Superwall Connectors feed Automations and server-side Journeys, without granting or maintaining Feature access today. Support for signed transactions from delegated checkout and Feature access through Connector webhooks is planned.
See Purchases for SDK methods and provider setup.
Permissions and responses
Experience actions record permission choices:
| Event | Meaning |
|---|---|
$notifications_enabled |
Notification permission is granted |
$notifications_denied |
Notification permission is denied |
$permission_granted |
An authored permission request succeeds |
$permission_denied |
An authored permission request is denied |
$tracking_authorized |
App Tracking Transparency authorization is granted on iOS |
$tracking_denied |
Tracking authorization is denied on iOS |
Response inputs update the answers collected by an Experience. $response_set and $response_unset are local response controls, not activity events. Setting an answer and submitting it are separate actions; see Collected responses.
App Actions
$app_action_requested records an Experience handing an action to your app. Its name identifies the action, and payload contains the authored data when present.
For example, an Experience can request open_workout with a workout identifier. Your SDK callback opens the native workout screen. This event records the request; record your own app event if you also need to measure completion of the app’s work.
See Presenting Experiences or your SDK reference to register the handler.
Use system events in Nuxie
System events can be used in analytics, Segment conditions, and supported Journey conditions. For example, a Segment can select users with at least one $app_opened event in the last seven days.
Use ordinary named events for app-specific outcomes, such as workout_completed. Recording $purchase_completed or $feature_used as an analytics event does not grant access, synchronize a purchase, or deduct usage. Those operations use the SDK’s purchase and Feature methods.
Event delivery
The SDK queues events and sends them to Nuxie. A device callback can arrive before the corresponding event appears in customer history or analytics.
Keep SDK-generated event IDs when forwarding or retrying events so repeated delivery does not create another occurrence. On iOS, use the SDK’s activity forwarding interface to send supported events to another analytics provider; see Tracking events.
Next steps
See Events and triggers to configure delivery, or the REST API for event request formats.