This article is part of the weekly learning pathways we’re releasing leading up to Firebase Summit. See the full pathway and register for the summit here.
When you send a push notification to your users, things can go wrong in many places: the network might be down, the device might have performance issues or the send request might be invalid. And each platform has its own complexity so the challenges can keep adding up. All of this makes it difficult to know whether your notifications actually got delivered to users.
To get a better understanding of whether your notifications were delivered and where things might have gone wrong, you need one central place to collect all information and then run an analysis. This is where BigQuery can help. BigQuery, Google's solution for building data warehouses, gives you the ability to run queries and build custom dashboards that provide deep insights and actionable information.
With the Firebase Cloud Messaging Android SDK, you can log notification delivery data and export it to BigQuery. We recently expanded the same support for iOS and the web. In this article, we will walk you through the process of setting this up so you can better understand your delivery rate and identify ways to troubleshoot or improve it.
First, you need to enable BigQuery for your Firebase project. You can do this by navigating to the Firebase console > Project Settings > Integrations, and then click Link on the BigQuery card. It's worth noting that, by default, this integration uses the BigQuery sandbox. This lets you explore BigQuery capabilities at no cost, so you can evaluate if it fits your use case. After you link your Firebase project to BigQuery, Firebase will export your data to BigQuery. The initial propagation of data might take up to 48 hours to complete.
Once the data is successfully exported, you should be able to see a data table created under your project’s firebase_messaging tab in the BigQuery console.
data
firebase_messaging
To collect Notification Delivery data, you need to enable logging on the client side. In the next step, we're going to set up the iOS client and start logging some data to BigQuery.
With the Firebase Messaging iOS SDK 8.6.0 or higher, you can now enable notification delivery logging in your app that exports to BigQuery by calling a new API we recently added. You will need to log alert and background notifications separately (this is only required for Apple's platforms).
Alert notifications and Notification Service Extension
To log alert notifications delivery, you first need to add a Notification Service Extension to your project in Xcode. The Notification Service Extension lets you customize the content of notifications before they become visible to users. Apple’s developer documentation has more details about how to add a service extension to your project.
After adding the Notification Service Extension to your project, find the NotificationService didReceiveNotificationRequest:withContentHandler: method inside the service extension target. This is where you will add code to enable logging.
NotificationService didReceiveNotificationRequest:withContentHandler:
In Firebase 8.6.0, We have introduced a new method to the Firebase Messaging API: the delivery data export API FIRMessagingExtensionHelper exportDeliveryMetricsToBigQueryWithMessageInfo:. Logging is disabled by default, so you will need to explicitly enable it by calling this API inside the Notification Service Extension.
FIRMessagingExtensionHelper exportDeliveryMetricsToBigQueryWithMessageInfo:
override func didReceive(_ request: UNNotificationRequest, withContentHandler contentHandler: @escaping (UNNotificationContent) -> Void) { self.contentHandler = contentHandler bestAttemptContent = (request.content.mutableCopy() as? UNMutableNotificationContent) if let bestAttemptContent = bestAttemptContent { // Modify the notification content here... bestAttemptContent.title = "\(bestAttemptContent.title) 👩🏻💻" // Log Delivery signals and export to BigQuery. Messaging.serviceExtension() .exportDeliveryMetricsToBigQuery(withMessageInfo: request.content.userInfo) // Add image, call this last to finish with the content handler. Messaging.serviceExtension() .populateNotificationContent(bestAttemptContent, withContentHandler: contentHandler) } }
Note that, if you use the Firebase Cloud Messaging SDK to add an image to your notification, you need to make sure to call the deliver data export API before calling Messaging.serviceExtension().populateNotificationContent(_:withContentHandler), as shown in the code snippet above.
Messaging.serviceExtension().populateNotificationContent(_:withContentHandler)
The Apple system only passes the notification to the service extension if the notification payload contains the key "mutable-content" :1, so make sure you specify this key if you use the HTTP v1 API. If you use the Firebase console to send notifications, "mutable-content" :1 will be set automatically.
"mutable-content" :1
Background notifications
Background notifications are hidden messages that allow your app to wake up and update data in the background. To enable delivery data export for these kinds of notifications, you will need to implement the application:didReceiveRemoteNotification:fetchCompletionHandler: method and call exportDeliveryMetricsToBigQueryWithMessageInfo: method as shown below:
application:didReceiveRemoteNotification:fetchCompletionHandler:
exportDeliveryMetricsToBigQueryWithMessageInfo:
// For background notifications, call the API inside the UIApplicationDelegate method: func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any]) { Messaging.extensionHelper().exportDeliveryMetricsToBigQuery(withMessageInfo:userInfo) }
Make sure to include "content-available":1 to specify it’s a background notification when you use the HTTP v1 API to send the notification.
"content-available":1
Notification Delivery Logging is newly available on the web for Firebase JS SDK versions 9.0.0 and newer. To enable delivery data export, all you need to do is to enable the flag on a service worker as shown below. This is handled similarly to Android.
// userConsent holds the decision of the user to give big query export consent. const userConsent = ...; const messaging = getMessagingInSw(app); experimentalSetDeliveryMetricsExportedToBigQueryEnabled(messaging, userConsent)
Notification Delivery Logging has been supported on Android since Firebase SDKs version 20.1.0 or higher. On Android, you can call the delivery data logging API to enable data export for both display and data messages like this:
FirebaseMessaging.getInstance().setDeliveryMetricsExportToBigQuery(true)
By default, Notification Delivery Logging is disabled on all three platforms, and will only be activated once you call the API to enable it for the particular platform your app is running on. You can also deactivate the BigQuery export any time by unlinking your project in the Firebase console.
Results on BigQuery
Once you have successfully logged some data you will see this data in the BigQuery console. Keep in mind that the data is regularly pushed from Firebase to BigQuery and the daily propagation might take some time (up to a couple of hours, depending on the amount of data) to complete.
BigQuery data also includes customized analytics labels that help you to create custom queries. Here’s a preview what type of data you can get from the iOS platform:
With the delivery data on BigQuery, you can now run custom queries or build a customized dashboard based on your needs. It provides detailed information about your campaign, including message identifier, message type, SDK platform and timestamp so you can get a lot of useful information helping you identify if the message was sent as expected. You can also segment the data based on your custom analytics labels. And if you are interested in getting additional aggregate information about message delivery on Android, check out this Medium post to find out how to use FCM Aggregation API for advanced data analysis.
View the full learning pathway on FCM message delivery for additional codelabs, videos and articles. And don’t forget to register for Firebase Summit and join us on November 10th to learn how Firebase can help you accelerate your app development, release with confidence and scale with ease!
Over the past few months, we’ve seen that apps not only improve the way we live, they also enhance our ability to adapt to change. In 2020, more businesses and families have turned to apps to stay connected, productive, and entertained. At the same time, our developer community has stepped up to build and scale the apps people are relying on. Our team, alongside the rest of Google, has strived to be supportive in this moment. Our mission is to help you succeed by making it easy to build and operate apps.
Last year, we shared that 2 million apps actively use Firebase every month. Now, that number has grown to over 2.5 million monthly active apps, which includes global businesses like Gameloft and Alibaba, as well as innovative startups like Classkick. Classkick is a full-spectrum learning platform with a backend powered by our Realtime Database and supported by Google Cloud. When the COVID-19 pandemic forced schools to close, Classkick onboarded thousands of teachers and school administrators to their platform. With Firebase, they were able to scale to meet this new demand so students could continue to learn effectively from home and stay engaged with their teachers and classmates.
Classkick is helping students learn effectively from home
Classkick is just one example from our incredible community of how apps are helping people adapt to their new surroundings. It’s stories like these that inspire us to keep making Firebase better. Every year at Firebase Summit, we share updates on how we can help you accelerate app development, run your app efficiently, and tailor Firebase to suit your needs. Read on to learn what’s new at our digital Firebase Summit 2020, and view the sessions and resources on our summit website.
We’re continuing to invest in tools that speed up your app development so you can deliver value to your users in less time.
Introducing the Authentication emulator for rapid iteration and local development
Last year, we launched the Firebase Emulator Suite to let you run emulated versions of our backend products for a faster and safer development experience. A few months ago, we introduced you to the local emulator UI, which makes it possible to run services locally via a web app with a distinguishable UI, and comes with features like advanced data editing and searching. The Emulator Suite supports Hosting, Realtime Database, Firestore, Cloud Functions, and Cloud Pub/Sub - and now, we’ve added support for Firebase Authentication.
The Emulator Suite now includes support for Authentication
This means you can test the entire user management process - from user creation to Function trigger to sending updates to Firestore, and even fuzzy log searches to debug interactions between the emulators and your application - on your local machine. You can also use the new auth emulator to run integration tests that rely on authentication. The Emulator Suite, now with Firebase Authentication, allows you to shift to a local-first developer workflow so you can experiment and rapidly iterate without touching production data, incurring costs, or worrying that you’ll break something. Check out our documentation to get started.
New Hosting preview channels let you see changes before publishing
Web development can be cumbersome and complicated. With Firebase Hosting, you can deploy secure, fast-loading web apps and landing pages that are backed by a global CDN in less time, and with less hassle. Recently, we added new features that many of you have been asking for, including an integration with Cloud Logging to give you more server-side analytics, support for Brotli compression to boost your site performance, and improved support for localized content.
Our latest update to Firebase Hosting, preview channels, lets you see your changes before publishing them to your site. Now, you can deploy changes to a preview channel in seconds with a single command and generate an obscured unique URL to share with your team. Preview channels not only let you check that your changes look as intended right away, they also make collaboration quicker and easier even if you’re working across a distributed team. Try them out today!
Hosting’s new preview channels let you see changes before publishing
More Extensions for adding features and functionality
At last year’s Firebase Summit, we launched Firebase Extensions; pre-packaged solutions that automate common tasks in your projects and let you add new functionality in fewer steps. Since then, we’ve partnered with Stripe to release the Send Invoices using Stripe and the Run Subscription Payments with Stripe extensions. These extensions let you integrate the Stripe payments platform with Firebase without requiring you to learn Stripe’s API.
Today, we’re sharing a preview of another extension through our Alpha Program, called Detect Online Presence. Detect Online Presence shows you which users or devices are currently online and stores that data in Cloud Firestore. If you’re developing a game or a social app, you can use this extension to let your users know when their friends are online for a friendly match or chat. Join our Alpha Program to try it out!
Detect Online Presence is our newest Firebase Extension, available in Alpha
In addition to accelerating app development, Firebase provides actionable data so you can optimize your app - and ultimately, keep users happy.
Redesigned Performance Monitoring dashboard to help you focus on critical metrics
Any time you release a new version of your app, it’s important to pay attention to stability and performance metrics to ensure your users have a fast, high-quality experience. Firebase Performance Monitoring gathers and presents data about your app’s performance to show you exactly what’s happening in your app - and when users are encountering slowness. But sometimes, there’s so much information, it can be hard to focus on what’s important.
To help you hone in on key insights, we’re excited to unveil the redesigned Performance Monitoring dashboard. This new dashboard makes it crystal clear if one of your critical metrics needs attention so that you can take action, and it’s customizable, allowing you to bring the metrics you care about most to the forefront. We’ve made this dashboard available to everyone - just head on over to the console and add the metrics that matter to you.
The redesigned Performance Monitoring dashboard brings critical metrics to the forefront
New organizational and targeting tools for Remote Config
As people start using your app, you’ll want to delight them with new features, promotions, and personalization so they stick around. With Firebase Remote Config, you can dynamically alter your app, safely test and release new features, and stay in control of the whole experience - without having to publish a new version. However, as your project gets bigger, it might become hard to maintain and navigate through your app config. Over the past few months, we’ve added new features to help you better organize, visualize, and target your parameters so you can manage your app config more efficiently.
First, we added information about experiments into the Remote Config dashboard and launched parameter groups. Then, we made it possible to sort parameters alphabetically and enhanced the search tool. On top of that, we improved version targeting by making it available for iOS and adding support for semantic versioning, so you can use numeric operators like “>=” to target specific app versions without resorting to complicated regular expressions.
Improved version targeting in Remote Config
Most recently, we launched config metrics to give you more visibility into how your app configuration is behaving for users so you can find and fix incorrect configurations quickly. These config metrics include realtime fetch requests, which allow you to monitor rollouts of a new set of values, and fetch percentages, which show you the distribution of parameter values across users. For example, when you see a smaller fetch percentage for a condition than expected, it signals that the wrong users may be exposed to the intended values.
Real-time config metrics for Remote Config
When your app and business grow, your development challenges may become more complex. We’re working to give you automation capabilities, such as Crashlytics BigQuery streaming, and more control and flexibility so you can adapt Firebase to fit your sophisticated needs.
New Google Analytics APIs for better data management
One of the key factors in scaling a successful app is knowing how your users are interacting with it. Our robust integration with Google Analytics helps you understand what actions users are taking inside your app, where they're spending their time, and why they churn -- so you can make smarter decisions. Last year, we announced a significant new upgrade in Google Analytics that gave you a single view of customer engagement across both native apps and web-powered ones. Since then, we’ve added new features like the setDefaultEventParameters and powerful new ecommerce measurement, which you can read about in this blog post.
Today, we're excited to announce three new APIs that give you more control so you can collect, record, and manage your data in a way that suits your growing business. The first one, the Google Analytics 4 Measurement Protocol, lets you log events directly to Google Analytics. This is especially useful for developers who want to augment their client-side data with server-to-server calls to gain new insights. For those of you who want to create your own custom dashboards, the Data API, which is the second new API, gives you programmatic access to your Google Analytics reporting data. Finally, the Admin API gives you the ability to configure your Analytics account and set user permissions.
Google Analytics 4 Measurement Protocol lets you log events directly to Google Analytics
Introducing imported segments for increased targeting flexibility
Over the years, we’ve seen many of you take advantage of our BigQuery integration by exporting data from Firebase, joining it with data from other channels, running sophisticated analysis - and even creating your own custom user segments in BigQuery. Now, we’re giving you the power to bring these custom segments back from BigQuery into Firebase with the launch of imported segments! This means you can target any custom segment with products like Remote Config, Cloud Messaging, and In-App Messaging. For example, if you have an ecommerce app and a physical storefront, you can import data from offline sources - like your store - and send those users an in-app promotion with In-App Messaging.
This feature is available through Firebase's BigQuery integration. To get started, simply create your custom segment and import it into your BigQuery dataset. Then, Firebase will be able to read that data and make those segments available for targeting. We built imported segments to give you more control and flexibility to target your users.
New imported segments let you bring custom segments from BigQuery into Firebase
With these improvements to Firebase, we aim to make app development faster and easier so you can stay focused on creating the amazing app experiences that people need to stay productive, connected, and entertained. People are relying on your apps to adapt and thrive in our changing world. You can rely on us to build, operate, and scale successful apps - in 2020 and beyond.
For more resources and content from Firebase Summit 2020, be sure to check out our summit website, and if you’d like a sneak peek of what’s coming next, join our Alpha program.
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!
#standardSQL SELECT event_dim FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607` LIMIT 50
#standardSQL SELECT event_dim FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607` WHERE event_dim.name = "round_completed"
Error: Cannot access field name on a value with type ARRAY<STRUCT<date STRING, name STRING, params ARRAY<STRUCT<key STRING, value STRUCT<string_value STRING, int_value INT64, float_value FLOAT64, ...>>>, ...>> at [2:17]
UNNEST
#standardSQL WITH data AS ( SELECT "primes under 15" AS description, [1,2,3,5,7,11,13] AS primes_array) SELECT * FROM data
#standardSQL WITH data AS ( SELECT "primes under 15" AS description, [1,2,3,5,7,11,13] AS primes_array) SELECT description, prime FROM data CROSS JOIN UNNEST (primes_array) as prime
primes_array
description
prime
SELECT *.
CROSS JOIN
#standardSQL WITH data AS ( SELECT "primes under 15" AS description, [1,2,3,5,7,11,13] AS primes_array) SELECT description, prime FROM data, UNNEST (primes_array) as prime
#standardSQL WITH data AS ( SELECT "primes under 15" AS description, [1,2,3,5,7,11,13] AS primes_array) SELECT description, prime FROM data, UNNEST (primes_array) as prime WHERE prime > 8
#standardSQL SELECT event.name, event.timestamp_micros FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607`, UNNEST(event_dim) as event WHERE event.name = "round_completed"
params
#standardSQL SELECT event, event.name, event.timestamp_micros FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607`, UNNEST(event_dim) as event, UNNEST(event.params) as event_param WHERE event.name = "round_completed" AND event_param.key = "score" AND event_param.value.int_value > 10000
#standardSQL SELECT user_dim.app_info.app_instance_id as unique_id, MAX(user_prop.key) as keyname, MAX(user_prop.value.value.string_value) as keyvalue FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607`, UNNEST(user_dim.user_properties) AS user_prop WHERE user_prop.key = "language" GROUP BY unique_id
#standardSQL SELECT keyvalue, count(*) as count FROM ( SELECT user_dim.app_info.app_instance_id as unique_id, MAX(user_prop.key) as keyname, MAX(user_prop.value.value.string_value) as keyvalue FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607`, UNNEST(user_dim.user_properties) AS user_prop WHERE user_prop.key = "language" GROUP BY unique_id ) GROUP BY keyvalue ORDER BY count DESC
#standardSQL SELECT user_dim, event, event.name, event.timestamp_micros FROM `firebase-analytics-sample-data.android_dataset.app_events_20160607`, UNNEST(event_dim) as event, UNNEST(event.params) as event_param, UNNEST(user_dim.user_properties) as user_prop WHERE event.name = "round_completed" AND event_param.key = "squares_daubed" AND event_param.value.int_value > 20 AND user_prop.key = "elite_powers" AND (CAST(user_prop.value.value.string_value as int64)) > 1
Since expanding Firebase to become Google's mobile application development platform at Google I/O last year, our amazing community of developers has created over 1 million Firebase projects.
We're thrilled so many of you use and trust us. While Firebase is a full suite of products for building and growing apps, we know that some apps need more than we offer out-of-the-box. That's why we're bringing Firebase much closer to Google Cloud Platform (GCP) to serve even the most demanding applications, whether you're a new startup or a large enterprise.
Firebase already shares the same account and billing system as GCP, so you can attach Firebase services to your GCP project and vice-versa. This makes for powerful combinations, such as exporting raw event data from Firebase Analytics into BigQuery for ad-hoc analysis. Starting today, we're beginning to share products too.
First, Firebase developers have been asking for ways to extend their app's functionality without spinning up a server, and Cloud Functions for Firebase lets you do just that. Cloud Functions is our new event-driven serverless compute offering that enters public beta today. The infrastructure is shared between Cloud and Firebase, allowing you to invoke a function or access resources from throughout the Cloud/Firebase ecosystem. For more information, read the announcement on the Firebase blog and Cloud blog.
Next, we're bringing Firebase Storage closer to Cloud Storage. Firebase Storage launched 10 months ago, and lets you easily upload and download files from your device directly to Cloud Storage. Previously we gave you a single bucket for your files. Now we're fully aligning the two products and letting you use any Cloud Storage bucket, from any global region and from any storage class, all straight from the Firebase SDK. To reflect this alignment we're renaming the product Cloud Storage for Firebase. Read more in our blog post.
Stay tuned for more product integrations in the future as Firebase continues to provide direct client-side access to GCP infrastructure through our iOS, Web, and Android SDKs.
We love lawyers almost as much as developers, so we're extending GCP's Terms of Service to cover several Firebase products. This makes Firebase and Cloud simpler to evaluate and use together. Products to be covered include: Authentication, Hosting, Storage, Functions, and Test Lab. Our streamlined Terms of Service will take effect soon.
Firebase brings together the best of Google on mobile -- whether that's Google's flagship advertising solutions like AdMob and AdWords, or Google's analytics expertise in the form of Firebase Analytics.
Google Cloud Platform lets you to benefit from the institutional knowledge Google has developed from almost two decades of running global-scale computing infrastructure.
By bringing together the ease-of-use of Firebase with the full-range of GCP infrastructure offerings, we're better able to serve you up and down the stack. If you're a startup using Firebase to quickly get to market, you can now easily scale into a full public cloud. If you're an existing business running on GCP who wants to ship a mobile app, we've got you covered too.
We can't wait to see what you build with Firebase and Google Cloud Platform!
Our goal with Firebase is to help developers build better apps and grow them into successful businesses. Six months ago at Google I/O, we took our well-loved backend-as-a-service (BaaS) and expanded it to 15 features to make it Google’s unified app development platform, available across iOS, Android, and the web.
We launched many new features at Google I/O, but our work didn’t stop there. Since then, we’ve learned a lot from you (750,000+ projects created on Firebase to date!) about how you’re using our platform and how we can improve it. Thanks to your feedback, today we’re launching a number of enhancements to Crash Reporting, Analytics, support for game developers and more. For more information on our announcements, tune in to the livestream video from Firebase Dev Summit in Berlin. They’re also listed here:
Often the hardest part about fixing an issue is reproducing it, so we’ve added rich context to each crash to make the process simple. Firebase Crash Reporting now shows Firebase Analytics event data in the logs for each crash. This gives you clarity into the state of your app leading up to an error. Things like which screens of your app were visited are automatically logged with no instrumentation code required. Crash logs will also display any custom events and parameters you explicitly log using Firebase Analytics. Firebase Crash Reporting works for both iOS and Android apps.
Glide, a popular live video messaging app, relies on Firebase Crash Reporting to ensure user quality and release agility. “No matter how much effort you put into testing, it will never be as thorough as millions of active users in different locations, experiencing a variety of network conditions and real life situations. Firebase allows us to rapidly gain trust in our new version during phased release, as well as accelerate the process of identifying core issues and providing quick solutions.” - Roi Ginat, Founder, Glide.
We want to help you deliver high-quality experiences, so testing your app before it goes into the wild is incredibly important. Firebase Test Lab allows you to easily test your app on many physical and virtual devices in the cloud, without writing a single line of test code. Beginning today, developers on the Spark service tier (which is free!) can run five tests per day on physical devices and ten tests per day on virtual devices—with no credit card setup required. We’ve also heard that you want more device options, so we’ve added 11 new popular Android device models to Test Lab, available today.
We know that your data is most actionable when you can see and process it as quickly as possible. Therefore, we’re announcing a number of features to help you maximize the potential of your analytics events:
We were happy to give you a sneak preview at the Firebase Dev Summit of a new feature we are now building, StreamView, which will offer a live, dynamic view of your analytics data as it streams in.
To further enhance your targeting options, we’ve improved the connection between Firebase Analytics and other Firebase features, such as Dynamic Links and Remote Config. For example, you can now use Dynamic Links on your Facebook business page, and we can identify Facebook as a source in Firebase Analytics reporting. Also, you can now target Remote Config changes by User Properties, in addition to Audiences.
Game developers are building great apps, and we want Firebase to work for you, too. We’ve built an entirely new plugin for Unity that supports Analytics, the Realtime Database, Authentication, Dynamic Links, Remote Config, Notifications and more. We've also expanded our C++ SDK with Realtime Database support.
FirebaseUI is a library that provides common UI elements when building apps, and it’s a quick way to integrate with Firebase. FirebaseUI 1.0 includes a drop-in UI flow for Firebase Authentication, with common identity providers such as Google, Facebook, and Twitter. FirebaseUI 1.0 also added features such as client-side joins and intersections for the Realtime Database, plus integrations with Glide and SDWebImage that make downloading and displaying images from Firebase Storage a cinch. Follow our progress or contribute to our Android, iOS, and Web components on Github.
We want to provide the best tool for developers, but it’s also important that we give resources and training to help you get more out of the platform. As such, we’ve created a new Udacity course: Firebase in a Weekend! It’s an instructor-led video course to help all developers get up and running with Firebase on iOS and Android, in two days.
Finally, to help wrap your head around all our announcements, we’ve created a new demo app. This is an easy way to see how Analytics, Crash Reporting, Test Lab, Notifications, and Remote Config work in a live environment, without having to write a line of code.
Helping developers build better apps and successful businesses is at the core of Firebase. We work hard on it every day. We love hearing your feedback and ideas for new features and improvements—and we hope you can see from the length of this post that we take them to heart! Follow us on Twitter, join our Slack channel, participate in our Google Group, and let us know what you think. We’re excited to see what you’ll build next!
