Frequently asked questions

What data does the SDK collect?
Do users need to opt in?
What is BSIN?
How do push notifications work?
Why is the push open rate 0%?
What is the difference between push notifications and in-app messages?
How do I test a mobile campaign before launching?
How do I handle opt-out and GDPR requests?
Can I use the SDK without push notifications?
How quickly do events appear in ZMP?

What data does the SDK collect?

The SDK collects the data your development team configures during integration. At a minimum, this includes:

Lifecycle events: app installs, app opens, app closes.
Device identifiers: a device token for push delivery, and optionally IDFA (iOS) or GAID (Android) if your app provides them.
User identifiers: user ID, email, or other identifiers your app passes to the SDK after login.

Your team can also configure the SDK to collect custom events (add to cart, purchase, video watched), screen views, location data, and custom user properties. The SDK only collects what your app explicitly provides, beyond the automatic lifecycle events listed above.

For a detailed breakdown by platform, see:

Do users need to opt in?

It depends on the channel:

Push notifications: Yes. On iOS, the app must request notification permission and the user must grant it. On Android 13 and later, the app must request the POST_NOTIFICATIONS runtime permission. Users who decline do not receive push notifications.
In-app messages: No opt-in required. These messages are rendered by the SDK inside the app while the user is actively using it. They do not go through the OS notification system.
App inbox: No opt-in required. Inbox messages are fetched and stored locally by the SDK when the app is open.

Separately, the SDK itself has a tracking opt-in/opt-out mechanism. When a user opts out of tracking, the SDK stops sending any data to ZMP and clears locally cached data. Your development team configures this during integration.

What is BSIN?

BSIN (Zeta's unique user identifier) is a unique profile identifier assigned by ZMP to each user profile. When the SDK sends data to ZMP, ZMP matches it to an existing BSIN or creates a new one. You do not need to generate or manage BSINs yourself. ZMP handles assignment automatically based on the identifiers your app provides (email, user ID, device token).

BSINs allow ZMP to link a user's mobile activity with their behavior on other channels (email, web, offline), creating a unified customer profile.

How do push notifications work?

Push notifications follow this flow:

You create a campaign in ZMP and select your target audience.
When the campaign activates, ZMP sends the notification payload to Apple Push Notification service (APNS) for iOS or Firebase Cloud Messaging (FCM) for Android.
APNS or FCM delivers the notification to the user's device.
The notification appears as a banner, lock screen alert, or notification center entry.
When the user taps the notification, the SDK records a click event and sends it back to ZMP.

For push notifications to work, the user must have granted notification permission, and your development team must have integrated the SDK's push handling. See Push notifications for campaign setup details.

Why is the push open rate 0%?

This is expected behavior. Push notifications do not have an "opened" metric equivalent to email opens (which use a tracking pixel). The open rate for push campaigns is always reported as 0% in ZMP.

The meaningful engagement metric for push is the click rate, which measures how many users tapped the notification. Use the click rate in your campaign report instead of open rate.

What is the difference between push notifications and in-app messages?

	Push notifications	In-app messages
Delivery	Delivered by the OS (APNS/FCM)	Rendered by the SDK inside the app
When shown	Any time, including when the app is closed	Only when the app is in the foreground
Opt-in required	Yes	No
Persistence	Managed by the OS notification center	Shown once per trigger, then dismissed
Use case	Re-engagement, time-sensitive alerts	Contextual prompts, onboarding, promotions while user is active

Use push notifications to bring users back to the app. Use in-app messages to engage users who are already active.

How do I test a mobile campaign before launching?

ZMP provides several options for testing:

Preview in the campaign builder. The campaign editor shows a preview of your push notification or in-app message as you compose it.
Test segments. Create a segment containing only internal team members or test devices. Target this segment when activating a test campaign.
Sandbox environment. Your development team can configure the SDK to use a sandbox (non-production) environment for testing push delivery without affecting real users.

Note: For push notifications on iOS, your development team needs to configure both a sandbox and production APNS certificate. Sandbox certificates only deliver to development builds. See Mobile app registration for certificate setup.

How do I handle opt-out and GDPR requests?

The SDK provides a tracking opt-out mechanism. When activated, the SDK immediately stops sending data to ZMP and clears locally cached data.

For GDPR or CCPA data subject requests:

Opt-out from tracking: Your development team activates opt-out in the SDK. No further data is collected or sent.
Profile deletion: Contact your Zeta account team to request deletion of a specific user profile from ZMP.
Data export: To request a data export, contact your Zeta account team.

For more detail, see GDPR and CCPA overview.

Can I use the SDK without push notifications?

Yes. Push notifications are one feature of the SDK, not a requirement. You can use ZMP for in-app messaging, app inbox, event tracking, and audience segmentation without creating any push campaigns. Simply do not create push campaigns in ZMP, and ask your development team not to enable push handling during SDK integration.

How quickly do events appear in ZMP?

Events are transmitted in near real time. Under normal network conditions, events sent by the SDK typically appear in ZMP within seconds. If the device is offline, events are queued locally and delivered when connectivity returns.

Campaign triggers that depend on events evaluate in near real time as well, so a user action can typically fire a triggered campaign within seconds of occurring. Actual timing depends on ZMP backend processing and network conditions.