Event tracking overview

Events are the foundation of mobile analytics in ZMP. Every app open, screen view, notification tap, and custom action your app tracks flows into ZMP where it powers segmentation, campaign triggers, and reporting.

How event tracking works

Events are generated. The SDK captures events on the device. Some events are tracked automatically (app lifecycle). Others are sent by your app's code (screen views, custom events).
Events are sent to ZMP. The SDK transmits events to ZMP in near real time. On Android, events are queued locally and synced when connectivity is available, so events are not lost during network interruptions.
Events update the user profile. Each event is associated with the user's profile in ZMP. The event history becomes part of the user's record.
Events are available for action. Once in ZMP, events can trigger campaigns, qualify users for segments, and appear in reports.

Auto-tracked events

The SDK automatically tracks the following lifecycle events without any additional configuration by your development team:

Event	When it fires	Description
`app_installed`	First app launch only	Recorded once, on the very first time the app is opened after installation.
`app_opened`	App enters the foreground	Recorded each time the app transitions from background to foreground.
`app_closed`	App enters the background	Recorded each time the app transitions from foreground to background.
`app_terminated`	App is force-quit or terminated by the OS	Recorded when the app is terminated. iOS only.

These events are available in ZMP immediately after SDK integration. No additional configuration is needed.

Note: Auto-tracked events provide baseline engagement data. For richer analytics, ask your development team to add screen tracking and custom events.

Screen tracking

Screen tracking records which screens the user visits within your app. Your development team calls the SDK's screen tracking method on each screen transition, passing the screen name and optionally a deep link URL and custom properties.

Screen tracking data lets you:

See which screens are most visited.
Build segments based on screen views (for example, "users who viewed the pricing page").
Trigger campaigns based on specific screen visits.

The screen name is cached by the SDK and attached to subsequent events as a property, so you can see which screen the user was on when other events occurred.

Custom events

Custom events are actions specific to your business that your development team sends through the SDK. Examples include:

Event name	Description
`add_to_cart`	User added an item to their shopping cart.
`purchase`	User completed a purchase.
`video_watched`	User finished watching a video.
`subscription_started`	User started a subscription.
`search_performed`	User searched for something in the app.
`form_submitted`	User submitted a form.

Each custom event can include properties (key-value pairs) that provide additional context. For example, a purchase event might include product_id, category, and amount.

Custom events are defined and sent by your development team. If you need a specific event for segmentation or campaign triggering, coordinate with your development team to add it.

Where events appear in ZMP

Events from the SDK appear in several areas of ZMP:

Area	How events are used
User profile	Each user's event history is visible on their profile page. You can see when they last opened the app, what screens they viewed, and what custom events occurred.
Segment builder	Use events as filter criteria. For example, "users who fired `add_to_cart` in the last 7 days but did not fire `purchase`."
Experience Builder	Use events as campaign triggers. For example, "when `cart_abandoned` fires, wait 2 hours, then send a push notification."
Report Builder	Include event counts and trends in custom reports.
Campaign reports	Engagement events (notification clicked, in-app message viewed) appear in campaign-level reporting.

Events and segmentation

Every event the SDK sends to ZMP is available as a segmentation criterion. This lets you build audiences based on in-app behavior:

Recency -- "users who opened the app in the last 7 days."
Frequency -- "users who opened the app at least 5 times this month."
Specific actions -- "users who viewed the upgrade page but did not purchase."
Absence -- "users who have not opened the app in 30 days."

Combine event-based criteria with user properties and data from other channels for precise targeting. See Audience segmentation.

Events and campaign triggers

In Experience Builder, you can use SDK events as real-time campaign triggers:

Define a trigger event. Select the event that starts the campaign journey (for example, add_to_cart).
Add conditions (optional). Filter the trigger by event properties (for example, only trigger when cart_value is above a threshold).
Add a delay (optional). Wait before sending the message (for example, wait 2 hours to see if the user completes the purchase).
Send the message. If the conditions are met after the delay, ZMP sends the push notification, in-app message, or inbox entry.

This lets you create responsive, behavior-driven campaigns that react to what users do in your app.

Note: Trigger evaluation happens in near real time. The delay between the user's action and the trigger evaluation is typically seconds, not minutes.