Guides

Data flow

How data moves between your app, the Zeta SDK, ZMP, and the Data Cloud.

Suggest Edits

This page is for developers who want to understand the end-to-end data pipeline. It covers event delivery, push notification routing, in-app message flow, and app inbox synchronization across iOS, Android, React Native, and Flutter.

On this page

Overview

The Zeta SDK acts as the bridge between your app and the Zeta Marketing Platform (ZMP). The data flows in both directions:

  • Outbound: Your app generates events and user property updates. The SDK batches and sends them to the ZMP backend, where they merge with behavioral signals, transaction history, and intent data in the Zeta Data Cloud.
  • Inbound: ZMP delivers push notifications (via APNs or FCM), queues in-app messages, and syncs app inbox content back to the SDK.

End-to-end data flow

flowchart LR
    subgraph device [Device]
        App[Your App] <--> SDK[Zeta SDK]
    end

    SDK -->|"Events & Properties"| ZMP[ZMP Backend]
    ZMP --> DC[Data Cloud]
    ZMP -->|"Push Payload"| PNS[APNs / FCM]
    PNS -->|"Notification"| SDK
    SDK -->|"Tracking Events"| ZMP
    ZMP -->|"In-App & Inbox"| SDK

Event delivery

Events (auto-tracked and custom) are batched by the SDK and sent to the ZMP backend over HTTPS. The SDK queues events locally when the device is offline and delivers them when connectivity resumes.

Note: The SDK queues events locally and delivers them in batches when connectivity is available. Queue capacity and retry behavior may vary by platform.

The general flow:

  1. Your app (or the SDK itself for auto-tracked events) creates an event.
  2. The SDK writes the event to a local database.
  3. On the next batch cycle, the SDK sends queued events to the ZMP backend.
  4. ZMP processes the events and merges them into the user's profile in the Data Cloud.
  5. On success, the SDK removes the events from the local database.

Push notification delivery path

Push notifications follow a round-trip path from ZMP to the device and back.

sequenceDiagram
    participant ZMP as ZMP Backend
    participant PNS as APNs / FCM
    participant Device
    participant SDK as Zeta SDK

    ZMP->>PNS: Send push payload
    PNS->>Device: Deliver notification
    Device->>SDK: Notification received
    SDK->>SDK: Process, render, track
    SDK->>ZMP: Delivery / click events
  1. Campaign dispatch. A ZMP campaign triggers a push notification. ZMP sends the payload to APNs (iOS) or FCM (Android).
  2. Platform delivery. APNs or FCM delivers the notification to the device.
  3. SDK processing. The SDK processes the notification -- rendering rich content (images, GIFs, video) if applicable, handling deeplinks, and firing tracking events.
  4. Tracking events. The SDK sends delivery and click events back to ZMP. On iOS, delivery tracking requires the Notification Service Extension and an App Group.

Note: If the user has opted out of tracking, the SDK does not process incoming push messages. See Opt-in and opt-out.

In-app message flow

In-app messages are foreground-only UI elements rendered by the SDK.

  1. Polling. The SDK periodically polls ZMP for queued in-app messages.
  2. Condition evaluation. When a message arrives, the SDK evaluates display conditions (app state, screen context, frequency caps).
  3. Rendering. If conditions are met, the SDK renders the message as a foreground overlay (toaster-style). The host app does not need to provide any UI.
  4. Interaction tracking. The SDK tracks impressions, clicks, and dismissals, and sends those events back to ZMP.

App inbox sync model

App inbox provides a persistent, queryable message store on the device. The sync model balances local storage with server-side backup.

  • Local store: Up to 200 active messages are stored on the device.
  • Remote backup: The server retains the most recent 50 messages.
  • fetchMessages() sync: Calling fetchMessages() syncs the server's message set to the local store. New messages from the server are added locally; messages not on the server remain in the local store until they expire or the 200-message cap is reached.
  • Status changes are local-only. Marking a message as read or deleting it updates only the local store. These changes are not synced back to the server.

Note: Because status changes are local-only, a user who reinstalls the app or switches devices sees all messages as unread. The local-only model prioritizes performance and offline availability.

See also