It all sounds like magic doesn’t it? How can a Firebase tool predict what my users are going to do? It’s all thanks to machine learning — Predictions applies machine learning to tracked analytics data that allows us to dynamically create user groups based on predicted user behaviour. These dynamic groups consist of users who are likely to complete a specified task within the next 7 days — this group of users is known as predicted user groups. These specified tasks each correspond to a single specific task, for example we could have a task for when a user is predicted to stop using our app, upgrade their account, perform an in-app purchase or even use a specific feature.
Once these dynamic groups have been populated we can then utilise them with other Firebase tools including Remote Config, Notifications Composer and A/B testing to increase user retention with our application. At this point we could use Remote Config to alter the UX, Notification Composer to send some form of message or go on to perform A/B testing on improved features for the groups in question.
As you can probably see by now, this new tool allows us to learn even more from our users behaviours than we were previously and in-turn improve on the experiences that we are providing by leveraging the power of machine learning on behalf of Google.
Let’s take a look at what makes up Predictions and how we can get it setup in our app.
Before we can get started with predictions, we need to ensure that our application is using Firebase analytics — this is because Predictions uses events from our analytics tracking to predict when these events will occur. If you’re already using Firebase analytics that’s great, you can move on from this paragraph. Otherwise you’ll need to head over here and set that up in your app.
Note: You’ll need to be sure to enabled data sharing within your firebase projects to be able to use predictions. To do this, head on other to Project Settings within the firebase console and select Share Analytics data for all your apps within your project. If this isn’t enabled, Predictions won’t have access to the required analytical data.
Next, we want to enabled Predictions in our project. We can begin by heading on over to the firebase console and selecting ‘Predictions’ from the left hand panel. At this point, if you haven’t already enabled predictions then you’ll be shown this welcome message to Predictions:
It’s important to note the message here regarding the number of monthly active users. If you’re trying to set this up for a small sample project then you may be waiting some time for results to show up. If your company is already using Firebase analytics, maybe they’ll let you try out Predictions 🙂
To continue, you can go ahead an click the “Yes, I’m in” button. At this point you’ll be shown some default predictions which have been setup for you out of the box. This is also the screen you will come back to when you want to view predictions, alter the risk levels for them or add a new prediction.
At this point you may or may not have data tracked in your project to show some results, if this is the case you’ll just have to sit patiently (or try and get more usage in your app!). However if you do have enough tracked data you’ll notice a percentage value along with a slider. The percentage value here is the number of users in your application that are likely to perform the given event within the next seven days. The slider determines the risk tolerance you want to take when performing actions on your predictions — we’ll come onto that more soon. Hitting the target users button will allow you to perform your desired action on this predicted user group.
These built in predictions alone are already likely to be pretty useful for a lot of applications, these so far include:
- churn — A predicted group of users who are likely to churn
- not_churn — A predicted group of users who are likely not to churn
- spend — A predicted group of users who are likely to spend money with your app
- not_spend — A predicted group of users who are not likely to spend money with your app
However these predictions may not be enough for your application. Thankfully we are able to create out own custom predictions, let’s take a look at how these work.
As well as these built in predictions, it’s also possible to create our own custom ones. At the moment we are only able to create 5 custom predictions, so think wisely about what it is that you want to predict the most! These predictions can be deleted if you wish to create a new one, but it’s important to note that once deleted you will lose all of your prediction data.
You’ll notice the card that allows you to add a prediction, if you go ahead and click that you’ll be presented with the Create Prediction dialog.
At this point you need to fill out 3 things to be able to create your prediction:
- Name — This will be the unique identifier used to recognise your prediction
- Event status — You need to state whether you want to predict the given event will happen or whether it will not happen
- Event — This is the firebase analytics event that you wish to predict
You’ll be able to set this prediction risk tolerance from the predictions home screen on each of the prediction cards.
Whilst the predicted percentage for users completing this event is displayed on the card, this slider will allow you to declare the level of risk that you are willing to take for that percentage stated, which in turn will affect the number of targeted users.
Risk tolerance allows us to decide the level of uncertainty which is allowed to be present within our predictions. I think it’s important to accept that currently results aren’t going to be 100% accurate, but it’s down to us to decide the level of accuracy that we want to proceed with in our apps.
With Predictions we can select either to apply a low, medium or high risk level to our predicted values. The easiest way to understand how this works is to look at an example, so imagine within our app currently we have this ratio of happy & unhappy users:
There are a lot of unhappy users here, the red ones are depicting the users who are predicted to churn. We need to change that, but first we need to decide the risk tolerance which we want to apply to our prediction.
- A high risk tolerance targets a higher number of users than other risk levels. The higher risk tolerance means that we’re willing to take more risk and possibly allow more users to be included in the prediction than we may have originally intended. This will be a trade-off you will need to take as whilst you have a higher chance of including all intended users within the prediction group, you also run the chance of including a higher number of users who shouldn’t be than you would in other risk levels.
- A medium risk tolerance targets a lower number of users than the higher risk tolerance level but still leaves room for potential inaccuracies. So not being as accurate as before paves way for two issues that could arise here — we’d still possibly be including users in our predictions who shouldn’t be there, but at the same time excluding some users who should be. Obviously though this will be a trade-off as we may want to reduce the number of false users within our predicted group over the users who should actually be in there — this will probably vary on a case by case basis.
- A low risk tolerance targets an even lower number of users than both the higher and medium risk tolerance levels, with the intention to potentially clear out any inaccuracies. Whilst it may not clear out all inaccuracies, we have a higher chance of doing so than the other risk levels. However, this risk level means that we may possible miss out on including users in our predictions who should be there — because we’re not willing to take more of a risk on our accuracy, so it is going to be likely that missing out on users here will occur, but that is a trade off which is likely to depend per use case.
As previously mentioned, the risk tolerance will probably depend per use case. For example:
- In cases where discounts are involved, it may be quite important to your business that not too many users receive a 50% off code for subscriptions. For these kind of situations you’re probably going to want to take a lower risk approach to your Prediction action.
- Sometimes your predictions might just be making some feature more dominant within your UI. Depending on the feature, this may not be a big deal if more users see it than you intended. So in these cases you can probably take a higher risk than you would when dealing with the situation stated above.
We can use our Predictions with Firebase Remote Config to remotely configure our application for our generated predicted user group. There are likely many use cases where we may want to do this, for example we may wish to make some part of our upgrade UI more prominent to users who are predicted to not upgrade based off of current actions. Things like this are easily achievable with Remote Config and our predictions are automatically available from Remote Config.
If we head on over to the Remote Config section of the Firebase console and selection the Conditions tab, we can go ahead and create a new condition based on our Prediction.
All we need to do here is give our prediction a name (it might make sense to match the name to the prediction event name) and select the prediction that we wish to apply to the condition. Once created, you can then assign this condition to a parameter value defined within the Parameters section.
If you haven’t used Remote Config for Firebase yet and wish to know more, then you can do so here.
We can use our Predictions with Firebase Notification Composer to send notifications for our application which target our generated predicted user group. There are plenty of use cases where we may want to do this, for example we may wish to alert users who are likely to churn that we’re offering them some money off of upgrades at the moment, or something similar. Things like this are easily achievable with the Notifications Composer and our predictions are automatically available from within the console for this tool.
If we head on over to the Notifications Composer section of the Firebase console we can go ahead and create a new message. When creating your message it’s a good idea to label it with the Prediction name, just so that it is easily identifiable.
All we need to do here is navigate to the Target section and add the condition to target a user segment based on a certain property. For this property we’re going to select Prediction and then choose the prediction that we want to use to target our users.
Once the prediction has been set here, we can continue to compose our notification as we would have done before. If you haven’t used Notification Composer for Firebase yet and wish to know more, then you can do so here.
From what I know so far, Predictions seems to be the start of a powerful new addition to the Firebase suite. Firebase analytics has already allowed us to analyse our users behaviour and make improvements from our own personal predictions and analysis, but now Predictions allows us to utilise machine learning to provide automated predictions that we may be able to trust more than our own. But it is still early days, it’s still in alpha and hasn’t been out long enough for me to have real experience from it, but I’m looking forward to utilising this new tool and learning more from it.