In-App Messaging – Delivery Logic & SDK Tracking (for Developers)

  • 1 minute(s) read
Prev Next

This page explains the delivery flow of in-app messages in Mapp Engage from a technical perspective. It covers processing logic, SDK behavior, and event tracking codes.

Overview

In-app messages in Mapp Engage follow distinct processing paths depending on the selected message type. Each message goes through multiple steps from event trigger to display or inbox storage. Developers can monitor these steps using SDK tracking events and delivery status codes.

Message Processing Flow

The table below outlines the delivery steps for In-App and Inbox message types.

Step

In-App

Inbox

1. Message Trigger

✓ Triggered by app event

✗ Not triggered

2. Target Group Evaluation

✓ Evaluated in real time

✗ Not evaluated

3. Server Processing

✓ Prepared and queued

✓ Added to message inbox

4. SDK Delivery

✓ Delivered to SDK in real time

✗ No SDK delivery

5. Display Constraints

✓ Checked before display

✗ Not evaluated

6. Message Display

✓ Shown immediately in app

✗ Not shown directly

7. Inbox Storage

✗ Not stored

✓ Stored in inbox

Note

If a message is set to In-App + Inbox, both flows apply.

Event Tracking & Status Codes

Mapp SDK logs delivery steps and errors using specific status codes. These codes help developers validate message delivery and troubleshoot issues.

Step

Event Code(s)

Applies to

1. Message Trigger

SKIPPED_NO_EVENT

In-App

2. Target Group Evaluation

SKIPPED_NO_MATCHING_AUDIENCE

In-App

3. Server Processing

CREATED_SUCCESSFULLY, CREATED_INBOX_ONLY

Both

4. SDK Delivery

DELIVERED_TO_SDK, SDK_NOT_AVAILABLE

In-App

5. Display Constraints

SKIPPED_CONSTRAINTS_NOT_MET, SKIPPED_TOO_FREQUENTLY

In-App

6. Message Display

DISPLAYED

In-App

7. Inbox Storage

STORED_IN_INBOX, NOT_ELIGIBLE_FOR_INBOX

Inbox, In-App + Inbox

Technical Notes

  • Event Triggers: Must be tracked via Mapp Mobile SDK. Untracked events will not initiate message delivery.

  • SDK Availability: If the SDK is unavailable (e.g. during offline usage), real-time delivery will fail and is logged accordingly.

  • Constraint Checks: Display frequency and visibility rules are enforced client-side before rendering.

  • Native vs. Web: The rendering format (selected in Step 2 of message creation) determines how the SDK processes and displays the message:

    • Web: Delivered via WebView container.

    • Native: Renders using fixed templates directly within the app.