Segments, campaign, reports, all of them now already have separated to ‘web’ and ‘mobile’ notification channels. Now we can also measure notification opens and hits. And last but not least, now we can send custom data (as payload) through our messages, and definie message expirations also.
Our 2.4.0 release is one of our bigest Firebase Cloud Messaging notification update yet.
Perfectly separated ‘web’ and ‘mobile’ notifications
- From now there is a possibility to target directly contacts with only ‘web’ or ‘mobile’ ‘Push ID’s, so we can create only ‘web’ push notification, or only ‘mobile’ push notification campaigns, separated from each other. While in the past we could do the same, the result was not so convenient (was not enough sophisticated yet) as the messages were just automaticaly filtered at the end of the processes, thus in practice without a direct filtering possibility from the administration interface. At the and only persons with ‘web’ ‘Push ID’s got the ‘web’ notifications and also only persons with ‘mobile’ ‘Push ID’s got the mobile notifications, so the result was basically the same, but until now we got error messages in our contacts’ event histories – in all cases -, when the contact had not has both type of ‘Push ID’s.
- The other somewhere relevant problem was the notification reports without – same like – clearly differentiated notification types.
While the core logic about push notifications is, when we want to send one message to our contacts, the platform is basically irrelevant as our goal is only to get the corresponding person to be notified (in any type of notification channel, be it ‘web’ or ‘mobile’), with this release we offer totally separated ‘web’ and mobile’ messages to serve any type of needs. Because the platform dependent features ‘web’ and ‘mobile’ the messages has already been already differentiated from each other. Now the corresponding segments, campaigns and the reports are already also differentiated.
From one side this is a bit overcomplicated situation. In theory we should define a message and sent to our contacts without care about their platform to use. But from another side (because the mentioned differncies), in a practice the differentiated messages could make less misunderstandings while using LeadEngine or Mautic.
Open and hit rate
Now with our plugin we can measure the push notification opens, hits therefore open rates, hit rates. Although their needs are simple, we need to manage their useage in our own applications. We can find the details in our plugin’s user manual.
(The results of those measurements could be in our manually configured notification reports.)
Sometimes we need to deliver some additional/custom data through the notifiations themselves for any custom reason. With the mobile push notifications now there is a solution for it. We can define custom key-value pairs at the mobile messages’ ‘Additional Data’ tab per message and later use those special data in our mobile application (after it had received the corresponding message).
* The function currently is only available at mobile notifications.
Configurable message expiration
The FCM default message expiration is 28 days per subscription (person/device/application). It is the period in which the notification in theory should arrive to the recipient. If it not happens, FCM will drop the message and report its state. The reason of this unsuccessful state could be a switched off device or so where to the message technically could ne be sent.
If we have short life sale campaign, where we need to communicate in a short period, the default 28 days could be a problem as in a flash (eg.: 24 hours long) discount campaign a 2 days late message is basically a failure. Now we can set up our required push notification expiration time – per message – in both of ‘web’ or ‘mobile’ messages.
Don’t forget to update ????