Pushes and in-app-Messaging

purple apps summary 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 pushes in the purple experience 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 firebase pushes connect firebase to your purple app docid\ zv k 3gpya3s9x akdeq1 cleverpush docid\ fyk0xb5g94pjftab7ufna airship docid 2zvprdxngl glzp u yde pinpoint docid\ wvkk4pim63ezlhdoilb5q how pushing works 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 set up push messages 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 docid\ iubzrguxkik85qjapwxie 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 testing push messages to verify pushes are working as expected, you'll need to verify every platform on its own testing pushes on ios 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 \<navigationnode targeturl="purple //app/resource/dynamic/firebase/meta html"> \<title>check\</title> \<iconurl>menuicons/info png\</iconurl> \</navigationnode> 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 in app messages in purple it can be done via airship or firebase