Firebase Cloud Messaging as an engine for targeted push notifications

How to begin with push notifications ?

Having a mobile app without the ability to notify users about what’s new – for sure it’s a no-go. In such cases expectations are seemingly simple – you need a notification service that targets different types of app users with different messages.

And the multitargeting part is the most tricky part. For example your app has different language versions and offers that are targeted to particular customer groups. Designing a simple solution that would only send notifications to all app users just isn’t enough.

Another feature that is often needed in terms of push notifications is deep-linking. It means that your app needs to redirect users to specific app locations. In other words you may quickly discover that notifications have to be managed in not that simple way. Therefore, below you will find our way of implementing notifications in a more demanding situation.

Looking for solutions

The first question always is – what do we need in order to start the implementation. First of all you need to put backend and mobile developers together and prepare the architecture plan. In our case we concluded quickly. We needed an external engine where the push notifications can be managed. After this configuration is done we could connect it to the mobile app and display it on Android and iOS. No backend management at this point.

In this article I’m covering one of the most popular solution which is Google Firebase Could Messaging.

Why Firebase Cloud Messaging ?

FCB allows versatile message targeting. It can distribute notifications to clients app in any of 3 ways – to single devices, to groups of devices or to devices subscribed to topics. In the described case (multinational, different groups etc.) subscribing for topics is enough. FCM topic messaging allows you to send a message to multiple devices that have opted in to a particular topic. You compose topic messages as needed, as a result FCM handles routing and delivering the message reliably to the right devices.

While searching for solutions – an important fact in the decision making process is also that FCM service is a free of charge service regardless of amount of data send to the world. At least for now.

Implementation: Firebase configuration

Step 1: Setting up a project

You can start with configuring the Firebase project, no extra CMS panel, no backend involvement as this point. Just a proof of concept – configuring Firebase to see how it looks and, above all, to see targeting different audiences in action. The first step was to just a simple instant messaging tool with no extras.

Step 2: Defining the topics

If you discover that the idea works for you, you can start adding particular topics. For instance the first one we tried was language version – sending notification only to users using polish app version. The app would manage topic subscription. After composing all the topics necessary- notifications could be defined by combination of topics subscribed – for instance – polish version+logged in+ customer group A.

Firebase allows up to 5 topics per 1 message and this, I think, is enough to define most of the target groups.

Step 3: Key-value implementation

After topic management is handled you can start thinking about deep-linking. This feature refers to where the recipient of the push is directed after clicking on the message. Redirection is possible by using the key-value (key: destination) function. You can, for example, define several key-values associated with specific app locations. For instance <settings> – if that key value used – by clicking the notification user would be redirected to app settings.

This allows for a mechanism that after providing a message about new promo offer – notification as a result would take the user directly to that offer.

Implementation: CMS panel

Google Firebase has its own notification composer but it may be not enough in all cases. If your app already has a CMS you can add extra functions to it. It’s extra effort but on the other hand it’s easier to have all the content management in one place. You can think of a user friendly panel for defining the Firebase notification in terms of:

  • Message text – title and main content
  • When to send it – defined time
  • Who to send it to – which topics
  • Message priority – if two notifications send at once – the one with higher priority gets send first, this allowed sequence management
  • How long should it be valid for (if phone switched off or off-line)
  • Location to which the notification should take the user to – deep-linking

If you use the panel – the editor doesn’t even have to be aware that in fact he or she is using Firebase Cloud Messaging service.

Main challenges

However there may be some tricky moments during both implementation and testing. There are issues that need to be remembered to avoid few common problems.

Separate Firebase project for testing

Something that needs to be remembered is to have a separate Firebase project for development and test purposes and separate project for the live app.

Same goes for test and live app versions that need to be connected to those two separate projects in order to have a safe playground to test before using live version published at store.

For Google Play the flow you can establish while releasing a new app version is:

  • test app builds released to Beta channel are only connected to test Firebase project,
  • the release candidate – the Alfa version – is only connected to live project.

This means that checking the release candidate in terms of push notification is not possible – the message would be send to live app users that already have the app that features push notifications.

Topic sign out

The main issue is not only singing-in for topics but also singing out of them. While programming the topic subscription on the app side you need to be very careful. Make sure that if user changes settings (for instance changes the language version) the outdated topic has to be unsubscribed.

If this is not implemented properly you may face:

  • doubled notifications send to device –  two topics regarding language version are subscribed – users receive two notifications.

Handling push settings

You may have some struggle understanding how handling the push settings work. It seemed easier for iOS, where you get a system pop-up asking if sending notifications for this app is allowed. Managing those settings is only possible outside the app within the iPhone settings.

On the other hand with more open Android one may assume that it’s possible to manage the push settings inside the app. For example if phones settings allowed notifications but in-app settings didn’t – in this case you wouldn’t get a notification. For the newest Firebase version when the user has the app disabled, there is no influence on the notification. In-app settings don’t work. The question you may face is whether to downgrade the Firebase version and stick with managing the setting within the app or only use phone settings – the same way iOS does. We suggest to stick to option 2 which seems more transparent. Especially that at some point a Firebase upgrade would be necessary in any case.

What else in Firebase

The initial idea for using Firebase came from need of having a push notifications engine. But of course Firebase is a lot more that that. It can, for example, track platform screen transitions and attach information about the current screens to events. It enables to record metrics such as user engagement or user behavior per screen. As you may have heard the platform became useful for tracking user activity in general. It displaced Google Analytics which allowed to cumulate all the statistics on one platform.