Mobile Push: FAQs

What is a registration token, and where can I find it?

A Registration Token, also known as a Firebase Cloud Messaging (FCM) registration token, is a unique identifier assigned to each instance of a mobile app that registers with FCM. It is used by the FCM service to send push notifications to specific devices.

The registration token changes in three cases: when you uninstall and reinstall the app, when you clear app data, or when you restore the app on a new device.

Learn more: about how to retrieve registration tokens for the Android and iOS mobile app.

How can I test receiving a Mobile Push to my device?

Follow the steps described in this section to test Mobile Push content.

If a customer's devices are off when I send a Mobile Push, will they still receive a notification after turning the phone on?

If the customer's device is switched off or not within network coverage, your notification will still be delivered when they reconnect within the specified time-to-live period. You can set this period in the Mobile Push Content tab, under the TTL field. By default, this period is set to 4 weeks. For more information, please refer to this article.

Will a mobile push notification appear immediately to the customers in the segment after it is sent?

After using the "Send now" button, customers from the segment will immediately receive a notification on their devices.

Can one segment have multiple Mobile Push campaigns?

Yes, each segment can have multiple active Mobile Push campaigns.

How can I prevent spamming my customers?

To prevent customers from being spammed with notifications, start by implementing global and local frequency caps across campaigns to limit the number of notifications sent per day or hour. These caps ensure that notifications are delivered appropriately without overwhelming recipients. 

Additionally, you may use timestamp attributes in the conditions of segments to further control notification frequency. For instance, consider conditions such as "Push notification sent timestamp last was more than 3 days ago" or "Number of push notifications sent to the user is less than 5."

Do we support other languages in the Mobile Push messages besides English? How can we send multilingual campaigns?

Yes, we support sending messages in languages other than English. During the initial Mobile SDK setup, you can set the language property using a 2-character ISO-639-1 language code. You can then segment users based on their language preference by using the app.language attribute in system events.

Once segmented, you can create mobile push notifications in the desired language and target them to the appropriate user segments. This enables you to run multilingual Mobile Push campaigns tailored to specific language profiles by utilizing the Language dimension within the Mobile Push Subscription attribute.

Please note that changing the language after the initial Mobile SDK configuration is currently not supported.

Is it possible to implement Mobile Push notifications without Firebase SDK in mobile apps?

No, we use Firebase as our data message transfer layer, utilizing its infrastructure to send mobile push notifications.

Do you support multiple apps in multiple Firebase projects?

Yes, we do.

Can we integrate Mobile Push channel without Meiro Mobile SDKs?

No, this is not the supported method. We've developed an SDK to minimize the amount of work required on the client’s side. The SDK handles complex logic such as identifier management, session evaluation, automatic event tracking, queuing of unsent events, and notification display. We bypass the Firebase SDK to enable tracking of Mobile Push-related events, meaning it is no longer responsible for displaying notifications. Additionally, any future enhancements to the Mobile Push channel would necessitate further development on client’s end if the SDK is not used.

We’d like to integrate only the Mobile Push channel without tracking analytics events, because we’re tracking user activity via Adjust already, is it possible?

Yes, it is possible to disable the automatic sending of analytics events using the SDK configuration option called automaticTrackingEnabled. Once this option is disabled, only Mobile Push-related events, such as token registration, push received, or push opened, will be sent.

What if we already have the Firebase SDK integrated and the majority of our app users already have Firebase tokens? Do you support this scenario?

Yes, the iOS SDK handles this scenario seamlessly, automatically collecting registration tokens even if they were issued before integration. For the Android SDK, there is one additional step required, which is detailed in the developer documentation.

How do you manage user consent for sending Mobile Push notifications and tracking?

We don't manage user consent directly. It's the client's responsibility to initiate the Mobile SDK once they have obtained user consent, and to remove it if consent is withdrawn.

How can a user unsubscribe from receiving Mobile Push notifications within the application?

Currently, there isn't an option for users to unsubscribe from Mobile Push notifications within the application. However, if a client requires this feature, the implementation is not difficult. We would create a new system event for changing subscription status and add this functionality to the Meiro SDK interface.

We’re sending transactional Mobile Push notifications via our internal system. Is it possible that integration of your Mobile SDKs breaks this functionality?

No, our Firebase data message payload includes a property called is_meiro_message, and our Mobile SDKs only handle messages containing the property. As long as your Firebase message doesn't include it, you're fine.

We've encountered issues in the past with sending the Mobile Push received event on the iOS platform. How do you address this?

The iOS platform may restrict sending events when the app is not running in the foreground. In such cases, we queue the events, and they will be sent the next time the user opens the app.

Is it possible to retrieve the history of user notifications?

Yes, we can configure the Audience API custom query to return past notifications, they’re based on Mobile Push sent event so the history remains based on event retention.

How do you manage the situation when two different users log in on the same device?

Currently, the best approach is to call the SDK method resetIdentity() when a user logs out. This clears the user ID on the device, ensuring that a different person won't be incorrectly matched based on the previous ID. However, this means you won't be able to reliably retrieve the notification history for anonymous users, as resetting the ID removes the single identifier. We plan to improve this in the future with an enhanced identity stitching algorithm (coming later this year) and identifier-specific attributes / second level filtering (expected next year).

Do you support sending Mobile Push notifications based on a user's preference list?

Yes, we support this partially. Currently, we cannot resolve preference lists for customer profiles with multiple mobile devices. Our recommended approach is as follows:

1. Reset user identity upon logout to prevent the stitching of different users on the same device, which reduces the number of profiles with multiple devices.
2. Create an attribute that counts the number of different devices that have installed and actively use the desired mobile application (i.e., the count of different active registration tokens for the app).
3. Create a compound attribute that holds user preferences, which can be a combination of boolean dimensions and the app name.

When activating a mobile push campaign for a specific app, segment only those users who have a single active device for the app, and then further segment according to user preferences. While this approach is not the most user-friendly, it will be addressed next year with the implementation of identifier-specific attributes / second-level filtering.

We've encountered issues in the past with spamming users through Mobile Push notifications. Do you have measures in place to address this?

Yes, we have implemented frequency caps at both the channel level and the campaign level to prevent spamming users with notifications.

Do you offer a solution for omni-channel preferences, such as when a user prefers to be contacted via email rather than Mobile Push notifications?

No, we don't currently have this capability, but it's coming soon with the Journey Canvas feature. However, it will face similar challenges as those encountered with user preference lists.

What standard parameters do your Mobile Push notifications have?

They support common parameters such as title, body, and image URL, along with actions like opening the app, a browser, or a deeplink. The handling of deeplinks needs to be managed on the application side. We also support setting a time-to-live (TTL) for notifications.

Are we able to set custom data that can be transferred with the notifications?

Yes, you can set a custom data template at the Mobile Push channel level, including default values for certain parameters. In the Mobile Push campaign details, users can modify these values through a user-friendly form.form. Please note that Firebase messages can only contain simple key: value pairs, where the value is always a string.

Can we target only specific platform, eg. iOS users only?

Yes, this is possible in the Mobile Push campaign UI, located next to the application selection.