If you’ve visited the Firebase console’s Analytics section recently, you might have noticed something new… an updated Analytics dashboard, a new Realtime view and a few other UI enhancements.
These new changes are part of our effort to improve the Google Analytics experience in Firebase, by providing access to some of the newest Google Analytics 4 innovations directly in the Firebase console.
Firebase now shows a curated collection of Analytics cards that provide the same information as the previous dashboard, but presented more intuitively to get to key insights faster. This matches the ‘App Developer - Firebase’ collection in Google Analytics 4 - meaning you no longer need to switch to the Google Analytics interface to see this data. The cards are now organized by surfacing overview metrics first, followed by user engagement and retention cards, then monetization and user demographics.
The dashboard now also contains a lot of explorer cards that allow you to more easily drill-down into specifics for data represented by that card for more details - like the new App Versions card which provides a quick view into the number of users you have per app version, and a jumpoff link to see more data like engagement rates, revenue and conversions per app version as well.
The Publisher card is another example of providing a more natural flow to learn more about how different ad units are performing as well as the revenue they are generating.
Before adding this card to the dashboard, accessing this information would require digging into specific event reports, like the ad_impression event report to get out the ad unit performance or revenue data. Well, no need to go digging through various event reports anymore with this updated flow that should make accessing this information more convenient and intuitive.
Check out this Google Analytics help center article for more information about the differences between the new and older dashboard cards in the “Data cards before and after” section.
One feature that’s been around in Google Analytics 4 for a while but only just making an appearance in the Firebase console is the Comparisons tool, which replaces what was previously ‘Filters’. Similar to the Filters tool, with the Comparisons tool you can create comparison groups based on any custom or pre-defined Analytics dimensions or audiences. The advantage of the Comparisons tool is that you can create up to five comparison groups at once, and view and compare the Analytics data for each of these groups across all cards on the Analytics dashboard. For example, if you recently ran a promotional campaign offering 10% off in-app purchases to your top purchasers using Remote Config, you can check to see the impact of that at a glance on metrics like user engagement and app revenue by comparing the top purchasers audience, your most engaged users audience, and all users by applying Comparisons in the dashboard.
Note to compare events or conversions as you would have done using Filters in the past, you can navigate to the Events or Conversions card from the dashboard to reveal a detailed report that you can then apply comparisons on.
Check out this article or this video that covers how to use the Comparison tool in more detail.
The Realtime dashboard now shows the same views as in Google Analytics 4 and is great for, well, seeing events come in real-time from around the world. This can be really useful after just releasing a new feature, and seeing new events come in for the first time as it rolls out to your users. The updated dashboard contains new cards and new card capabilities, like the User Acquisition card that can be filtered by source, campaign, medium and platform, as well as the Users card that can now be filtered by audience.
One of the biggest benefits of this new change is the ability to use the Comparisons tool in the Realtime dashboard, too, so you can create and compare different groups over real-time app analytics data.
As part of this change, the Google Analytics settings page now links out to the Google Analytics console where you can modify any Analytics settings as you would previously in the Firebase > Project Settings > Integration > Google Analytics page. The Analytics Linking card however is still available and can be edited from within the Firebase console.
We invite you to take the updated Analytics dashboard in the Firebase console for a spin, and as always, let us know if you have any feedback or questions.
As an app developer, you probably send hundreds of app notifications to users nudging them to try a new game level, complete a purchase, read a new article, or so on. But have you ever wondered what impact those notifications are having on user behavior? Are they actually improving the metrics you care about?
Firebase Cloud Messaging enables you to deliver and receive messages and notifications on Android, iOS, and the web at no cost. Measuring the impact of these notifications is an important but somewhat difficult task to accomplish. Cloud Messaging has always used Google Analytics to count sent notifications, and now, there’s a new way to see other user events related to an open notification across sessions or a longer period of time. Using these events will not only provide more information about the notifications you’re sending to users, they will also enable you to better measure the impact of sending notifications to users.
With analytics labels in Cloud Messaging, you have the ability to pick and apply analytics labels to messages, which Google Analytics can use to track all events related to your notifications beyond just counting sent ones. What is an analytics label? The label is a text string that you can add to any message. For example, let’s say you wanted to see all of the opened notifications for users who signed up in January. You can now do that by attaching a “january” label to your notifications when sending.
You can attach a label for any notification sent via the Firebase Cloud Messaging API as well as for a messaging campaign in Firebase Console. When you set up a Cloud Messaging campaign in the Notifications composer, you can use the dropdown menu in step 4 for Conversion events to choose an analytics label.
This will attach an analytics label to all messages sent as part of this campaign.
After some time has passed, you can get insight into the impact of those messages. Cloud Messaging in Firebase Console has a Reports tab with a graph showing funnel analysis - the number of sends, received, impressions, and opened notifications for a given timeframe. Filtering using an analytics label shows the information for just that label.
Aside from being able to see the impact of labels in Reports, you can use them to perform other specific Google Analytics analyses. For example, perhaps you want to compare how your game play time during winter holidays performed against summertime; you can use comparisons to evaluate metrics like engagement time for those two different messaging campaigns. You can also use the cohort exploration feature to compare user activity, and in fact, you can use the labels as event parameters on the messages for any Google Analytics analyses!
Viewing User Engagement card with label comparisons applied.
Cohort analysis using labeled notification campaign segments.
So there we have it! Using analytics labels in Cloud Messaging, we are able to leverage the full power of Google Analytics to measure the impact of messages sent via the API and Firebase Console!
Hey there, Firebase developers!
Well, Cloud Next 2019 is upon us, and if you happen to be one of the several thousand people descending upon Moscone Center this year and want to get your fill of Firebase knowledge, you're in luck! There are a bunch of great sessions the Firebase team is putting on throughout the conference. And if you want to talk to any of us in person, swing on by the App Dev zone in the expo area. We'll be at the Firebase booth from now until Thursday the 11th.
But if you're not able to make it to beautiful downtown San Francisco this year, never fear! You can still find out everything that's new with Firebase in this blog post, so read on!
For those of you who are Google Cloud Platform customers, we are pleased to announce that the GCP support plan now includes support for Firebase products. This means that if you are using any of the paid GCP support packages, you can get the same high-quality support that you've come to expect from GCP for Firebase products as well. This includes target response times as quick as 15 minutes, technical account management (for enterprise customers), phone support, and much more.
Now if you're not a paying GCP customer, don't worry -- free community support isn't going anywhere. But for many of our larger customers who were interested in a more robust paid support experience, this new option is welcome news. To find out more, you can check out the support pages on the GCP site as well as the Firebase Support Guide.
One of the new GCP products that we announced at this year's Cloud Next is Cloud Run, a fully managed compute platform that lets you run stateless containers which you can invoke via HTTP requests. And we're happy to announce that you can use Cloud Run in conjunction with Firebase Hosting.
Why do you care? Because Firebase Hosting isn't just good for hosting static sites. You can run microservices on top of Hosting as well. In the past, you did this by connecting your Hosting site with Cloud Functions for Firebase, which meant that you had to write all of your code in Node.js. But now that you can deploy stateless servers through Cloud Run and have Hosting talk to them, you can build your microservices in anything from Python to Ruby to Swift.
This is a pretty deep topic which deserves its own blog post, so keep an eye out for that in the next couple of days. Or check out the documentation if you want to get started today.
In the past, you could filter your event reports in Google Analytics for Firebase by a single user property (or audience). So you could quickly answer questions like how many iOS 12 users were signing up for your newsletter. But up until now, you couldn't filter by more than one different user property at once. So if you wanted to find out how many iOS 12 users on iPad Pros were signing up for your newsletter, that wasn't really possible.
Well, we're happy to announce that you'll be able to filter your Analytics event reports by any number of different user properties or audiences -- both ones defined by Firebase as well as custom user properties -- at the same time. So if you want to find out how many iOS 12 users with iPad Pros who prefer dogs over cats signed up for your newsletter, that's now something you can see directly within the Firebase console.
This change is currently rolled out to a small number of users, and will be available to everybody over the next few weeks. This will apply automatically to all of your data going back to December of 2018 when it becomes available, so hop on over to the Firebase console and give it a try!
About 9 months ago ago, we gave developers the ability to create nicer looking domains for their Dynamic Links. So instead of having Dynamic Links with domains that looked like a8bc7w.app.goo.gl, you could set them to something much nicer, like example.page.link.
a8bc7w.app.goo.gl
example.page.link
We improved upon this feature to give you the ability to create dynamic links with any custom domain you own. So if you want to create a link with a domain like www.example.com, this is now something you can do with Dynamic Links.
www.example.com
The one caveat here is that your site needs to be hosted using Firebase Hosting. If migrating your primary domain over to Firebase Hosting isn't feasible, you can easily setup a subdomain of your site instead. For instance, maybe you can't move all of www.example.com to Firebase Hosting, but you could pretty easily set up links.example.com on Firebase Hosting, and use that for your Dynamic Links moving forward.
links.example.com
To find out more about custom domains in Dynamic Links and to get started, make sure to check out the documentation.
Of course, we're always rolling out new features and improvements to the Firebase platform, and with I/O happening just next month, maybe we'll have something more to talk about in May 😉. There's only one way to find out: Attend I/O in person, or keep reading the Firebase blog! (Okay, that's two ways. Counting was never a strong suit of mine.)
Hi, there, Firebase developers! We wanted to let you know about some important changes coming your way from Google Analytics for Firebase that will affect how we help you measure user engagement and sessions. This might also affect any BigQuery queries you might have written, so let's get right into the changes, shall we?
Up until now, sessions were measured using the following formula:
session_start
pseudo_user_id
session_started
With the latest version of the Firebase SDK, we're going to be changing how a session is measured. Specifically:
extend_session
ga_session_id
ga_session_number
In the Firebase console, the biggest change you'll notice is that your app will have more sessions, because we'll be counting instances where users interact with your app for less than ten seconds. This also means that any kind of "average some_event per session" stat will decrease, since the number of sessions is going up.
On the BigQuery side of things, these new event parameters will make your life a whole lot easier. Analyzing anything by session should be really straightforward now -- you just need to group them by ga_session_id. So calculating your own "average xxx per session" values will be a lot easier in BigQuery.
For example, here's a query where we calculate how many level_complete_quickplay events an average user generates per session:
level_complete_quickplay
SELECT AVG(total_quickplays) as average_quickplays_per_session FROM ( SELECT COUNT(event_name) as total_quickplays, (SELECT value.string_value FROM UNNEST (event_params) WHERE key = "ga_session_id") as session_id FROM `firebase-public-project.analytics_153293282.events_xxxxxxxx` WHERE event_name = "level_complete_quickplay" GROUP BY session_id HAVING session_id IS NOT NULL )
And if you want to figure out, say, how many sessions it typically takes before somebody makes a purchase, you can do that by analyzing the ga_session_number parameter.
In the past, Firebase measured total user engagement by recording the amount of time your user spent with the app in the foreground and then sending down those values (as incremental measurements) as user_engagement events. You could then calculate the total amount of time a user spent within your app by adding up the values of the engagement_time_msec parameter that were sent with each of these events.
user_engagement
engagement_time_msec
These user_engagement events were typically sent when a user a) Sent your app into the background, b) Switched screens, c) Crashed, or d) Used your app for an hour. As a result, it was very common to see user_engagement events sent alongside events like app_exception or screen_view events. To the point where we asked ourselves, "Why are we sending down all these extra events? Why not just send engagement time as a parameter with these other events we're already generating?"
app_exception
screen_view
And so that's exactly what we're going to do, starting in early 2019. You will still occasionally see separate user_engagement events, but you will also start seeing engagement_time_msec parameters added to other events automatically generated by Google Analytics for Firebase. We're going to start with screen_view, first_open and app_exception events, but you might see them added to other events in the future.
screen_view, first_open
On the Firebase console, nothing should change. Your app might end up using a little less data, since you're no longer sending down so many separate user_engagement events, but otherwise, nothing else should look different.
On the BigQuery side of things, you'll need to alter your queries slightly if you were calculating important metrics by filtering for user_engagement events. If you were, you'll need to alter those queries by looking for events that contain an engagement_time_msec parameter.
For example, here's a query that calculates the total user_engagement time for each user by summing up the engagement_time_msec parameter for user_engagement events. This might work today, but it will be inaccurate in the future.
SELECT SUM(engagement_time) AS total_user_engagement FROM ( SELECT user_pseudo_id, (SELECT value.int_value FROM UNNEST(event_params) WHERE key = "engagement_time_msec") AS engagement_time FROM `firebase-public-project.analytics_153293282.events_20181003` WHERE event_name = "user_engagement" ) GROUP BY user_pseudo_id
So here's that same query, modified to look for all events that might have a engagement_time_msec parameter
SELECT SUM(engagement_time) AS total_user_engagement FROM ( SELECT user_pseudo_id, (SELECT value.int_value FROM UNNEST(event_params) WHERE key = "engagement_time_msec") AS engagement_time FROM `firebase-public-project.analytics_153293282.events_20181003` ) WHERE engagement_time > 0 GROUP BY user_pseudo_id
The nice thing about that second query is that it works both with the old way of measuring user engagement and the new one, so you can modify your BigQuery queries today, and everything will still work just fine when the new changes go into effect.
Update: Well, it took a little longer than planned, but this feature launched in April of 2020. If you've been using this second BigQuery query all along, then congratulations! Everything should continue working as before. If not, well, there's no better time to switch over.
We hope that these changes make your life a little easier in the long run, and offer only a minimal amount of disruption in the short term. In the meantime, if you have any questions, feel free to reach out on StackOverflow, or any of our official support forums.
Happy analyzing!
Last year at Firebase Summit, we introduced you to Predictions, a machine learning product that helps you smartly segment your users based on their predicted future behavior. Without requiring anyone on your app team to have ML expertise, Predictions gives you insight into which segments of users are likely to churn or spend (or complete another conversion event) so you can make informed product decisions and grow your app.
As of today, Predictions makes more than 6 billion predictions per day for our developers and allows them to take meaningful actions by making predictive segments available for targeting in Remote Config, Cloud Messaging, In-App Messaging, and A/B Testing.
This year at Firebase Summit, we announced that Predictions has graduated out of beta and into general availability with a host of new features that we added based on your feedback.
Since Predictions continuously update based on actual user behavior inside your app, we heard from many of you that you wanted to know how stable a prediction was before you integrate it into your app.
To help answer this question, we created a health indicator at the bottom of each predictive segment card that gives you a snapshot of how a certain prediction is performing:
Image 1: Green means it has been performing consistently well over the last two weeks
Image 2: Yellow means it is performing well today but did not meet the quality threshold some time in the past two weeks
Image 3: Red means it is not performing well today and had other performance issues over the last two weeks
It is worth mentioning that actions targeted with Predictions have a fail-safe mechanism, so if a predictive segment is performing poorly, it simply turns inactive. That means, if you are using Remote Config to deliver a set of values to users in that predicted group, Remote Config will gracefully fall back to your default values if the predictive segment decreases in reliability. Any notifications or in-app messages directed at that predictive segment will also not trigger until the predictive segment increases in accuracy.
To help you understand how we assess the quality of a prediction, we are now exposing our evaluation criteria. For every predictive segment, we use a portion of your historical data from the last 28 days that we hold out during the model training phase.
We then compare the results of the prediction to what actually happened. This gives us two ways to score the prediction: how many of the users in the predictive segment actually behaved in the predicted way (we call that true positive rate) and how many users in the predictive segment were incorrectly classified (or in more technical terms, the false positive rate).
You can access this data from the bottom of the prediction card
Tapping on the health indicator exposes these values.
By exposing these two scores to you, you can now make a better determination about which risk profile to choose for your action.
Another common question we received during our beta phase is what went into creating a predictive segment. We now offer a details page that gives you the ingredient list! You can click through and see what data our model makes use of. This includes event frequency, volume, and parameters as well as other data like device language, freshness of app install and more.
The last thing we are excited to announce is that now, you can export your raw predictions data into BigQuery. This will give you access to the raw prediction score, the thresholds we used for each risk profile, as well as the final result. You can use this data to create your own risk profiles or if you supply your own user_id property in analytics, to do sophisticated analysis with your analytics data. For example, you can find out which countries exhibit the highest potential to churn or spend!
We are humbled to have gained your trust over the past year and hope these improvements make it easier for you to make the most out of Predictions in your mobile apps and games. As always, if you have any questions, you can find us on Twitter (@firebase) and on Stack Overflow.
For more information on these updates, check out our docs below!
Predictions risk tolerance and performance
Predictions model inputs and details page
Predictions data export to BigQuery
MightySignal, a mobile intelligence startup based out of San Francisco, just published a new report examining the fastest growing Android SDKs of 2017. This fascinating report sheds light on which app development tools are taking off and what trends they signal for the year ahead. We're humbled and excited to see that 8 out of the top 20 fastest growing SDKs are part of Firebase!
This positive reception from the community validates and fuels our commitment to helping developers succeed. It also motivates us to continue making Firebase even better. Over the past year, we've made numerous improvements to our SDKs, including the ones highlighted in MightySignal's report.
Source: MightySignal's 2017 report on the fastest growing SDKs
For example, Firebase Realtime Database is number three on MightySignal's list, and it continues to be one of our most used and trusted products. We understand how important storing and syncing data is for your mobile business, and to further help you with this, we introduced another database product this year. If you're a Realtime Database customer, we think you'll love Cloud Firestore, our latest realtime, scalable NoSQL database that we built in collaboration with the Google Cloud Platform team. It allows you to sync and store data like Realtime Database, while also addressing its key limitations like data structuring, querying, and scaling. Cloud Firestore is available in beta today!
Another notable mention is Firebase Remote Config. Remote Config gives you the power to customize your app's interface and behavior for different audiences so you can deliver personalized app experiences without requiring users to update their apps. Now, Remote Config can be used with Firebase Predictions' dynamic user groups. This means you can change the look and feel of your app for users based on their predicted behavior (such as churn or in-app purchase). Wondering how this works? Learn how Halfbrick Studios grew their 7-day retention rate from 25% to 30% by combining Predictions with Remote Config.
And that's not all that's new with Remote Config! In the past, Remote Config allowed you to perform simple A/B testing, but now, we've gone ahead and added an entirely new experiment layer in Firebase that works wonderfully with Remote Config so you can set up, run, and measure sophisticated A/B tests.
We were also delighted to see that Firebase Auth and Firebase Crash Reporting are experiencing high growth as well, according to MightySignal's findings. After welcoming the Fabric team to Firebase, we worked together to add new features to Auth (such as phone number authentication), which we unveiled in June. More recently, we launched a beta version of Firebase Crashlytics, a powerful realtime crash reporting tool that will help you track, prioritize, and fix issues that erode app stability. Firebase Crashlytics is now our primary crash reporter. If you want to learn more about how app stability can lead to growth in user engagement and retention, check out how Doodle used Crashlytics to grow user engagement by 42%.
MightySignal's data on the fastest growing SDKs is available here. We're very thankful to be part of the developer community and committed to helping you build better apps and grow your business. Stay tuned for more product updates next year and, in the meantime, happy building!
When the folks at Fabric joined Firebase earlier this year, we aligned around a common mission: provide developers like you with a platform that solves common problems across the app development lifecycle, so you can focus on building an awesome user experience.
One area — among many — where Fabric excelled was in its console and dashboards. We've been hard at work for the last several months, working with them to bring together the best parts of Fabric and Firebase. Today, we're excited to share some improvements to the Firebase console.
We started by redesigning the navigation, to more accurately reflect the way your team works. We've clustered Firebase products into four groups: Develop, Stability, Analytics, and Grow. All of the products that you're used to seeing in the Firebase console are still there; we've simply reorganized them in a way that makes it simpler to navigate between them as you use more products across the Firebase platform.
We've also redesigned the Project Home screen in the Firebase console to bring a few important metrics front and center. Now, when you first open a project in Firebase, you'll see four key metrics: 30-day crash-free user rate, 30-day crashes, daily active users, and monthly active users, along with graphs that displays these trends over time. In research, we found that the vast majority of the time, developers are looking for one of those four metrics, so we made them easily accessible from the Project Home landing page.
Another well-loved Fabric console feature is the Latest Release section. This dashboard gives you all the most important insights from your most recent app release, so you can get a quick snapshot of what's going well and what might need to be rolled back. We've brought this section into the redesigned Firebase Console; you'll find it under the Analytics section of the navigation bar.
Starting today, you'll also see an Analytics dashboard that is organized into simple cards underneath an easy to understand question. Organizing data around jargon like "DAUs" or "retention cohorts" is difficult to navigate, so we've restructured the dashboard around questions you have about your app, like "where are my users engaged?" Or "how well do I retain users?" Our research confirmed that 90% of users preferred this design and we hope you find it helpful too!
Another thing we've learned from our friends at Fabric and heard from all of you is that having information in realtime is critical. Whether you're tracking a new app release or monitoring the status of a bug fix, you need to understand what's happening in your app in realtime, so you can make changes and prioritize work accordingly.
To help with this, we've added realtime data on crashes and active users to a card that you'll see in the new Analytics dashboard, as well as the Latest Release section of the console. This is just the first step and, over time, we plan to make realtime data more prevalent across the rest of the Firebase console.
As always, you can contact us at https://firebase.google.com/support/ with feedback and questions. Happy building!
If you're like most app developers, you know that small changes can often make a big difference in the long term success of your app. Whether it's the wording that goes into your "Purchase" button, the order in which dialogs appear in your sign-up flow, or how difficult you've made a particular level of a game, that attention to detail can often make the difference between an app that hits the top charts, or one that languishes.
But how do you know you've made the right changes? You can certainly make some educated guesses, ask friends, or run focus groups. But often, the best way to find out how your users will react to changes within your app is to simply try out those changes and see for yourself. And that's the idea behind A/B testing; it lets you release two (or more!) versions of your app simultaneously among randomly selected users to find out which version truly is more successful at getting the results you want.
And while Firebase Remote Config did allow you to perform some simple A/B testing through its "random percentile" condition, we've gone ahead and added an entirely new experiment layer in Firebase that works with Remote Config and notifications to make it quick and easy to set up and measure sophisticated A/B tests. Let's take a quick tour of how it works!
With the new A/B testing feature, you can create an A/B test that will allow you to play with any combination of values that you can control through Remote Config. Setting up an A/B test allows you to define how the experiment will behave in a number of different ways, including determining how many of your users are involved with the experiment at first…
…how many variants you want to run, and how your app might behave differently for each variant…
...and what the goal of the experiment is.
Different experiments might have different desired goals, and A/B testing supports a number of common outcomes, like increasing overall revenue or retention in your app, reducing the number of crashes, or increasing the occurrence of any event you're measuring in Google Analytics for Firebase, such as finishing your in-app tutorial.
Once you've defined your A/B test, Firebase takes over by delivering these different variations of your app to randomly-selected members of your audience. Firebase will then measure your users' behavior over time, and let you know when an experiment appears to be performing better, based on those goals you've defined earlier. Firebase A/B testing measures these results for you with the same Bayesian statistical models that power Google Optimize, Google's free testing and personalization product for websites.
Fabulous, a motivational app for building better habits, recently made improvements to their app's onboarding flow by using Firebase A/B testing. When the user first starts an app, Fabulous shows them how to complete a habit, presents them with a letter about forming better habits, and then asks them to commit to a simple routine. The team suspected that if they removed a few steps from this onboarding process, more people might complete it.
Some of the screens a typical user encounters when first using Fabulous
So they ran an A/B test where some users didn't see the letter, others didn't see the request to commit to a simple routine, and others skipped both of those steps. The Fabulous team found that by removing both of these steps from the onboarding process, there was a 7% improvement in the rate of users completing the onboarding flow. More importantly, they confirmed that this shorter onboarding experience didn't have any negative impact on their app's retention.
You also have the ability to A/B test your app notification messages through the Firebase Notifications console. You can try out different versions of your notification message and see which ones lead to more users opening up your app from that notification, or which messages lead to users performing some intended goal within your app, like making a purchase.
A/B testing is available in beta to all Firebase developers starting today. If you're excited to get started, you should make sure that your app is wired up to use Remote Config and/or Firebase Cloud Messaging, and that you've updated these libraries to the latest and greatest versions. You can always find out more about A/B testing in our documentation, or check out the A/B Test Like a Pro video series we've been building.
Then, head on over to the Firebase Console and start making your app better — one experiment at a time!
We're delighted to announce the beta launch of Firebase Predictions. With this we are bringing the power of Google's machine learning systems to every developer that uses Firebase. Predictions is a product that can build dynamic user groups based on predicted behavior, determined using a machine learned model, and these user groups can then be targeted using Firebase Cloud Messaging, Remote Config and other technologies. User groups are updated daily to keep your predictions fresh.
Out of the box, there are four predicted groups:
You'll see these three groups right away when you select Predictions in the left nav bar of Firebase Console.
You'll notice that each of these cards has actions that you can take upon them.
Tolerance: The tolerance slider gives you the ability to tolerate low, medium or high risk of false positives. So, with a low tolerance, your population of users will be smaller, but so also will your risk of false positives. Similarly, with a high tolerance, you'll have a larger population of users, but at a risk of some of them being false positives. In the case of 'churn', a false positive would be a user who is predicted to churn, but in fact continues to use your app.
Target Users: This gives you a drop-down on which you can select Remote Config or Notifications for that user group. It also links to some handy guidance for offering in-app incentives.
Selecting Remote Config will take you to a new screen where you can specify the remote config parameter that you want to set up, and then the value for it for that population. So, for example if you've been building a game, and a lot of people have churned and you see from feedback that it's too difficult to play, you could set a remote config variable for the difficulty, so that likely churners could get a lower default value set for them, and thus would have an easier experience playing the game.
Selecting Notifications will take you to the familiar composer for messages to be sent using Firebase Cloud Messaging, but in addition to the usual options for picking target audience, you'll also get the predicted user group pre-populated as a user segment.
This allows you to target notifications at that user group. So, for example, for users at a risk of churning, you could send a notification with an enticement to continue using the app.
Creating your own predictions. You aren't limited to the built-in predictions cards, of course, and can create your own based on custom events that you set up in your app. In this case, you'll see a card that allows you to create a prediction.
And when you select it, you can then create a prediction for when your event will, or will not happen. This helps you identify users who are likely to engage in that conversion event:
So, for example, in the above case, whenever a user levels up in the game, the level_up conversion event is logged. Thus, you could create a prediction for players who may level up, and incentivize them to continue playing.
Then, once you've saved your prediction, over time a card will populate on the Firebase Console in the same way as the built-in ones.
And this card can be used in the same way as the others -- including targeting users with notifications and Remote Config.
Firebase Predictions is a Beta product, and we're continuing to work on it and improve it. If you have any questions or feedback, please reach out -- and for bugs and product suggestions, you can reach us at firebase.google.com/support.
Learn more about Firebase Predictions at firebase.google.com/products/predictions/ or dive straight into our docs right here.
Here at Firebase, we know that the first step in making improvements in your app is knowing how your users are interacting with it: what parts they love, where they're having trouble, and what features are sadly underutilized. This is why we built Google Analytics for Firebase from the ground up to be a complete mobile analytics solution, with free and unlimited app analytics designed specifically for the way mobile apps are built.
Now, if you were paying close attention to the last paragraph, you may have noticed that the product formerly known as Firebase Analytics is now called "Google Analytics for Firebase." Don't worry; it's the same analytics product you know and love -- and we'll talk more about the name change in a bit.
Over the last year, we've made a number of improvements to Google Analytics for Firebase, including adding StreamView, which gives you an impression of how users are interacting with your app at this very moment, and DebugView, which allows you to see in precise detail what analytics events (and errors!) might be happening on a test device.
This year at Google I/O, we were thrilled to announce a number of new improvements and enhancements that make using analytics even better. In case you missed those presentations (which you can also watch on YouTube), let's give you a quick summary of what's new with Google Analytics for Firebase.
With Google Analytics for Firebase, you're allowed to submit up to 25 custom parameters alongside any events that you record in your app. For instance, if you were submitting a end_of_round event in a game, you could submit a user_score or premium_coins_earned parameter along with that event. By analyzing these different parameter values, you could then ensure that your game had the high score distribution or general payout rate that you were expecting.
end_of_round
user_score
premium_coins_earned
But up until now, it's been impossible to see the results of most of these custom event parameters without first exporting your data to BigQuery and doing the analysis there. Being able to view summaries of these event parameters directly in the Firebase console has been our most common feature request since analytics first launched last year. So we're very pleased to announce that we've taken our first big steps in making these reports available to you.
To get started with custom event parameters in Firebase, you'll need to let Google Analytics for Firebase know what parameters you're interested in. You can do this by going to the specific event in the Firebase console and clicking the "Add event parameters" button in the interface. From there, you can specify a parameter, note whether it's a number or a string, and add units of measurement, if applicable.
Once you've done that, you'll start seeing these parameter summaries directly in the console. We'll show you sums and averages for numeric values, and a list of your most popular values for strings.
Like other analytics reports available in Google Analytics for Firebase, you can filter these reports by user properties or audiences to get a better sense of how different users are interacting with your app in different ways.
Currently, you can specify up to 50 different event parameters for which you'd like to generate summary reports.
Of course, if you want to analyze a greater number of custom event parameters, or want to do more sophisticated analysis than what's available from the Firebase console, you can export your Google Analytics data directly into BigQuery, Google's data warehouse in the cloud. Analyzing your data in BigQuery is a very powerful way of running all sorts of ad hoc queries or custom analysis on your data, and we want to encourage all our developers to try it out.
To assist you on your journey, we've now added a free tier of storage in BigQuery -- 10 GB of data to be exact -- for every project using Google Analytics for Firebase. Combine this free storage tier with the 1 TB of free monthly query usage that you get from BigQuery, and you can do an awful lot of BigQuery analysis for a relatively little amount of money. And with the new analytics report templates in Data Studio, making stylish reports on custom parameters (or anything else you can measure in BigQuery) is a cinch.
We've made some major enhancements in the way Firebase and AdMob communicate with each other. Much like milk and cookies1, mixing Firebase and AdMob together results in an exciting new flavor combination that complements the strengths of both products!
By linking your AdMob account to Firebase, your app will automatically record analytics events associated with AdMob (along with mediated ad units) just like any other analytics event. This gives Google Analytics for Firebase the ability to create reports on ad impressions, clicks, and exposure time, broken down by important characteristics such as screen, ad format or ad unit. This makes it easier than ever before to see which ads are most effective in your app, where you're earning the most ad dollars, or which ads your users spend the most time viewing.
Linking your AdMob and Firebase accounts together also gives you a more complete picture of where you're making money in your app. Both the APRU reports on the dashboard and the Lifetime Value metrics in the Attribution reports will now include revenue generated from AdMob advertising, as well as in-app purchases.
This can help you gain a much more complete understanding of how your app is doing from a revenue standpoint, and help you more accurately gauge which growth campaigns are bringing you users who are earning you the most revenue.
If, like me, you enjoy spending your free time reading the latest Firebase Release Notes, you might have noticed that a few months ago, Firebase started adding screen tracking support to the events that it was recording. This month, we're taking the first steps towards adding screen tracking reports in Google Analytics for Firebase, by showing you the top three screens your users are spending time on. You can find this information in the User Engagement section of the Firebase Dashboard.
Screen tracking reporting works behind the scenes by automatically logging a screen_view event whenever a screen transition occurs. These events are then combined on the server to paint a more complete picture of the user's journey throughout your app. And just like any other event, you can view them in StreamView or DebugView, or analyze them through BigQuery. If you would like to customize these events -- for instance, you're a game developer who has multiple "screens" all within the same ViewController -- you can do so with by setting these events manually on the client.
You can already use Google Analytics for Firebase for attribution tracking, which helps you learn not just which ad networks are sending you users, but which ones are sending you valuable users that you care about the most. And we're pleased to announce a new integration with DoubleClick Digital Marketing that will include attribution tracking for DoubleClick Campaign Manager and Bid Manager. Add this to the 50+ third-party advertising networks (and growing!) that we've integrated into our system, and Firebase can help you make better decisions around where to spend your advertising dollars with true cross-network attribution data.
If you're using the old Google Analytics Services SDK in your existing apps, don't worry; it's not going anywhere. But we encourage you to start adding the Firebase SDK in future releases. Using the Firebase SDK will give you access to the latest reports in Google Analytics for Firebase and to new functionality as it becomes available. If you're a long-time Google Analytics fan, you can use Google Tag Manager to automatically send your events data to those reports as well. If you need more help on this topic, we wrote a blog post a few months back that covers a few strategies on how to get both these analytics libraries working together in your app. Give it a read sometime!
We're thrilled to be bringing you these improvements to Google Analytics for Firebase -- they should be already available in the Give it a read sometime today (check out the demo project for an example!). If you haven't yet added analytics to your product, you can find all the documentation you need here to get started. Give it a try, and let us know what you think!
1. Or chili and mango, which Steve Ganem assures me is delicious, but sounds weird to me.↩
