Pushes and in-app-Messaging
Purple Apps
Push notifications and in-app messages are both communication tools used by apps, but they serve different purposes and function differently:
- Push Notifications:
- Sent to a user's device even when the app is not actively open.
- Appear on the lock screen or notification center.
- Often used to re-engage users, alert them to updates, or provide time-sensitive information.
- In-App Messages:
- Displayed only when the user is actively using the app.
- Can be banners, pop-ups, or other message types within the app interface.
- Typically used to guide users, provide tips, or promote features directly while they are engaged with the app.
Both types of communication must be used judiciously, as excessive or irrelevant notifications can lead to user frustration and app uninstalls or browser push opt-outs.
Purple Experience (PXP) allows multiple ways to send push-notifications to users. As sending out pushes in a timely manner is a complex task, PXP relies on third-party integrations for that. Depending on the chosen Push service, pushing may be limited to app contexts only. Please refer to your project manager for further information.
When sending a push notification to an app, several technical steps are typically involved:
- Client-Side Registration:
- The app (client) registers with a push notification service (such as Apple's APNs or Google Firebase Cloud Messaging) when it's installed or opened for the first time.
- The push notification service returns a unique device token or registration ID that identifies the app on that particular device.
- Sending the Device Token to the Server:
- The app sends this unique device token to your backend server.
- The server stores this token associated with the user or device to use for future push notifications.
- Server-Side Preparation:
- When the server needs to send a notification, it composes the message payload. This payload typically includes the message content, title, custom data, and any other relevant information (e.g., badge number, sound).
- The payload is then formatted according to the specifications of the push notification service being used.
- Authentication:
- The server must authenticate itself with the push notification service using credentials such as API keys, certificates, or tokens, depending on the service.
- This ensures that only authorized servers can send notifications to devices.
- Sending the Push Notification:
- The server sends the prepared payload along with the target device token to the push notification service.
- The service processes the request, determines the target device, and sends the notification to the appropriate device.
- Delivery to the Device:
- The push notification service delivers the notification to the user's device.
- The device's operating system handles the notification, displaying it to the user as a banner, alert, or in the notification center.
- User Interaction:
- When the user interacts with the notification (e.g., taps on it), the app is launched or brought to the foreground.
- The app can then handle the notification, often using custom logic based on the data payload received.
- Feedback and Analytics (Optional):
- The app or backend server may collect analytics data on the delivery and interaction with the notification (e.g., delivery success, user engagement).
- Some push notification services also provide feedback on undelivered messages, allowing you to manage inactive or unregistered device tokens.
Pushing Messages to users requires consent of the user. The Systems that push must hold Ids for the Devices to push to, and that's personal data, as devices are uniquely identifiable.
For setting up, we recommend to first set up pushes and add Consent Management App & Web in a later step. With this approach, you'll reduce the degrees of freedom in terms of configuration and test the functionality of your push system independently of the users' consent.
To verify Pushes are working as expected, you'll need to verify every platform on its own.
Pushes are only testable on production-like apps. To test, create a test App via TestFlight and ensure your TestFlight app is built using your latest configurations. Then, retrieve the push token of your app on the test device. The push token is unique to any app installation, so you will need to retrieve it anew, if you have performed a reinstallation of the app.
Bundled with your dynamic resources, you'll usually find a page that will allow you to retrieve Metadata of your App easily. You'll have to configure it to be displayed from your app_menu.xml like so:
- Now, open "Check" from your app and get the push token. (bottom-most value)
If you are pushing to iOS devices, you can execute a push via your Apple developer Console, to verify Apple's systems are working as expected.
It can be done via Airship or Firebase.