---
title: "System events"
description: "Events recorded automatically by Nuxie and its SDKs."
search:
  tags: ["api", "reference"]
  keywords: ["telemetry", "lifecycle", "$identify"]
---

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](/docs/ios-sdk/configuration#events).

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

```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](/docs/ios-sdk/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](/docs/guides/activity-and-journeys) 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](/docs/guides/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](/docs/ios-sdk/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](/docs/guides/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](/docs/ios-sdk/presenting-experiences) or your [SDK reference](/docs/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](/docs/ios-sdk/tracking-events).

## Next steps

See [Events and triggers](/docs/guides/delivery) to configure delivery, or the [REST API](/docs/api-reference/rest-api) for event request formats.