Auto-Tracked Events

The SDK records the events below automatically. You do not need to call track() for any of them, and doing so produces duplicate data — two rows for the same moment, which silently double-counts every metric built on it. These events can be used as:

Experiment conversion goals in the Console
Webhook triggers for server-side integrations
In-app message and survey triggers
Analytics filters in dashboards and exports

This page is generated from the SDK source. Every event below is emitted by a real call site in the iOS SDK (82 events). CI (pnpm check:auto-tracked-events) fails if the SDK gains an event that is not listed here, so the page cannot drift out of date.

Every event carries the session and identity context automatically — session_id, the anonymous id, and the user id once identify() has been called — and the device context: platform, OS, app and SDK versions, locale, country and, from iOS SDK 1.0.82 / Android SDK 1.0.54, the device’s IANA time zone (device.timezone, see the event envelope). The Key properties column lists what is specific to that event.

Session & lifecycle

Event	Trigger	Key properties
`session_start`	New session begins	—
`session_end`	30 minutes of inactivity or app enters background	—
`app_open`	App enters foreground	—
`app_close`	App enters background	—
`sdk_initialized`	`AppDNA.configure()` completes and the SDK is ready	—
`config_fetched`	A remote-config bundle is fetched (cold start, or a refresh)	—

Onboarding

Event	Trigger	Key properties
`onboarding_flow_started`	An onboarding flow begins	`flow_id` · `flow_version`
`onboarding_step_viewed`	A step is displayed to the user	`flow_id` · `step_id` · `step_index` · `step_type`
`onboarding_step_completed`	User completes a step (e.g., answers a question)	`flow_id` · `step_id` · `step_index` · `selection_data`
`onboarding_step_skipped`	User skips a step	`flow_id` · `step_id` · `step_index`
`step_skipped`	A step is skipped through the advance path	—
`onboarding_completed`	The user reaches the end of an onboarding flow	`flow_id` · `paywall_id` · `completed_via` · `continue`
`onboarding_flow_completed`	User completes the entire flow	`flow_id` · `total_steps` · `total_duration_ms` · `responses`
`flow_completed_via_fallback`	The flow completes through the fallback path rather than the normal one	—
`onboarding_flow_dismissed`	User dismisses the flow before completing	`flow_id` · `last_step_id` · `last_step_index`
`onboarding_paywall_stay`	The user stays on the onboarding paywall instead of dismissing it	`flow_id` · `paywall_id` · `reason` · `completed_via` · `continue`
`onboarding_paywall_skip`	The user skips the onboarding paywall	`flow_id` · `paywall_id` · `reason`

Location answers are reduced at ingest. A location answer inside selection_data or responses is stored and forwarded with only what the geocoding providers’ terms allow. A plain string means the answer was stored as the text the user typed: they typed without picking a suggestion, or, on the SDK releases that resolve a tapped suggestion, they picked one that could not be resolved (the resolve was refused or failed, for example a Mapbox token without permanent access, a Google key without the Geocoding API, a provider error or a network failure, or the suggestion carried no ID). Any other picked answer is an object: {raw_query, timezone, timezone_offset} for a Mapbox permanent answer, {raw_query, place_id} for a Google answer, {raw_query} (the text the user typed) for any other picked answer, keeping only the keys the answer has. The full answer stays on the device (getLocationData). SDK releases that do not resolve a tapped suggestion send a picked answer as {raw_query}; the other two object shapes come only from the releases that do, so which shape you receive depends on the SDK version in the build of your app the user ran.

Permissions

Event	Trigger	Key properties
`permission_prompted`	The SDK presents a system permission prompt during onboarding	`permission_type` · `flow_id` · `step_id` · `granted`
`permission_granted`	The user grants the permission	`permission_type` · `flow_id` · `step_id` · `granted`
`permission_denied`	The user denies the permission	`permission_type` · `flow_id` · `step_id` · `granted`
`permission_already_granted`	The permission was already granted, so no prompt was shown	`permission_type` · `flow_id` · `step_id` · `granted`
`permission_unavailable`	The permission cannot be requested on this device or OS version	`permission_type` · `flow_id` · `step_id` · `granted`

Paywalls & purchases

Event	Trigger	Key properties
`paywall_view`	A paywall is displayed	—
`paywall_close`	Paywall is closed	`paywall_id` · `dismiss_reason`
`purchase_started`	A purchase flow begins	`paywall_id` · `product_id`
`purchase_completed`	A purchase completes successfully	`product_id` · `price` · `currency` · `provider` · `transaction_id` · `original_transaction_id` · `paywall_id` · `is_trial` · `is_consumable` · `emitted_by`
`purchase_pending`	A purchase is pending approval (e.g. Ask to Buy / deferred)	`paywall_id` · `product_id`
`purchase_canceled`	User cancels the purchase dialog	`paywall_id` · `product_id` · `pending`
`purchase_failed`	A purchase fails with an error	`paywall_id` · `product_id` · `error` · `error_type` · `reason` (optional, e.g. `verification_failed`, the server’s code, `not_configured` (a paywall plan tap that reaches the SDK while billing is not configured, both platforms; on Android also a direct `purchase()` made after `configure()` but before billing setup finishes — a direct `purchase()` before `configure()` or after `shutdown()` tracks no event on either platform), or `item_already_owned` (Android: a re-buy of a consumable that is still owned because its consume failed again, or whose purchase flow could not be relaunched after the consume, with `error_type: "unknown"`; a re-buy whose owned purchase fails verification tracks the usual failed-verify `purchase_failed` instead)) · `emitted_by`
`purchase_restored`	A previous purchase is restored, or an already-owned item is bought again	`product_id` · `paywall_id` · `restored_count` · `transaction_id` · `reason` (`item_already_owned` on a re-buy of an owned item, both platforms — that path carries no price) · `provider` (`adapty` on the aggregate event the Adapty bridge emits for a restore, iOS with Adapty linked) · `emitted_by`
`purchase_restore_failed`	A restore fails	`paywall_id` (paywall restores only) · `error` · `error_type` · `reason` (optional: `not_configured` for a paywall Restore tap before billing is ready or after `shutdown()`, both platforms) · `emitted_by`
`purchase_request`	A screen flow requests a purchase from the host app	—
`restore_request`	A screen flow requests a restore from the host app	—

Purchase event details

is_trial: with billingProvider storeKit2 (AppDNA’s own billing), purchase_completed.is_trial is a Boolean on both platforms, and a free-trial start reports price 0. On iOS price is the amount actually charged (the intro price for a paid introductory offer). The RevenueCat and Adapty bridges omit is_trial — an app on revenueCat sees no change in trial event revenue.
Late purchases: a purchase_completed reported after the purchase call has ended carries an empty paywall_id (""). On iOS (.storeKit2) these are interrupted, Ask-to-Buy and offer-code purchases, reported whenever StoreKit delivers the transaction — at app start or while the app runs. On Android they are purchases whose verification failed earlier and purchases made outside the app, reported at every return to the foreground (app start included), at identify, during a restore, and on refreshEntitlementCache().
is_consumable is sent on both platforms, from different sources. On Android it is true for a product marked Consumable in Monetization → Products. On iOS it comes from the App Store product type: true for a product configured as Consumable in App Store Connect (the console flag is not read).
emitted_by is "sdk" on SDK billing events. It is reserved: AppDNA.track drops an emitted_by you pass.
cancel_semantics on subscription_canceled: "vanished_not_renewing" (the SDK saw the subscription disappear while not auto-renewing) or "auto_renew_off" (a billing provider webhook reported auto-renew turned off).
delivery_id on push events identifies one delivery to one device; it requires an AppDNA server from this release.

Subscriptions

Event	Trigger	Key properties
`subscription_started`	A completed purchase is an auto-renewing subscription — fires alongside `purchase_completed`	`product_id` · `price` · `currency` · `provider` · `transaction_id` · `original_transaction_id` · `paywall_id` · `emitted_by`
`subscription_renewed`	The store reports a renewal	`product_id` · `purchase_time` (on Android, absent when the renewal is detected only by a changed order id) · `transaction_id` · `original_transaction_id` · `price` · `currency` (on iOS: the price charged for the new period and its ISO currency; on Android: the base plan’s recurring catalogue price, as Play’s client API has no charged amount per order; both omitted when unknown) · `emitted_by`
`subscription_canceled`	The store reports the subscription cancelled	`product_id` · `transaction_id` · `original_transaction_id` (the last-seen ids) · `cancel_semantics` · `emitted_by`
`subscription_renewal_failed`	The store reports a failed renewal (billing retry)	`product_id` · `transaction_id` · `original_transaction_id` (the last-seen ids) · `emitted_by`

Paid state you report yourself

Event	Trigger	Key properties
`paying_user_reported`	You called `AppDNA.reportPayingUser(...)` — the user is in a paid state for a subscription the SDK never sold	`source` (always `"host"`) · `product_id` · `price` (major units) · `currency` — the last three only when you pass them

source: "host" is what distinguishes your assertion from a purchase the SDK observed, so the two are never confused in the warehouse. There is no user id in the payload: the SDK attaches the identity it already holds. Whether these count toward your bill is part of your agreement — see Who counts as a paying user.

Web entitlements

Event	Trigger	Key properties
`web_entitlement_activated`	Web subscription becomes active	`plan_name` · `status` · `reason`
`web_entitlement_expired`	Web subscription expires or is canceled	`plan_name` · `reason`

Screens, flows & slots

Event	Trigger	Key properties
`screen_presented`	A server-driven screen is displayed	`screen_id` · `screen_name` · `duration_ms`
`screen_dismissed`	A server-driven screen is closed	`screen_id` · `screen_name` · `duration_ms`
`screen_action`	User taps a CTA or interactive element in a screen	`screen_id` · `action_type`
`screen_response_submitted`	A screen form is submitted	`screen_id` · `field_count`
`flow_started`	A multi-screen flow begins	`flow_id` · `flow_name` · `start_screen_id`
`flow_completed`	A multi-screen flow finishes	`flow_id` · `flow_name` · `start_screen_id`
`flow_abandoned`	A flow is dismissed before completion	`flow_id` · `flow_name` · `start_screen_id`
`interception_triggered`	A navigation interception fires and injects a screen	`trigger_screen` · `timing` · `screen_id`
`slot_registered`	A screen slot first renders in the app	`slot_name` · `platform` · `screen_id` · `screen_name`
`slot_rendered`	A slot displays content from a screen config	`slot_name` · `screen_id` · `screen_name`
`slot_empty`	A slot renders with no assigned content	`slot_name`
`message_request`	A screen flow requests an in-app message from the host app	—

In-app messages

Event	Trigger	Key properties
`in_app_message_received`	A message is delivered to the device	`delivery_id` · `trigger` · `source` · `consumed` · `message_type`
`in_app_message_shown`	An in-app message is displayed	`message_id` · `message_type` · `trigger_event` · `cta_action`
`in_app_message_clicked`	User taps an action in the message	`message_id` · `cta_action` · `url`
`in_app_message_dismissed`	Message is closed	`message_id`

Push

Event	Trigger	Key properties
`push_token_registered`	Device token is registered with AppDNA	`token_hash` · `platform`
`push_permission_granted`	User grants push notification permission	`granted` · `push_id`
`push_permission_denied`	User denies push notification permission	`granted` · `push_id`
`push_delivered`	A push notification is delivered to the device	`push_id` · `delivery_id`
`push_tapped`	User taps on a push notification	`push_id` · `delivery_id` · `action` (when the tap carries one)
`push_dismissed`	User dismisses a push notification without tapping it	`push_id` · `delivery_id`

Both platforms report every dismissal. iOS delivers one only for a notification whose category was registered with customDismissAction, so the SDK registers a button-less appdna_default category at configure time and every AppDNA push names it — a push with no action buttons reports its dismissal exactly like one that has them. Android reports dismissals through the notification’s delete intent.A push that names its own category keeps it; only an unset one falls back to appdna_default. If you set a custom category, register it with customDismissAction yourself or that push’s dismissals go unreported on iOS.

Surveys & feedback

Event	Trigger	Key properties
`survey_shown`	A survey is displayed	`survey_id` · `survey_type` · `trigger_event` · `question_id` · `question_type`
`survey_question_answered`	The user answers a survey question	`survey_id` · `question_id` · `question_type` · `answer`
`survey_completed`	User submits a survey response	`survey_id` · `survey_type` · `answers` · `user_id` · `platform` · `completed_at` · `context` · `app_version`
`survey_dismissed`	Survey is closed without completing	`survey_id` · `questions_answered` · `survey_type`
`feedback_form_submitted`	The user submits the free-text feedback form	`feedback`
`feedback_form_dismissed`	The user dismisses the feedback form	—
`survey_followup_prompt_review`	A survey that asks for a review on ANY branch finished, so every respondent was asked	`survey_id`, `sentiment`
`survey_followup_feedback_form`	A survey answer routes the user to the feedback form	—
`survey_followup_winback`	A survey answer routes the user to a win-back offer	—
`review_prompt_shown`	The SDK asked the OS to show a store review prompt	`prompt_type`
`store_listing_opened`	The SDK opened your store listing — the `review` button action, which is a plain link and not the OS review prompt	`store` (`app_store` \| `google_play`) · plus iOS: `app_store_id` · Android: `package`

There is no “accepted” or “declined” review event, and there cannot be. review_prompt_shown records that the SDK asked the OS for a prompt — which is the only thing either store lets an app know. Apple’s StoreKit reports nothing about what the user did next, and Google’s In-App Review API documents that it withholds the outcome deliberately, so that an app cannot condition behaviour on whether a review was left.Both stores forbid the only mechanism that could tell you: a pre-screen dialog (“Enjoying this app?” → Yes / Not really) used to gate who sees the real prompt. Never build one.So there is no review-conversion funnel to measure. Compare review_prompt_shown against your store listing’s review count instead.

Onboarding step hooks

A step can call a hook — your onBeforeStepRender / onBeforeStepAdvance delegate, or a server-side one — before it renders or before it advances. These four events say what happened, so a slow or failing hook is visible as a funnel drop rather than a mystery.

Event	Trigger	Key properties
`onboarding_hook_started`	A step hook began executing	`flow_id` · `step_id`
`onboarding_hook_completed`	A step hook finished	`flow_id` · `step_id`
`onboarding_hook_error`	A step hook failed	`flow_id` · `step_id`
`onboarding_hook_retry`	A failed step hook was retried	`flow_id` · `step_id`

Onboarding chat step

Event	Trigger	Key properties
`chat_message_sent`	The user sends a message in a chat onboarding step	`flow_id` · `step_id` · `turn` · `message_length`
`chat_message_received`	The assistant replies in a chat step	`flow_id` · `step_id` · `turn` · `message_count`
`chat_quick_reply_tapped`	The user taps a quick reply	`flow_id` · `step_id` · `quick_reply_id` · `turn`
`chat_rating_submitted`	The user rates the chat step	`flow_id` · `step_id` · `rating` · `turn`
`chat_completed`	The chat step completes	`flow_id` · `step_id` · `user_turn_count` · `total_messages` · `duration_ms` · `completion_reason` · `role` · `user`
`chat_webhook_error`	The chat webhook returns an error	`flow_id` · `step_id` · `turn` · `http_status` · `response_body`

Deep links

Event	Trigger	Key properties
`deep_link_handled`	A deep link is opened	`url`
`deferred_deep_link_resolved`	A deferred deep link is resolved on first launch	`path` · `params` · `visitor_id`

Experiments

Event	Trigger	Key properties
`experiment_exposure`	First variant assignment per experiment (`getVariant()`, `isInVariant()`, `getExperimentConfig()` or a servable surface); again after an app restart or `reset()`	`experiment_id` · `variant` · `source`

Identity

Event	Trigger	Key properties
`identify`	`AppDNA.identify()` links the anonymous id to a user id	`anon_id` · `user_id`

SDK health

Event	Trigger	Key properties
`sdk_decode_dropped`	Part of a published config could not be decoded and was DROPPED; the rest still rendered	`surface` · `surface_id` · `coding_path` · `dropped` · `total`

coding_path is the field that was wrong and why — for example steps[9].content_blocks[3]: Dictionary<String, Any> was null. A count alone would say that something is wrong and nothing about what, so the path is what the event carries. Reported once per distinct problem per process: one malformed document is decoded on every bootstrap and every presentation, and an unbounded event would bill for thousands of identical rows. The same information reaches your own code through AppDNALifecycleDelegate.onConfigurationIssue.

Platform differences

The tables above are generated from the iOS SDK. Android, Flutter and React Native emit the same event names for the same moments — that parity is enforced by the shared behavioural fixtures in packages/sdk-shared-fixtures/ — but a platform may not implement every surface yet. If an event you expect never arrives, check the platform SDK page under SDKs before implementing it yourself.

Defining your own events

Anything not listed above is yours to define — the product moments no SDK can infer: the action that means a user got value, what counts as activated, the loop a healthy user repeats. See Events for the track() contract, and Analytics & feedback for how they reach your dashboards.

Before adding a custom event, search this page for the moment you are trying to capture. The two most common duplicates are onboarding_completed and subscription_started — both are already here.

​Auto-Tracked Events

​Session & lifecycle

​Onboarding

​Permissions

​Paywalls & purchases

​Subscriptions

​Paid state you report yourself

​Web entitlements

​Screens, flows & slots

​In-app messages

​Push

​Surveys & feedback

​Onboarding step hooks

​Onboarding chat step

​Deep links

​Experiments

​Identity

​SDK health

​Platform differences

​Defining your own events

Auto-Tracked Events

Session & lifecycle

Onboarding

Permissions

Paywalls & purchases

Subscriptions

Paid state you report yourself

Web entitlements

Screens, flows & slots

In-app messages

Push

Surveys & feedback

Onboarding step hooks

Onboarding chat step

Deep links

Experiments

Identity

SDK health

Platform differences

Defining your own events