Google Developers Blog: Firebase
Posted by Brahim Elbouchikhi, Director of Product Management and Matej Pfajfar, Engineering Director
We launched ML Kit at I/O last year with the mission to simplify Machine Learning for everyone. We couldn’t be happier about the experiences that ML Kit has enabled thousands of developers to create. And more importantly, user engagement with features powered by ML Kit is growing more than 60% per month. Below is a small sample of apps we have been working with.
But there is a lot more. At I/O this year, we are excited to introduce four new features.
The Object Detection and Tracking API lets you identify the prominent object in an image and then track it in real-time. You can pair this API with a cloud solution (e.g. Google Cloud’s Product Search API) to create a real-time visual search experience.
When you pass an image or video stream to the API, it will return the coordinates of the primary object as well as a coarse classification. The API then provides a handle for tracking this object's coordinates over time.
A number of partners have built experiences that are powered by this API already. For example, Adidas built a visual search experience right into their app.
The On-device Translation API allows you to use the same offline models that support Google Translate to provide fast, dynamic translation of text in your app into 58 languages. This API operates entirely on-device so the context of the translated text never leaves the device.
You can use this API to enable users to communicate with others who don't understand their language or translate user-generated content.
To the right, we demonstrate the use of ML Kit’s text recognition, language detection, and translation APIs in one experience.
We also collaborated with the Material Design team to produce a set of design patterns for integrating ML into your apps. We are open sourcing implementations of these patterns and hope that they will further accelerate your adoption of ML Kit and AI more broadly.
Our design patterns for machine learning powered features will be available on the Material.io site.
With AutoML Vision Edge, you can easily create custom image classification models tailored to your needs. For example, you may want your app to be able to identify different types of food, or distinguish between species of animals. Whatever your need, just upload your training data to the Firebase console and you can use Google’s AutoML technology to build a custom TensorFlow Lite model for you to run locally on your user's device. And if you find that collecting training datasets is hard, you can use our open source app which makes the process simpler and more collaborative.
Wrapping up
We are excited by this first year and really hope that our progress will inspire you to get started with Machine Learning. Please head over to g.co/mlkit to learn more or visit Firebase to get started right away.
Posted by Brahim Elbouchikhi, Director of Product Management and Matej Pfajfar, Engineering Director
We launched ML Kit at I/O last year with the mission to simplify Machine Learning for everyone. We couldn’t be happier about the experiences that ML Kit has enabled thousands of developers to create. And more importantly, user engagement with features powered by ML Kit is growing more than 60% per month. Below is a small sample of apps we have been working with.
But there is a lot more. At I/O this year, we are excited to introduce four new features.
The Object Detection and Tracking API lets you identify the prominent object in an image and then track it in real-time. You can pair this API with a cloud solution (e.g. Google Cloud’s Product Search API) to create a real-time visual search experience.
When you pass an image or video stream to the API, it will return the coordinates of the primary object as well as a coarse classification. The API then provides a handle for tracking this object's coordinates over time.
A number of partners have built experiences that are powered by this API already. For example, Adidas built a visual search experience right into their app.
The On-device Translation API allows you to use the same offline models that support Google Translate to provide fast, dynamic translation of text in your app into 58 languages. This API operates entirely on-device so the context of the translated text never leaves the device.
You can use this API to enable users to communicate with others who don't understand their language or translate user-generated content.
To the right, we demonstrate the use of ML Kit’s text recognition, language detection, and translation APIs in one experience.
We also collaborated with the Material Design team to produce a set of design patterns for integrating ML into your apps. We are open sourcing implementations of these patterns and hope that they will further accelerate your adoption of ML Kit and AI more broadly.
Our design patterns for machine learning powered features will be available on the Material.io site.
With AutoML Vision Edge, you can easily create custom image classification models tailored to your needs. For example, you may want your app to be able to identify different types of food, or distinguish between species of animals. Whatever your need, just upload your training data to the Firebase console and you can use Google’s AutoML technology to build a custom TensorFlow Lite model for you to run locally on your user's device. And if you find that collecting training datasets is hard, you can use our open source app which makes the process simpler and more collaborative.
Wrapping up
We are excited by this first year and really hope that our progress will inspire you to get started with Machine Learning. Please head over to g.co/mlkit to learn more or visit Firebase to get started right away.
Posted by Mertcan Mermerkaya, Software Engineer
We have great news for web developers that use Firebase Cloud Messaging to send notifications to clients! The FCM v1 REST API has integrated fully with the Web Notifications API. This integration allows you to set icons, images, actions and more for your Web notifications from your server! Better yet, as the Web Notifications API continues to grow and change, these options will be immediately available to you. You won't have to wait for an update to FCM to support them!
. This integration allows you to set icons, images, actions and more for your Web notifications from your server! Better yet, as the Web Notifications API continues to grow and change, these options will be immediately available to you. You won't have to wait for an update to FCM to support them!
Below is a sample payload you can send to your web clients on Push API supported browsers
Notice that you are able to set new parameters, such as actions, which gives the user different ways to interact with the notification. In the example below, users have the option to choose from actions to like the photo or to unsubscribe.
To handle action clicks in your app, you need to add an event listener in the default firebase-messaging-sw.js file (or your custom service worker). If an action button was clicked, event.action will contain the string that identifies the clicked action. Here's how to handle the "like" and "unsubscribe" events on the client:
// Retrieve an instance of Firebase Messaging so that it can handle background messages.
const messaging = firebase.messaging();
// Add an event listener to handle notification clicks
self.addEventListener('notificationclick', function(event) {
if (event.action === 'like') {
// Like button was clicked
const photoId = event.notification.data.photoId;
like(photoId);
}
else if (event.action === 'unsubscribe') {
// Unsubscribe button was clicked
const notificationType = event.notification.data.notificationType;
unsubscribe(notificationType);
}
event.notification.close();
});
The SDK will still handle regular notification clicks and redirect the user to your click_action link if provided. To see more on how to handle click actions on the client, check out the guide.
Since different browsers support different parameters in different platforms, it's important to check out the browser compatibility documentation to ensure your notifications work as intended. Want to learn more about what the Send API can do? Check out the FCM Send API documentation and the Web Notifications API documentation. If you're using the FCM Send API and you incorporate the Web Notifications API in a cool way, then let us know! Find Firebase on Twitter at @Firebase, and Facebook and Google+ by searching "Firebase".
Posted by Brahim Elbouchikhi, Product Manager
In today's fast-moving world, people have come to expect mobile apps to be intelligent - adapting to users' activity or delighting them with surprising smarts. As a result, we think machine learning will become an essential tool in mobile development. That's why on Tuesday at Google I/O, we introduced ML Kit in beta: a new SDK that brings Google's machine learning expertise to mobile developers in a powerful, yet easy-to-use package on Firebase. We couldn't be more excited!
Getting started with machine learning can be difficult for many developers. Typically, new ML developers spend countless hours learning the intricacies of implementing low-level models, using frameworks, and more. Even for the seasoned expert, adapting and optimizing models to run on mobile devices can be a huge undertaking. Beyond the machine learning complexities, sourcing training data can be an expensive and time consuming process, especially when considering a global audience.
With ML Kit, you can use machine learning to build compelling features, on Android and iOS, regardless of your machine learning expertise. More details below!
If you're a beginner who just wants to get the ball rolling, ML Kit gives you five ready-to-use ("base") APIs that address common mobile use cases:
With these base APIs, you simply pass in data to ML Kit and get back an intuitive response. For example: Lose It!, one of our early users, used ML Kit to build several features in the latest version of their calorie tracker app. Using our text recognition based API and a custom built model, their app can quickly capture nutrition information from product labels to input a food's content from an image.
ML Kit gives you both on-device and Cloud APIs, all in a common and simple interface, allowing you to choose the ones that fit your requirements best. The on-device APIs process data quickly and will work even when there's no network connection, while the cloud-based APIs leverage the power of Google Cloud Platform's machine learning technology to give a higher level of accuracy.
See these APIs in action on your Firebase console:
Heads up: We're planning to release two more APIs in the coming months. First is a smart reply API allowing you to support contextual messaging replies in your app, and the second is a high density face contour addition to the face detection API. Sign up here to give them a try!
If you're seasoned in machine learning and you don't find a base API that covers your use case, ML Kit lets you deploy your own TensorFlow Lite models. You simply upload them via the Firebase console, and we'll take care of hosting and serving them to your app's users. This way you can keep your models out of your APK/bundles which reduces your app install size. Also, because ML Kit serves your model dynamically, you can always update your model without having to re-publish your apps.
But there is more. As apps have grown to do more, their size has increased, harming app store install rates, and with the potential to cost users more in data overages. Machine learning can further exacerbate this trend since models can reach 10's of megabytes in size. So we decided to invest in model compression. Specifically, we are experimenting with a feature that allows you to upload a full TensorFlow model, along with training data, and receive in return a compressed TensorFlow Lite model. The technology behind this is evolving rapidly and so we are looking for a few developers to try it and give us feedback. If you are interested, please sign up here.
Since ML Kit is available through Firebase, it's easy for you to take advantage of the broader Firebase platform. For example, Remote Config and A/B testing lets you experiment with multiple custom models. You can dynamically switch values in your app, making it a great fit to swap the custom models you want your users to use on the fly. You can even create population segments and experiment with several models in parallel.
Other examples include:
We can't wait to see what you'll build with ML Kit. We hope you'll love the product like many of our early customers:
Get started with the ML Kit beta by visiting your Firebase console today. If you have any thoughts or feedback, feel free to let us know - we're always listening!
Posted by Brahim Elbouchikhi, Product Manager
In today's fast-moving world, people have come to expect mobile apps to be intelligent - adapting to users' activity or delighting them with surprising smarts. As a result, we think machine learning will become an essential tool in mobile development. That's why on Tuesday at Google I/O, we introduced ML Kit in beta: a new SDK that brings Google's machine learning expertise to mobile developers in a powerful, yet easy-to-use package on Firebase. We couldn't be more excited!
Getting started with machine learning can be difficult for many developers. Typically, new ML developers spend countless hours learning the intricacies of implementing low-level models, using frameworks, and more. Even for the seasoned expert, adapting and optimizing models to run on mobile devices can be a huge undertaking. Beyond the machine learning complexities, sourcing training data can be an expensive and time consuming process, especially when considering a global audience.
With ML Kit, you can use machine learning to build compelling features, on Android and iOS, regardless of your machine learning expertise. More details below!
If you're a beginner who just wants to get the ball rolling, ML Kit gives you five ready-to-use ("base") APIs that address common mobile use cases:
With these base APIs, you simply pass in data to ML Kit and get back an intuitive response. For example: Lose It!, one of our early users, used ML Kit to build several features in the latest version of their calorie tracker app. Using our text recognition based API and a custom built model, their app can quickly capture nutrition information from product labels to input a food's content from an image.
ML Kit gives you both on-device and Cloud APIs, all in a common and simple interface, allowing you to choose the ones that fit your requirements best. The on-device APIs process data quickly and will work even when there's no network connection, while the cloud-based APIs leverage the power of Google Cloud Platform's machine learning technology to give a higher level of accuracy.
See these APIs in action on your Firebase console:
Heads up: We're planning to release two more APIs in the coming months. First is a smart reply API allowing you to support contextual messaging replies in your app, and the second is a high density face contour addition to the face detection API. Sign up here to give them a try!
If you're seasoned in machine learning and you don't find a base API that covers your use case, ML Kit lets you deploy your own TensorFlow Lite models. You simply upload them via the Firebase console, and we'll take care of hosting and serving them to your app's users. This way you can keep your models out of your APK/bundles which reduces your app install size. Also, because ML Kit serves your model dynamically, you can always update your model without having to re-publish your apps.
But there is more. As apps have grown to do more, their size has increased, harming app store install rates, and with the potential to cost users more in data overages. Machine learning can further exacerbate this trend since models can reach 10's of megabytes in size. So we decided to invest in model compression. Specifically, we are experimenting with a feature that allows you to upload a full TensorFlow model, along with training data, and receive in return a compressed TensorFlow Lite model. The technology behind this is evolving rapidly and so we are looking for a few developers to try it and give us feedback. If you are interested, please sign up here.
Since ML Kit is available through Firebase, it's easy for you to take advantage of the broader Firebase platform. For example, Remote Config and A/B testing lets you experiment with multiple custom models. You can dynamically switch values in your app, making it a great fit to swap the custom models you want your users to use on the fly. You can even create population segments and experiment with several models in parallel.
Other examples include:
We can't wait to see what you'll build with ML Kit. We hope you'll love the product like many of our early customers:
Get started with the ML Kit beta by visiting your Firebase console today. If you have any thoughts or feedback, feel free to let us know - we're always listening!
We launched the Google URL Shortener back in 2009 as a way to help people more easily share links and measure traffic online. Since then, many popular URL shortening services have emerged and the ways people find content on the Internet have also changed dramatically, from primarily desktop webpages to apps, mobile devices, home assistants, and more.
To refocus our efforts, we're turning down support for goo.gl over the coming weeks and replacing it with Firebase Dynamic Links (FDL). FDLs are smart URLs that allow you to send existing and potential users to any location within an iOS, Android or web app. We're excited to grow and improve the product going forward. While most features of goo.gl will eventually sunset, all existing links will continue to redirect to the intended destination.
Starting April 13, 2018, anonymous users and users who have never created short links before today will not be able to create new short links via the goo.gl console. If you are looking to create new short links, we recommend you check out popular services like Bitly and Ow.ly as an alternative.
If you have existing goo.gl short links, you can continue to use all features of goo.gl console for a period of one year, until March 30, 2019, when we will discontinue the console. You can manage all your short links and their analytics through the goo.gl console during this period.
After March 30, 2019, all links will continue to redirect to the intended destination. Your existing short links will not be migrated to the Firebase console, however, you will be able to export your link information from the goo.gl console.
Starting May 30, 2018, only projects that have accessed URL Shortener APIs before today can create short links. To create new short links, we recommend FDL APIs. FDL short links will automatically detect the user's platform and send the user to either the web or your app, as appropriate.
If you are already calling URL Shortener APIs to manage goo.gl short links, you can continue to use them for a period of one year, until March 30, 2019, when we will discontinue the APIs. For developers looking to migrate to FDL see our migration guide.
As it is for consumers, all links will continue to redirect to the intended destination after March 30, 2019. However, existing short links will not be migrated to the Firebase console/API.
URL Shortener has been a great tool that we're proud to have built. As we look towards the future, we're excited about the possibilities of Firebase Dynamic Links, particularly when it comes to dynamic platform detection and links that survive the app installation process. We hope you are too!
Posted by Michael Hermanto, Software Engineer, Firebase
We launched the Google URL Shortener back in 2009 as a way to help people more easily share links and measure traffic online. Since then, many popular URL shortening services have emerged and the ways people find content on the Internet have also changed dramatically, from primarily desktop webpages to apps, mobile devices, home assistants, and more.
To refocus our efforts, we're turning down support for goo.gl over the coming weeks and replacing it with Firebase Dynamic Links (FDL). FDLs are smart URLs that allow you to send existing and potential users to any location within an iOS, Android or web app. We're excited to grow and improve the product going forward. While most features of goo.gl will eventually sunset, all existing links will continue to redirect to the intended destination.
Starting April 13, 2018, anonymous users and users who have never created short links before today will not be able to create new short links via the goo.gl console. If you are looking to create new short links, we recommend you check out popular services like Bitly and Ow.ly as an alternative.
If you have existing goo.gl short links, you can continue to use all features of goo.gl console for a period of one year, until March 30, 2019, when we will discontinue the console. You can manage all your short links and their analytics through the goo.gl console during this period.
After March 30, 2019, all links will continue to redirect to the intended destination. Your existing short links will not be migrated to the Firebase console, however, you will be able to export your link information from the goo.gl console.
Starting May 30, 2018, only projects that have accessed URL Shortener APIs before today can create short links. To create new short links, we recommend FDL APIs. FDL short links will automatically detect the user's platform and send the user to either the web or your app, as appropriate.
If you are already calling URL Shortener APIs to manage goo.gl short links, you can continue to use them for a period of one year, until March 30, 2019, when we will discontinue the APIs. For developers looking to migrate to FDL see our migration guide.
As it is for consumers, all links will continue to redirect to the intended destination after March 30, 2019. However, existing short links will not be migrated to the Firebase console/API.
URL Shortener has been a great tool that we're proud to have built. As we look towards the future, we're excited about the possibilities of Firebase Dynamic Links, particularly when it comes to dynamic platform detection and links that survive the app installation process. We hope you are too!
Back in October, we were thrilled to launch a beta version of Firebase Crashlytics. As the top ranked mobile app crash reporter for over 3 years running, Crashlytics helps you track, prioritize, and fix stability issues in realtime. It's been exciting to see all the positive reactions, as thousands of you have upgraded to Crashlytics in Firebase!
Today, we're graduating Firebase Crashlytics out of beta. As the default crash reporter for Firebase going forward, Crashlytics is the next evolution of the crash reporting capabilities of our platform. It empowers you to achieve everything you want to with Firebase Crash Reporting, plus much more.
This release include several major new features in addition to our stamp of approval when it comes to service reliability. Here's what's new.
We heard from many of you that you love Firebase Crash Reporting's "breadcrumbs" feature. (Breadcrumbs are the automatically created Analytics events that help you retrace user actions preceding a crash.) Starting today, you can see these breadcrumbs within the Crashlytics section of the Firebase console, helping you to triage issues more easily.
To use breadcrumbs on Crashlytics, install the latest SDK and enable Google Analytics for Firebase. If you already have Analytics enabled, the feature will automatically start working.
By broadly analyzing aggregated crash data for common trends, Crashlytics automatically highlights potential root causes and gives you additional context on the underlying problems. For example, it can reveal how widespread incorrect UIKit rendering was in your app so you would know to address that issue first. Crash insights allows you to make more informed decisions on what actions to take, save time on triaging issues, and maximize the impact of your debugging efforts.
From our community:
- Marc Bernstein, Software Development Team Lead, Hudl
Generally, you have a few builds you care most about, while others aren't as important at the moment. With this new release of Crashlytics, you can now "pin" your most important builds which will appear at the top of the console. Your pinned builds will also appear on your teammates' consoles so it's easier to collaborate with them. This can be especially helpful when you have a large team with hundreds of builds and millions of users.
To show you stability issues, Crashlytics automatically uploads your dSYM files in the background to symbolicate your crashes. However, some complex situations can arise (i.e. Bitcode compiled apps) and prevent your dSYMs from being uploaded properly. That's why today we're also releasing a new dSYM uploader tool within your Crashlytics console. Now, you can manually upload your dSYM for cases where it cannot be automatically uploaded.
With today's GA release of Firebase Crashlytics, we've decided to sunset Firebase Crash Reporting, so we can best serve you by focusing our efforts on one crash reporter. Starting today, you'll notice the console has changed to only list Crashlytics in the navigation. If you need to access your existing crash data in Firebase Crash Reporting, you can use the app picker to switch from Crashlytics to Crash Reporting.
Firebase Crash Reporting will continue to be functional until September 8th, 2018 - at which point it will be retired fully.
Upgrading to Crashlytics is easy: just visit your project's console, choose Crashlytics in the left navigation and click "Set up Crashlytics":
If you're currently using both Firebase and Fabric, you can now link the two to see your existing crash data within the Firebase console. To get started, click "Link app in Fabric" within the console and go through the flow on fabric.io:
If you are only using Fabric right now, you don't need to take any action. We'll be building out a new flow in the coming months to help you seamlessly link your existing app(s) from Fabric to Firebase. In the meantime, we encourage you to try other Firebase products.
We are excited to bring you the best-in class crash reporter in the Firebase console. As always, let us know your thoughts and we look forward to continuing to improve Crashlytics. Happy debugging!
#crashImg {
width: 100%;
margin: 10px 0;
}
Originally posted on the Firebase Blog by Jason St. Pierre, Product Manager.
Back in October, we were thrilled to launch a beta version of Firebase Crashlytics. As the top ranked mobile app crash reporter for over 3 years running, Crashlytics helps you track, prioritize, and fix stability issues in realtime. It's been exciting to see all the positive reactions, as thousands of you have upgraded to Crashlytics in Firebase!
Today, we're graduating Firebase Crashlytics out of beta. As the default crash reporter for Firebase going forward, Crashlytics is the next evolution of the crash reporting capabilities of our platform. It empowers you to achieve everything you want to with Firebase Crash Reporting, plus much more.
This release include several major new features in addition to our stamp of approval when it comes to service reliability. Here's what's new.
We heard from many of you that you love Firebase Crash Reporting's "breadcrumbs" feature. (Breadcrumbs are the automatically created Analytics events that help you retrace user actions preceding a crash.) Starting today, you can see these breadcrumbs within the Crashlytics section of the Firebase console, helping you to triage issues more easily.
To use breadcrumbs on Crashlytics, install the latest SDK and enable Google Analytics for Firebase. If you already have Analytics enabled, the feature will automatically start working.
By broadly analyzing aggregated crash data for common trends, Crashlytics automatically highlights potential root causes and gives you additional context on the underlying problems. For example, it can reveal how widespread incorrect UIKit rendering was in your app so you would know to address that issue first. Crash insights allows you to make more informed decisions on what actions to take, save time on triaging issues, and maximize the impact of your debugging efforts.
From our community:
- Marc Bernstein, Software Development Team Lead, Hudl
Generally, you have a few builds you care most about, while others aren't as important at the moment. With this new release of Crashlytics, you can now "pin" your most important builds which will appear at the top of the console. Your pinned builds will also appear on your teammates' consoles so it's easier to collaborate with them. This can be especially helpful when you have a large team with hundreds of builds and millions of users.
To show you stability issues, Crashlytics automatically uploads your dSYM files in the background to symbolicate your crashes. However, some complex situations can arise (i.e. Bitcode compiled apps) and prevent your dSYMs from being uploaded properly. That's why today we're also releasing a new dSYM uploader tool within your Crashlytics console. Now, you can manually upload your dSYM for cases where it cannot be automatically uploaded.
With today's GA release of Firebase Crashlytics, we've decided to sunset Firebase Crash Reporting, so we can best serve you by focusing our efforts on one crash reporter. Starting today, you'll notice the console has changed to only list Crashlytics in the navigation. If you need to access your existing crash data in Firebase Crash Reporting, you can use the app picker to switch from Crashlytics to Crash Reporting.
Firebase Crash Reporting will continue to be functional until September 8th, 2018 - at which point it will be retired fully .
Upgrading to Crashlytics is easy: just visit your project's console, choose Crashlytics in the left navigation and click "Set up Crashlytics":
If you're currently using both Firebase and Fabric, you can now link the two to see your existing crash data within the Firebase console. To get started, click "Link app in Fabric" within the console and go through the flow on fabric.io:
If you are only using Fabric right now, you don't need to take any action. We'll be building out a new flow in the coming months to help you seamlessly link your existing app(s) from Fabric to Firebase. In the meantime, we encourage you to try other Firebase products.
We are excited to bring you the best-in class crash reporter in the Firebase console. As always, let us know your thoughts and we look forward to continuing to improve Crashlytics. Happy debugging!
Today we're excited to launch Cloud Firestore, a fully-managed NoSQL document
database for mobile and web app development. It's designed to easily store and
sync app data at global scale, and it's now available in beta.
Key features of Cloud Firestore include:
And of course, we've aimed for the simplicity and ease-of-use that is always top
priority for Firebase, while still making sure that Cloud Firestore can scale to
power even the largest apps.
Managing app data is still hard; you have to scale servers, handle intermittent
connectivity, and deliver data with low latency.
We've optimized Cloud Firestore for app development, so you can focus on
delivering value to your users and shipping better apps, faster. Cloud
Firestore:
As you may have guessed from the name, Cloud Firestore was built in close
collaboration with the Google Cloud Platform team.
This means it's a fully managed product, built from the ground up to
automatically scale. Cloud Firestore is a multi-region replicated database that
ensures once data is committed, it's durable even in the face of unexpected
disasters. Not only that, but despite being a distributed database, it's also
strongly consistent, removing tricky edge cases to make building apps easier
regardless of scale.
It also means that delivering a great server-side experience for backend
developers is a top priority. We're launching SDKs for Java, Go, Python, and
Node.js today, with more languages coming in the future.
Over the last 3 years Firebase has grown to become Google's app development
platform; it now has 16 products to build and grow your app. If you've used
Firebase before, you know we already offer a database, the Firebase Realtime
Database, which helps with some of the challenges listed above.
The Firebase Realtime Database, with its client SDKs and real-time capabilities,
is all about making app development faster and easier. Since its launch, it has
been adopted by hundred of thousands of developers, and as its adoption grew, so
did usage patterns. Developers began using the Realtime Database for more
complex data and to build bigger apps, pushing the limits of the JSON data model
and the performance of the database at scale.
Cloud Firestore is inspired by
what developers love most about the Firebase Realtime Database while also
addressing its key limitations like data structuring, querying, and scaling.
So, if you're a Firebase Realtime Database user today, we think you'll love
Cloud Firestore. However, this does not mean that Cloud Firestore is a drop-in
replacement for the Firebase Realtime Database. For some use cases, it may make
sense to use the Realtime Database to optimize for cost and latency, and it's
also easy to use both databases together. You can read a more in-depth
comparison between the two databases here.
We're continuing development on both databases and they'll both be available in
our console and documentation.
Cloud Firestore enters public beta starting today. If you're comfortable using a
beta product you should give it a spin on your next project! Here are some of
the companies and startups who are already building with Cloud Firestore:
Get started by visiting the database tab in your Firebase
console. For more details, see the documentation, pricing, code
samples, performance
limitations during beta, and view our open source iOS and JavaScript SDKs on
GitHub.
We can't wait to see what you build and hear what you think of Cloud Firestore!
Today we're excited to launch Cloud Firestore, a fully-managed NoSQL document
database for mobile and web app development. It's designed to easily store and
sync app data at global scale, and it's now available in beta.
Key features of Cloud Firestore include:
And of course, we've aimed for the simplicity and ease-of-use that is always top
priority for Firebase, while still making sure that Cloud Firestore can scale to
power even the largest apps.
Managing app data is still hard; you have to scale servers, handle intermittent
connectivity, and deliver data with low latency.
We've optimized Cloud Firestore for app development, so you can focus on
delivering value to your users and shipping better apps, faster. Cloud
Firestore:
As you may have guessed from the name, Cloud Firestore was built in close
collaboration with the Google Cloud Platform team.
This means it's a fully managed product, built from the ground up to
automatically scale. Cloud Firestore is a multi-region replicated database that
ensures once data is committed, it's durable even in the face of unexpected
disasters. Not only that, but despite being a distributed database, it's also
strongly consistent, removing tricky edge cases to make building apps easier
regardless of scale.
It also means that delivering a great server-side experience for backend
developers is a top priority. We're launching SDKs for Java, Go, Python, and
Node.js today, with more languages coming in the future.
Over the last 3 years Firebase has grown to become Google's app development
platform; it now has 16 products to build and grow your app. If you've used
Firebase before, you know we already offer a database, the Firebase Realtime
Database, which helps with some of the challenges listed above.
The Firebase Realtime Database, with its client SDKs and real-time capabilities,
is all about making app development faster and easier. Since its launch, it has
been adopted by hundred of thousands of developers, and as its adoption grew, so
did usage patterns. Developers began using the Realtime Database for more
complex data and to build bigger apps, pushing the limits of the JSON data model
and the performance of the database at scale.
Cloud Firestore is inspired by
what developers love most about the Firebase Realtime Database while also
addressing its key limitations like data structuring, querying, and scaling.
So, if you're a Firebase Realtime Database user today, we think you'll love
Cloud Firestore. However, this does not mean that Cloud Firestore is a drop-in
replacement for the Firebase Realtime Database. For some use cases, it may make
sense to use the Realtime Database to optimize for cost and latency, and it's
also easy to use both databases together. You can read a more in-depth
comparison between the two databases here.
We're continuing development on both databases and they'll both be available in
our console and documentation.
Cloud Firestore enters public beta starting today. If you're comfortable using a
beta product you should give it a spin on your next project! Here are some of
the companies and startups who are already building with Cloud Firestore:
Get started by visiting the database tab in your Firebase
console. For more details, see the documentation, pricing, code
samples, performance
limitations during beta, and view our open source iOS and JavaScript SDKs on
GitHub.
We can't wait to see what you build and hear what you think of Cloud Firestore!
Whether it's opening night for a Broadway musical or launch day for your app,
both are thrilling times for everyone involved. Our agency, Posse, collaborated with Hamilton to design,
build, and launch the official Hamilton app... in only three short months.
We decided to use Firebase, Google's
mobile development platform, for our backend and infrastructure, while we used
Flutter, a new UI toolkit for iOS and Android,
for our front-end. In this post, we share how we did it.
We love to spend time designing beautiful UIs, testing new interactions, and
iterating with clients, and we don't want to be distracted by setting up and
maintaining servers. To stay focused on the app and our users, we implemented a
full serverless architecture and made heavy use of Firebase.
A key feature of the app is the ticket lottery, which offers fans a
chance to get tickets to the constantly sold-out Hamilton show. We used Cloud
Functions for Firebase, and a data flow architecture we learned
about at Google I/O, to coordinate the lottery workflow between the mobile
app, custom business logic, and partner services.
For example, when someone enters the lottery, the app first writes data to
specific nodes in Realtime Database and the database's security rules help to
ensure that the data is valid. The write triggers a Cloud Function,
which runs business logic and stores its result to a new node in the Realtime
Database. The newly written result data is then pushed automatically to the app.
Because of Hamilton's intense fan following, we wanted to make sure that app
users could get news the instant it was published. So we built a custom,
web-based Content Management System (CMS) for the Hamilton team that used
Firebase Realtime Database to store and retrieve data. The Realtime Database
eliminated the need for a "pull to refresh" feature of the app. When new content
is published via the CMS, the update is stored in Firebase Realtime Database and
every app user automatically sees the update. No refresh, reload, or
pull required!
Besides powering our lottery integration, Cloud Functions was also extremely
valuable in the creation of user profiles, sending push notifications, and our
#HamCam — a custom Hamilton selfie and photo-taking experience. Cloud Functions
resized the images, saved them in Cloud Storage, and then updated the database.
By taking care of the infrastructure work of storing and managing the photos,
Firebase freed us up to focus on making the camera fun and full of Hamilton
style.
With only three months to design and deliver the app, we knew we needed to
iterate quickly on the UX and UI. Flutter's hot reload development
cycle meant we could make a change in our UI code and, in about a second, see
the change reflected on our simulators and phones. No rebuilding, recompiling,
or multi-second pauses required! Even the state of the app was preserved between
hot reloads, making it very fast for us to iterate on the UI with our designers.
We used Flutter's reactive UI framework to implement Hamilton's iconic brand
with custom UI elements. Flutter's "everything is a widget" approach made it
easy for us to compose custom UIs from a rich set of building blocks provided by
the framework. And, because Flutter runs on both iOS and Android, we were able
to spend our time creating beautiful designs instead of porting the UI.
The FlutterFire
project helped us access Firebase Analytics, Firebase Authentication, and
Realtime Database from the app code. And because Flutter is open source, and
easy to extend, we even built a custom router library that helped us
organize the app's UI code.
We enjoyed building the Hamilton app (find it on the Play
Store or the App
Store) in a way that allowed us to focus on our users and experiment with
new app ideas and experiences. And based on our experience, we'd happily
recommend serverless architectures with Firebase and customized UI designs with
Flutter as powerful ways for you to save time building your app.
For us, we already have plans how to continue and develop Hamilton app in new
ways, and can't wait to release those soon!
If you want to learn more about Firebase or Flutter, we recommend the Firebase docs, the Firebase channel on YouTube,
and the Flutter website.
Whether it's opening night for a Broadway musical or launch day for your app,
both are thrilling times for everyone involved. Our agency, Posse, collaborated with Hamilton to design,
build, and launch the official Hamilton app... in only three short months.
We decided to use Firebase, Google's
mobile development platform, for our backend and infrastructure, while we used
Flutter, a new UI toolkit for iOS and Android,
for our front-end. In this post, we share how we did it.
We love to spend time designing beautiful UIs, testing new interactions, and
iterating with clients, and we don't want to be distracted by setting up and
maintaining servers. To stay focused on the app and our users, we implemented a
full serverless architecture and made heavy use of Firebase.
A key feature of the app is the ticket lottery, which offers fans a
chance to get tickets to the constantly sold-out Hamilton show. We used Cloud
Functions for Firebase, and a data flow architecture we learned
about at Google I/O, to coordinate the lottery workflow between the mobile
app, custom business logic, and partner services.
For example, when someone enters the lottery, the app first writes data to
specific nodes in Realtime Database and the database's security rules help to
ensure that the data is valid. The write triggers a Cloud Function,
which runs business logic and stores its result to a new node in the Realtime
Database. The newly written result data is then pushed automatically to the app.
Because of Hamilton's intense fan following, we wanted to make sure that app
users could get news the instant it was published. So we built a custom,
web-based Content Management System (CMS) for the Hamilton team that used
Firebase Realtime Database to store and retrieve data. The Realtime Database
eliminated the need for a "pull to refresh" feature of the app. When new content
is published via the CMS, the update is stored in Firebase Realtime Database and
every app user automatically sees the update. No refresh, reload, or
pull required!
Besides powering our lottery integration, Cloud Functions was also extremely
valuable in the creation of user profiles, sending push notifications, and our
#HamCam — a custom Hamilton selfie and photo-taking experience. Cloud Functions
resized the images, saved them in Cloud Storage, and then updated the database.
By taking care of the infrastructure work of storing and managing the photos,
Firebase freed us up to focus on making the camera fun and full of Hamilton
style.
With only three months to design and deliver the app, we knew we needed to
iterate quickly on the UX and UI. Flutter's hot reload development
cycle meant we could make a change in our UI code and, in about a second, see
the change reflected on our simulators and phones. No rebuilding, recompiling,
or multi-second pauses required! Even the state of the app was preserved between
hot reloads, making it very fast for us to iterate on the UI with our designers.
We used Flutter's reactive UI framework to implement Hamilton's iconic brand
with custom UI elements. Flutter's "everything is a widget" approach made it
easy for us to compose custom UIs from a rich set of building blocks provided by
the framework. And, because Flutter runs on both iOS and Android, we were able
to spend our time creating beautiful designs instead of porting the UI.
The FlutterFire
project helped us access Firebase Analytics, Firebase Authentication, and
Realtime Database from the app code. And because Flutter is open source, and
easy to extend, we even built a custom router library that helped us
organize the app's UI code.
We enjoyed building the Hamilton app (find it on the Play
Store or the App
Store) in a way that allowed us to focus on our users and experiment with
new app ideas and experiences. And based on our experience, we'd happily
recommend serverless architectures with Firebase and customized UI designs with
Flutter as powerful ways for you to save time building your app.
For us, we already have plans how to continue and develop Hamilton app in new
ways, and can't wait to release those soon!
If you want to learn more about Firebase or Flutter, we recommend the Firebase docs, the Firebase channel on YouTube,
and the Flutter website.
It's been an exciting year! Last May, we expanded Firebase into
our unified app platform, building on the original backend-as-a-service and
adding products to help developers grow their user base, as well as test and
monetize their apps. Hearing from developers like Wattpad, who built an app
using Firebase in only 3 weeks, makes all the hard work worthwhile.
We're thrilled by the initial response from the community, but we believe our
journey is just getting started. Let's talk about some of the enhancements
coming to Firebase today.
In January, we
announced that we were welcoming the Fabric team to Firebase. Fabric initially
grabbed our attention with their array of products, including the
industry-leading crash reporting tool, Crashlytics. As we got to know the team
better, we were even more impressed by how closely aligned our missions are: to
help developers build better apps and grow successful businesses. Over the last
several months, we've been working closely with the Fabric team to bring
the best of our platforms together.
We plan to make Crashlytics the primary crash reporting product in Firebase. If
you don't already use a crash reporting tool, we recommend you take a look at
Crashlytics and see what it can do for you. You can get started by following the Fabric
documentation.
Phone number authentication has been the biggest request for Firebase
Authentication, so we're excited to announce that we've worked with the Fabric
Digits team to bring phone auth to our platform. You can now let your users sign
in with their phone numbers, in addition to traditional email/password or
identity providers like Google or Facebook. This gives you a comprehensive
authentication solution no matter who your users are or how they like to log in.
At the same time, the Fabric team will be retiring the Digits name and SDK. If
you currently use Digits, over the next couple weeks we'll be rolling out the
ability to link your existing Digits account with Firebase and swap in the
Firebase SDK for the Digits SDK. Go to the Digits
blog to learn more.
/>
We recognize that poor app performance and stability are the top reasons for
users to leave bad ratings on your app and possibly churn altogether. As part of
our effort to help you build better apps, we're pleased to announce the beta
launch of Performance Monitoring.
Firebase Performance Monitoring is a new free tool that helps you understand
when your user experience is being impacted by poorly performing code or
challenging network conditions. You can learn more and get started with
Performance Monitoring in the Firebase
documentation.
Analytics has been core to the Firebase platform since we launched last I/O. We
know that understanding your users is the number one way to make your app
successful, so we're continuing to invest in improving our analytics product.
First off, you may notice that you're starting to see the name "Google Analytics
for Firebase" around our documentation. Our analytics solution was built in
conjunction with the Google Analytics team, and the reports are available both
in the Firebase console and the Google Analytics interface. So, we're renaming
Firebase Analytics to Google Analytics for Firebase, to reflect that your app
analytics data are shared across both.
For those of you who monetize your app with AdMob, we've started sharing data between
the two platforms, helping you understand the true lifetime value (LTV) of
your users, from both purchases and AdMob revenue. You'll see these new insights
surfaced in the updated Analytics dashboard.
Many of you have also asked for analytics insights into custom events and
parameters. Starting today, you can register up to 50 custom event parameters
and see their details in your Analytics reports. Learn more about
custom parameter reporting.
Firebase's mission is to help all developers build better apps. In that spirit,
today we're announcing expanded platform and vertical support for Firebase.
First of all, as Swift has become the preferred language for many iOS
developers, we've updated our SDK to handle Swift language nuances, making Swift
development a native experience on Firebase.
We've also improved Firebase Cloud Messaging by adding support for token-based
authentication for APNs, and greatly simplifying the connection and registration
logic in the client SDK.
Second, we've heard from our game developer community that one of the most
important stats you monitor is frames per second (FPS). So, we've built Game
Loop support & FPS monitoring into Test Lab for Android, allowing you to
evaluate your game's frame rate before you deploy. Coupled with the addition of
Unity plugins and a C++ SDK, which we
announced at GDC this year, we think that Firebase is a great option for
game developers. To see an example of a game built on top of Firebase, check out
our Mecha Hamster app on
Github.
Finally, we've taken a big first step towards open sourcing our SDKs. We believe
in open source software, not only because transparency is an important goal, but
also because we know that the greatest innovation happens when we all
collaborate. You can view our new repos on our open sourceproject page and learn more about our decision in this
blog post.
In March, we
launched Cloud Functions for Firebase, which lets you run custom backend
code in response to events triggered by Firebase features and HTTP requests.
This lets you do things like send a notification when a user signs up or
automatically create thumbnails when an image is uploaded to Cloud Storage.
Today, in an effort to better serve our web developer community, we're expanding
Firebase Hosting to integrate with Cloud Functions. This means that, in addition
to serving static assets for your web app, you can now serve dynamic content,
generated by Cloud Functions, through Firebase Hosting. For those of you
building progressive web
apps, Firebase Hosting + Cloud Functions allows you to go completely
server-less. You can learn more by visiting our
documentation.
Our goal is to build the best developer experience: easy-to-use products, great
documentation, and intuitive APIs. And the best resource that we have for
improving Firebase is you! Your questions and feedback continuously push us to
make Firebase better.
In light of that, we're excited to announce a Firebase Alpha program, where you
will have the opportunity to test the cutting edge of our products. Things might
not be perfect (in fact, we can almost guarantee they won't be), but by
participating in the alpha community, you'll help define the future of Firebase.
If you want to get involved, please register your interest in the Firebase Alpha form.
Thank you for your support, enthusiasm, and, most importantly, feedback. The
Firebase community is the reason that we've been able to grow and improve our
platform at such an incredible pace over the last year. We're excited to
continue working with you to build simple, intuitive products for developing
apps and growing mobile businesses. To get started with Firebase today, visit
our newly redesigned website. We're
excited to see what you build!
Originally posted on the Firebase Blog by Francis Ma, Firebase Group Product Manager
It's been an exciting year! Last May, we expanded Firebase into
our unified app platform, building on the original backend-as-a-service and
adding products to help developers grow their user base, as well as test and
monetize their apps. Hearing from developers like Wattpad, who built an app
using Firebase in only 3 weeks, makes all the hard work worthwhile.
We're thrilled by the initial response from the community, but we believe our
journey is just getting started. Let's talk about some of the enhancements
coming to Firebase today.
In January, we
announced that we were welcoming the Fabric team to Firebase. Fabric initially
grabbed our attention with their array of products, including the
industry-leading crash reporting tool, Crashlytics. As we got to know the team
better, we were even more impressed by how closely aligned our missions are: to
help developers build better apps and grow successful businesses. Over the last
several months, we've been working closely with the Fabric team to bring
the best of our platforms together.
We plan to make Crashlytics the primary crash reporting product in Firebase. If
you don't already use a crash reporting tool, we recommend you take a look at
Crashlytics and see what it can do for you. You can get started by following the Fabric
documentation.
Phone number authentication has been the biggest request for Firebase
Authentication, so we're excited to announce that we've worked with the Fabric
Digits team to bring phone auth to our platform. You can now let your users sign
in with their phone numbers, in addition to traditional email/password or
identity providers like Google or Facebook. This gives you a comprehensive
authentication solution no matter who your users are or how they like to log in.
At the same time, the Fabric team will be retiring the Digits name and SDK. If
you currently use Digits, over the next couple weeks we'll be rolling out the
ability to link your existing Digits account with Firebase and swap in the
Firebase SDK for the Digits SDK. Go to the Digits
blog to learn more.
We recognize that poor app performance and stability are the top reasons for
users to leave bad ratings on your app and possibly churn altogether. As part of
our effort to help you build better apps, we're pleased to announce the beta
launch of Performance Monitoring.
Firebase Performance Monitoring is a new free tool that helps you understand
when your user experience is being impacted by poorly performing code or
challenging network conditions. You can learn more and get started with
Performance Monitoring in the Firebase
documentation.
Analytics has been core to the Firebase platform since we launched last I/O. We
know that understanding your users is the number one way to make your app
successful, so we're continuing to invest in improving our analytics product.
First off, you may notice that you're starting to see the name "Google Analytics
for Firebase" around our documentation. Our analytics solution was built in
conjunction with the Google Analytics team, and the reports are available both
in the Firebase console and the Google Analytics interface. So, we're renaming
Firebase Analytics to Google Analytics for Firebase, to reflect that your app
analytics data are shared across both.
For those of you who monetize your app with AdMob, we've started sharing data between
the two platforms, helping you understand the true lifetime value (LTV) of
your users, from both purchases and AdMob revenue. You'll see these new insights
surfaced in the updated Analytics dashboard.
Many of you have also asked for analytics insights into custom events and
parameters. Starting today, you can register up to 50 custom event parameters
and see their details in your Analytics reports. Learn more about
custom parameter reporting.
Firebase's mission is to help all developers build better apps. In that spirit,
today we're announcing expanded platform and vertical support for Firebase.
First of all, as Swift has become the preferred language for many iOS
developers, we've updated our SDK to handle Swift language nuances, making Swift
development a native experience on Firebase.
We've also improved Firebase Cloud Messaging by adding support for token-based
authentication for APNs, and greatly simplifying the connection and registration
logic in the client SDK.
Second, we've heard from our game developer community that one of the most
important stats you monitor is frames per second (FPS). So, we've built Game
Loop support & FPS monitoring into Test Lab for Android, allowing you to
evaluate your game's frame rate before you deploy. Coupled with the addition of
Unity plugins and a C++ SDK, which we
announced at GDC this year, we think that Firebase is a great option for
game developers. To see an example of a game built on top of Firebase, check out
our Mecha Hamster app on
Github.
Finally, we've taken a big first step towards open sourcing our SDKs. We believe
in open source software, not only because transparency is an important goal, but
also because we know that the greatest innovation happens when we all
collaborate. You can view our new repos on our open sourceproject page and learn more about our decision in this
blog post.
In March, we
launched Cloud Functions for Firebase, which lets you run custom backend
code in response to events triggered by Firebase features and HTTP requests.
This lets you do things like send a notification when a user signs up or
automatically create thumbnails when an image is uploaded to Cloud Storage.
Today, in an effort to better serve our web developer community, we're expanding
Firebase Hosting to integrate with Cloud Functions. This means that, in addition
to serving static assets for your web app, you can now serve dynamic content,
generated by Cloud Functions, through Firebase Hosting. For those of you
building progressive web
apps, Firebase Hosting + Cloud Functions allows you to go completely
server-less. You can learn more by visiting our
documentation.
Our goal is to build the best developer experience: easy-to-use products, great
documentation, and intuitive APIs. And the best resource that we have for
improving Firebase is you! Your questions and feedback continuously push us to
make Firebase better.
In light of that, we're excited to announce a Firebase Alpha program, where you
will have the opportunity to test the cutting edge of our products. Things might
not be perfect (in fact, we can almost guarantee they won't be), but by
participating in the alpha community, you'll help define the future of Firebase.
If you want to get involved, please register your interest in the Firebase Alpha form.
Thank you for your support, enthusiasm, and, most importantly, feedback. The
Firebase community is the reason that we've been able to grow and improve our
platform at such an incredible pace over the last year. We're excited to
continue working with you to build simple, intuitive products for developing
apps and growing mobile businesses. To get started with Firebase today, visit
our newly redesigned website. We're
excited to see what you build!
In September, we launched a
new way to search for content in apps on Android phones. With this update,
users were able to find personal content like messages, notes, music and more
across apps like OpenTable, Ticketmaster, Evernote, Glide, Asana, Gmail, and
Google Keep from a single search box. Today, we're inviting all Android
developers to enable this functionality for their apps.
Starting with version 10.0, the Firebase App Indexing API on Android lets apps
add their content to Google's on-device index in the background, and update it
in real-time as users make changes in the app. We've designed the API with three
principles in mind:
There are several predefined data types that make it easy to represent common
things such as messages, notes, and songs, or you can add custom types to
represent additional items. Plus, logging user actions like a user listening to
a specific song provides an important signal to help rank user content across
the Google app.
Indexable note = Indexables.noteDigitalDocumentBuilder()
.setUrl("http://example.net/users/42/lists/23")
.setName("Shopping list")
.setText("steak, pasta, wine")
.setImage("http://example.net/images/shopping.jpg")
.build();
FirebaseAppIndex.getInstance().update(note);
Example of adding or updating a user's shopping list in the on-device index.
Integrating with Firebase App Indexing helps increase user engagement with your
app, as users can get back to their personal content in an instant with Google
Search. Because that data is indexed directly on the device, this even works
when offline.
To get started, check out our implementation guide
and codelab.
In September, we launched a
new way to search for content in apps on Android phones. With this update,
users were able to find personal content like messages, notes, music and more
across apps like OpenTable, Ticketmaster, Evernote, Glide, Asana, Gmail, and
Google Keep from a single search box. Today, we're inviting all Android
developers to enable this functionality for their apps.
Starting with version 10.0, the Firebase App Indexing API on Android lets apps
add their content to Google's on-device index in the background, and update it
in real-time as users make changes in the app. We've designed the API with three
principles in mind:
There are several predefined data types that make it easy to represent common
things such as messages, notes, and songs, or you can add custom types to
represent additional items. Plus, logging user actions like a user listening to
a specific song provides an important signal to help rank user content across
the Google app.
Indexable note = Indexables.noteDigitalDocumentBuilder()
.setUrl("http://example.net/users/42/lists/23")
.setName("Shopping list")
.setText("steak, pasta, wine")
.setImage("http://example.net/images/shopping.jpg")
.build();
FirebaseAppIndex.getInstance().update(note);
Example of adding or updating a user's shopping list in the on-device index.
Integrating with Firebase App Indexing helps increase user engagement with your
app, as users can get back to their personal content in an instant with Google
Search. Because that data is indexed directly on the device, this even works
when offline.
To get started, check out our implementation guide
and codelab.
SELECT
user_dim.app_info.app_instance_id,
user_dim.device_info.device_category,
user_dim.device_info.user_default_language,
user_dim.device_info.platform_version,
user_dim.device_info.device_model,
user_dim.geo_info.country,
user_dim.geo_info.city,
user_dim.app_info.app_version,
user_dim.app_info.app_store,
user_dim.app_info.app_platform
FROM
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]
SELECT
user_dim.geo_info.country as country,
EXACT_COUNT_DISTINCT( user_dim.app_info.app_instance_id ) as users
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601],
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]
GROUP BY
country
ORDER BY
users DESC
SELECT
user_dim.user_properties.value.value.string_value as language_code,
EXACT_COUNT_DISTINCT(user_dim.app_info.app_instance_id) as users,
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601],
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]
WHERE
user_dim.user_properties.key = "language"
GROUP BY
language_code
ORDER BY
users DESC
SELECT
event_dim.name,
COUNT(event_dim.name) as event_count
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601]
GROUP BY
event_dim.name
ORDER BY
event_count DESC
SELECT
event_dim.params.value.int_value as virtual_currency_amt,
COUNT(*) as num_times_spent
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601]
WHERE
event_dim.name = "spend_virtual_currency"
AND
event_dim.params.key = "value"
GROUP BY
1
ORDER BY
num_times_spent DESC
SELECT
user_dim.geo_info.city,
COUNT(user_dim.geo_info.city) as city_count
FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
GROUP BY
user_dim.geo_info.city
ORDER BY
city_count DESC
SELECT
user_dim.app_info.app_platform as appPlatform,
user_dim.device_info.device_category as deviceType,
COUNT(user_dim.device_info.device_category) AS device_type_count FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
GROUP BY
1,2
ORDER BY
device_type_count DESC
SELECT
STRFTIME_UTC_USEC(eventTime,"%Y%m%d") as date,
appPlatform,
eventName,
COUNT(*) totalEvents,
EXACT_COUNT_DISTINCT(IF(userId IS NOT NULL, userId, fullVisitorid)) as users
FROM (
SELECT
fullVisitorid,
openTimestamp,
FORMAT_UTC_USEC(openTimestamp) firstOpenedTime,
userIdSet,
MAX(userIdSet) OVER(PARTITION BY fullVisitorid) userId,
appPlatform,
eventTimestamp,
FORMAT_UTC_USEC(eventTimestamp) as eventTime,
eventName
FROM FLATTEN(
(
SELECT
user_dim.app_info.app_instance_id as fullVisitorid,
user_dim.first_open_timestamp_micros as openTimestamp,
user_dim.user_properties.value.value.string_value,
IF(user_dim.user_properties.key = 'user_id',user_dim.user_properties.value.value.string_value, null) as userIdSet,
user_dim.app_info.app_platform as appPlatform,
event_dim.timestamp_micros as eventTimestamp,
event_dim.name AS eventName,
event_dim.params.key,
event_dim.params.value.string_value
FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
), user_dim.user_properties)
)
GROUP BY
date, appPlatform, eventName
SELECT
user_dim.app_info.app_instance_id,
user_dim.device_info.device_category,
user_dim.device_info.user_default_language,
user_dim.device_info.platform_version,
user_dim.device_info.device_model,
user_dim.geo_info.country,
user_dim.geo_info.city,
user_dim.app_info.app_version,
user_dim.app_info.app_store,
user_dim.app_info.app_platform
FROM
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]
SELECT
user_dim.geo_info.country as country,
EXACT_COUNT_DISTINCT( user_dim.app_info.app_instance_id ) as users
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601],
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]
GROUP BY
country
ORDER BY
users DESC
SELECT
user_dim.user_properties.value.value.string_value as language_code,
EXACT_COUNT_DISTINCT(user_dim.app_info.app_instance_id) as users,
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601],
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]
WHERE
user_dim.user_properties.key = "language"
GROUP BY
language_code
ORDER BY
users DESC
SELECT
event_dim.name,
COUNT(event_dim.name) as event_count
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601]
GROUP BY
event_dim.name
ORDER BY
event_count DESC
SELECT
event_dim.params.value.int_value as virtual_currency_amt,
COUNT(*) as num_times_spent
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601]
WHERE
event_dim.name = "spend_virtual_currency"
AND
event_dim.params.key = "value"
GROUP BY
1
ORDER BY
num_times_spent DESC
SELECT
user_dim.geo_info.city,
COUNT(user_dim.geo_info.city) as city_count
FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
GROUP BY
user_dim.geo_info.city
ORDER BY
city_count DESC
SELECT
user_dim.app_info.app_platform as appPlatform,
user_dim.device_info.device_category as deviceType,
COUNT(user_dim.device_info.device_category) AS device_type_count FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
GROUP BY
1,2
ORDER BY
device_type_count DESC
SELECT
STRFTIME_UTC_USEC(eventTime,"%Y%m%d") as date,
appPlatform,
eventName,
COUNT(*) totalEvents,
EXACT_COUNT_DISTINCT(IF(userId IS NOT NULL, userId, fullVisitorid)) as users
FROM (
SELECT
fullVisitorid,
openTimestamp,
FORMAT_UTC_USEC(openTimestamp) firstOpenedTime,
userIdSet,
MAX(userIdSet) OVER(PARTITION BY fullVisitorid) userId,
appPlatform,
eventTimestamp,
FORMAT_UTC_USEC(eventTimestamp) as eventTime,
eventName
FROM FLATTEN(
(
SELECT
user_dim.app_info.app_instance_id as fullVisitorid,
user_dim.first_open_timestamp_micros as openTimestamp,
user_dim.user_properties.value.value.string_value,
IF(user_dim.user_properties.key = 'user_id',user_dim.user_properties.value.value.string_value, null) as userIdSet,
user_dim.app_info.app_platform as appPlatform,
event_dim.timestamp_micros as eventTimestamp,
event_dim.name AS eventName,
event_dim.params.key,
event_dim.params.value.string_value
FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
), user_dim.user_properties)
)
GROUP BY
date, appPlatform, eventName
Originally posted on Firebase blog
Posted by Laurence Moroney, Developer Advocate and Alfonso Gómez Jordana, Associate Product Manager
For most developers, building an authentication system for your app can feel a lot like paying taxes. They are both relatively hard to understand tasks that you have no choice but doing, and could have big consequences if you get them wrong. No one ever started a company to pay taxes and no one ever built an app just so they could create a great login system. They just seem to be inescapable costs.
But now, you can at least free yourself from the auth tax. With Firebase Authentication, you can outsource your entire authentication system to Firebase so that you can concentrate on building great features for your app. Firebase Authentication makes it easier to get your users signed-in without having to understand the complexities behind implementing your own authentication system. It offers a straightforward getting started experience, optional UX components designed to minimize user friction, and is built on open standards and backed by Google infrastructure.
Implementing Firebase Authentication is relatively fast and easy. From the Firebase console, just choose from the popular login methods that you want to offer (like Facebook, Google, Twitter and email/password) and then add the Firebase SDK to your app. Your app will then be able to connect securely with the real time database, Firebase storage or to your own custom back end. If you have an auth system already, you can use Firebase Authentication as a bridge to other Firebase features.
Firebase Authentication also includes an open source UI library that streamlines building the many auth flows required to give your users a good experience. Password resets, account linking, and login hints that reduce the cognitive load around multiple login choices - they are all pre-built with Firebase Authentication UI. These flows are based on years of UX research optimizing the sign-in and sign-up journeys on Google, Youtube and Android. It includes Smart Lock for Passwords on Android, which has led to significant improvements in sign-in conversion for many apps. And because Firebase UI is open source, the interface is fully customizable so it feels like a completely natural part of your app. If you prefer, you are also free to create your own UI from scratch using our client APIs.
And Firebase Authentication is built around openness and security. It leverages OAuth 2.0 and OpenID Connect, industry standards designed for security, interoperability, and portability. Members of the Firebase Authentication team helped design these protocols and used their expertise to weave in latest security practices like ID tokens, revocable sessions, and native app anti-spoofing measures to make your app easier to use and avoid many common security problems. And code is independently reviewed by the Google Security team and the service is protected in Google’s infrastructure.
Fabulous uses Firebase Authentication to power their login system. Fabulous is a research-based app incubated in Duke University’s Center for Advanced Hindsight. Its goal is to help users to embark on a journey to reset poor habits, replacing them with healthy rituals, with the ultimate goal of improving health and well-being. The developers of Fabulous wanted to implement an onboarding flow that was easy to use, required minimal updates, and reduced friction with the end user. They wanted an anonymous option so that users could experiment with it before signing up. They also wanted to support multiple login types, and have an option where the user sign-in flow was consistent with the look and feel of the app. “I was able to implement auth in a single afternoon. I remember that I spent weeks before creating my own solution that I had to update each time the providers changed their API” Chu-Day is an application (available on Android and iOS) that helps couples to never forget the dates that matter most to them. It was created by the Korean firm Malang Studio, that develops character-centric, gamified lifestyle applications. Generally, countdown and anniversary apps do not require users to sign-in, but Malang Studio wanted to make Chu-day special, and differentiate it from others by offering the ability to connect couples so they could jointly countdown to a special anniversary date. This required a sign-in feature, and in order to prevent users from dropping out, Chu-day needed to make the sign-in process seamless. Malang Studio was able to integrate an onboarding flow in for their apps, using Facebook and Google Sign-in, in one day, without having to worry about server deployment or databases. In addition, Malang Studio has also been taking advantage of the Firebase User Management Console, which helped them develop and test their sign-in implementation as well as manage their users: “Firebase Authentication required minimum configuration so implementing social account signup was easy and fast. User management feature provided in the console was excellent and we could easily implement our user auth system.” For more about Firebase Authentication, visit the developers site and watch our I/O 2016 session, “Best practices for a great sign-in experience.” Originally posted on Firebase blog Posted by Laurence Moroney, Developer Advocate and Alfonso Gómez Jordana, Associate Product Manager For most developers, building an authentication system for your app can feel a lot like paying taxes. They are both relatively hard to understand tasks that you have no choice but doing, and could have big consequences if you get them wrong. No one ever started a company to pay taxes and no one ever built an app just so they could create a great login system. They just seem to be inescapable costs. But now, you can at least free yourself from the auth tax. With Firebase Authentication, you can outsource your entire authentication system to Firebase so that you can concentrate on building great features for your app. Firebase Authentication makes it easier to get your users signed-in without having to understand the complexities behind implementing your own authentication system. It offers a straightforward getting started experience, optional UX components designed to minimize user friction, and is built on open standards and backed by Google infrastructure. Implementing Firebase Authentication is relatively fast and easy. From the Firebase console, just choose from the popular login methods that you want to offer (like Facebook, Google, Twitter and email/password) and then add the Firebase SDK to your app. Your app will then be able to connect securely with the real time database, Firebase storage or to your own custom back end. If you have an auth system already, you can use Firebase Authentication as a bridge to other Firebase features. Firebase Authentication also includes an open source UI library that streamlines building the many auth flows required to give your users a good experience. Password resets, account linking, and login hints that reduce the cognitive load around multiple login choices - they are all pre-built with Firebase Authentication UI. These flows are based on years of UX research optimizing the sign-in and sign-up journeys on Google, Youtube and Android. It includes Smart Lock for Passwords on Android, which has led to significant improvements in sign-in conversion for many apps. And because Firebase UI is open source, the interface is fully customizable so it feels like a completely natural part of your app. If you prefer, you are also free to create your own UI from scratch using our client APIs. And Firebase Authentication is built around openness and security. It leverages OAuth 2.0 and OpenID Connect, industry standards designed for security, interoperability, and portability. Members of the Firebase Authentication team helped design these protocols and used their expertise to weave in latest security practices like ID tokens, revocable sessions, and native app anti-spoofing measures to make your app easier to use and avoid many common security problems. And code is independently reviewed by the Google Security team and the service is protected in Google’s infrastructure. Fabulous uses Firebase Authentication to power their login system. Fabulous is a research-based app incubated in Duke University’s Center for Advanced Hindsight. Its goal is to help users to embark on a journey to reset poor habits, replacing them with healthy rituals, with the ultimate goal of improving health and well-being. The developers of Fabulous wanted to implement an onboarding flow that was easy to use, required minimal updates, and reduced friction with the end user. They wanted an anonymous option so that users could experiment with it before signing up. They also wanted to support multiple login types, and have an option where the user sign-in flow was consistent with the look and feel of the app. “I was able to implement auth in a single afternoon. I remember that I spent weeks before creating my own solution that I had to update each time the providers changed their API” Chu-Day is an application (available on Android and iOS) that helps couples to never forget the dates that matter most to them. It was created by the Korean firm Malang Studio, that develops character-centric, gamified lifestyle applications. Generally, countdown and anniversary apps do not require users to sign-in, but Malang Studio wanted to make Chu-day special, and differentiate it from others by offering the ability to connect couples so they could jointly countdown to a special anniversary date. This required a sign-in feature, and in order to prevent users from dropping out, Chu-day needed to make the sign-in process seamless. Malang Studio was able to integrate an onboarding flow in for their apps, using Facebook and Google Sign-in, in one day, without having to worry about server deployment or databases. In addition, Malang Studio has also been taking advantage of the Firebase User Management Console, which helped them develop and test their sign-in implementation as well as manage their users: “Firebase Authentication required minimum configuration so implementing social account signup was easy and fast. User management feature provided in the console was excellent and we could easily implement our user auth system.” For more about Firebase Authentication, visit the developers site and watch our I/O 2016 session, “Best practices for a great sign-in experience.” 
Machine learning for all skill levels
Production-ready for common use cases
Deploy custom models
Better together with other Firebase products
Get started!
Machine learning for all skill levels
Production-ready for common use cases
Deploy custom models
Better together with other Firebase products
Get started!
For consumers
For developers
For consumers
For developers
Integration with Analytics events
Crash insights
"In the few weeks that we've been working with Crashlytics' crash insights, it's been quite helpful on a few particularly pesky issues. The description and quality of the linked resources makes it easy to immediately start debugging."
Pinning important builds
dSYM uploading
Firebase's default crash reporter
Linking Fabric and Firebase Crashlytics
Integration with Analytics events
Crash insights
"In the few weeks that we've been working with Crashlytics' crash insights, it's been quite helpful on a few particularly pesky issues. The description and quality of the linked resources makes it easy to immediately start debugging."
Pinning important builds
dSYM uploading
Firebase's default crash reporter
Linking Fabric and Firebase Crashlytics
Optimized for app development
Putting the 'Cloud' in Cloud Firestore
Another database?
Get started!
Optimized for app development
Putting the 'Cloud' in Cloud Firestore
Another database?
Get started!
The Cloud Where It Happens
What'd I miss?
Cloud Functions Left Us Satisfied
Developing UI? Don't Wait For It.
What comes next?
The Cloud Where It Happens
What'd I miss?
Cloud Functions Left Us Satisfied
Developing UI? Don't Wait For It.
What comes next?
Integrating with Fabric
Phone authentication comes to Firebase
Introducing Firebase Performance Monitoring
More robust analytics
Firebase for all - iOS, games, and open source
Dynamic Hosting with Cloud Functions for Firebase
Firebase Alpha program and what's next
Integrating with Fabric
Phone authentication comes to Firebase
Introducing Firebase Performance Monitoring
More robust analytics
Firebase for all - iOS, games, and open source
Dynamic Hosting with Cloud Functions for Firebase
Firebase Alpha program and what's next
Posted by Sridhar Ramaswamy, Senior Vice President, Ads and Commerce
I/O is a magical time at Google. Every year, thousands of developers gather in Google's backyard to share new product ideas and learn about our latest innovations in computing.
We're meeting at an exciting time for the developer community. It's a time when consumers have more choices than ever before—like where to shop, what to watch, which games to play and how to communicate with friends and family. Your product needs to stand out. You need tools to help your business grow. And you need to make sure your users are happy.
We think we can help.
This week, my team and I shared 3 new innovations for developers to make it easy for users to pay for your services, build profitable businesses and grow your user base.
Enabling users to pay with Google
Starting today, our suite of payment solutions will be expanding. The Google Payment API enables merchants and developers to turbocharge checkout conversion by offering your users an easy way to pay with credit and debit cards saved to their Google Account. Users will have multiple Google payment options at their fingertips, like a credit or a debit card previously saved via Android Pay, a payment card used to transact on the Play Store or a form of payment stored via Chrome. And they'll be able to use these saved payment options in third-party apps and mobile sites, as well as on Google Assistant when they are on-the-go.
Paying with Google for Panera Bread on Google Assistant
For users, this means faster checkout. Now they'll never miss a deal because they're stuck on a bus and don't want to pull out their credit card in front of strangers. They'll no longer experience the pain of stumbling on a sale that ends at midnight when they're tucked in bed with their credit card out of reach. Users can save time and headache by using credit and debit cards they've already saved to their Google Account whenever they see the option to pay with Google on supported apps or sites.
For developers, this API is a significant innovation that can enable faster checkout, drive more conversions, increase sales and reduce abandoned carts—all with a simple integration. Learn more about our Google Payment API here.
Earn more from your apps with the brand new AdMob
People turn to their mobile devices throughout the day to shop, communicate and stay entertained. For developers, in-app purchases are one way to monetize. Ads are another way.
AdMob was built to support the app ecosystem. With over 1 million apps across iOS and Android, AdMob has paid over $3.5 billion dollars in ads revenue to developers. But there's more we can do to help you succeed.
Today, we're introducing a completely redesigned AdMob. Rebuilt from the ground up, AdMob is now simpler to use and delivers richer insights about your users' in-app experiences.
Simpler to use: We've applied Material Design to all aspects of the AdMob look and feel to deliver an easy-to-use and intuitive experience across the entire platform—on mobile and desktop. You'll get more done in less time. Below you can see how easy it is to pick an app that you're monitoring, check out its key metrics and then quickly take action to fine-tune its performance.
Redesigned AdMob experience
Deeper insights: We've also integrated Google Analytics for Firebase into the core of the redesigned AdMob so you have quick access to the metrics that matter most for your business. Once you link your AdMob and Firebase accounts, you'll have access to detailed ad revenue data and user insights like time spent in the app and in-app purchases—all in one place.
Google Analytics for Firebase dashboard in AdMob
Know your user, find your user with Universal App Campaigns
Earning money from your app is one piece of the puzzle. You also need to think about how to grow your user base.
Google's app innovations have delivered over 5 billion installs from ads and we are now helping developers drive over 3 billion in-app events per quarter—like users adding something to their cart or reaching level 3 of a game. Developers have gravitated toward Universal App Campaigns (UAC) as the "one stop shop" campaign type that scales your reach and maximizes app installs across Google's largest properties: Google Play, Search, YouTube, Gmail and the Display Network. UAC uses Google's machine learning technology to evaluate numerous signals in real time, refining each ad to help you reach your most engaged users. We're continuing to double down on UAC, with all new innovations being built into UAC to make app promotion even more effective.
Engage users in key moments of discovery with new UAC placements in Google Play
Android reaches more than 2 billion active devices every month, with Google Play available in 190+ countries around the world. It's the place users come to discover new apps and games. Beyond searching for apps to try, users are increasingly browsing the Play store and finding recommendations for new apps.
To help those users discover more of your apps, we are introducing new ad placements on the home and app listing pages in the Google Play Store. These new placements, available exclusively through UAC, help you reach users in "discovery mode" as they swipe, tap and scroll in search of their next favorite app.
New ad placements reach users browsing in Google Play
Discover more of your best users with new bidding options in UAC
Some users are more valuable to your business than others, like the players who level-up in your game or the loyal travelers who book several flights a month. That's why we're expanding Smart Bidding strategies in UAC to help you acquire more of these high-value users. Using Smart Bidding, you can tailor bids for your unique business goals - target cost per acquisition (tCPA) or target return on ad spend (tROAS). UAC delivers the right users based on your objectives: installs, events and, coming soon, value. This update starts rolling out to iOS and Android developers and advertisers in the coming months.
Introducing App Attribution Partners, a new measurement program
Many developers rely on third-party measurement providers to measure the impact of ads and gain valuable insights about how users engage with your app. To help you take action on these insights in a faster and more seamless way, we are introducing App Attribution Partners, a new program designed to integrate data from 7 global companies right into AdWords.
As consumers live more of their lives online, it's increasingly important for developers to build user-centric experiences in everything that you do—from the apps you design, to the experiences you deliver, to the ways you help people transact. We know it's not always easy, so Google is here to help.
Welcome to adjust, Adways, AppsFlyer, Apsalar, CyberZ, Kochava and TUNE... we're thrilled to have them onboard!
AdWords' integration with these partners ensures that you have consistent, reliable and more granular data where you review app metrics. Now you can take action with confidence and stay on top of your business performance.
We look forward to continuing on this journey with you.
Cross posted from Inside AdMob
Posted by Sridhar Ramaswamy, Senior Vice President, Ads and Commerce
I/O is a magical time at Google. Every year, thousands of developers gather in Google's backyard to share new product ideas and learn about our latest innovations in computing.
We're meeting at an exciting time for the developer community. It's a time when consumers have more choices than ever before—like where to shop, what to watch, which games to play and how to communicate with friends and family. Your product needs to stand out. You need tools to help your business grow. And you need to make sure your users are happy.
We think we can help.
This week, my team and I shared 3 new innovations for developers to make it easy for users to pay for your services, build profitable businesses and grow your user base.
Enabling users to pay with Google
Starting today, our suite of payment solutions will be expanding. The Google Payment API enables merchants and developers to turbocharge checkout conversion by offering your users an easy way to pay with credit and debit cards saved to their Google Account. Users will have multiple Google payment options at their fingertips, like a credit or a debit card previously saved via Android Pay, a payment card used to transact on the Play Store or a form of payment stored via Chrome. And they'll be able to use these saved payment options in third-party apps and mobile sites, as well as on Google Assistant when they are on-the-go.
Paying with Google for Panera Bread on Google Assistant
For users, this means faster checkout. Now they'll never miss a deal because they're stuck on a bus and don't want to pull out their credit card in front of strangers. They'll no longer experience the pain of stumbling on a sale that ends at midnight when they're tucked in bed with their credit card out of reach. Users can save time and headache by using credit and debit cards they've already saved to their Google Account whenever they see the option to pay with Google on supported apps or sites.
For developers, this API is a significant innovation that can enable faster checkout, drive more conversions, increase sales and reduce abandoned carts—all with a simple integration. Learn more about our Google Payment API here.
Earn more from your apps with the brand new AdMob
People turn to their mobile devices throughout the day to shop, communicate and stay entertained. For developers, in-app purchases are one way to monetize. Ads are another way.
AdMob was built to support the app ecosystem. With over 1 million apps across iOS and Android, AdMob has paid over $3.5 billion dollars in ads revenue to developers. But there's more we can do to help you succeed.
Today, we're introducing a completely redesigned AdMob. Rebuilt from the ground up, AdMob is now simpler to use and delivers richer insights about your users' in-app experiences.
Simpler to use: We've applied Material Design to all aspects of the AdMob look and feel to deliver an easy-to-use and intuitive experience across the entire platform—on mobile and desktop. You'll get more done in less time. Below you can see how easy it is to pick an app that you're monitoring, check out its key metrics and then quickly take action to fine-tune its performance.
Redesigned AdMob experience
Deeper insights: We've also integrated Google Analytics for Firebase into the core of the redesigned AdMob so you have quick access to the metrics that matter most for your business. Once you link your AdMob and Firebase accounts, you'll have access to detailed ad revenue data and user insights like time spent in the app and in-app purchases—all in one place.
Google Analytics for Firebase dashboard in AdMob
Know your user, find your user with Universal App Campaigns
Earning money from your app is one piece of the puzzle. You also need to think about how to grow your user base.
Google's app innovations have delivered over 5 billion installs from ads and we are now helping developers drive over 3 billion in-app events per quarter—like users adding something to their cart or reaching level 3 of a game. Developers have gravitated toward Universal App Campaigns (UAC) as the "one stop shop" campaign type that scales your reach and maximizes app installs across Google's largest properties: Google Play, Search, YouTube, Gmail and the Display Network. UAC uses Google's machine learning technology to evaluate numerous signals in real time, refining each ad to help you reach your most engaged users. We're continuing to double down on UAC, with all new innovations being built into UAC to make app promotion even more effective.
Engage users in key moments of discovery with new UAC placements in Google Play
Android reaches more than 2 billion active devices every month, with Google Play available in 190+ countries around the world. It's the place users come to discover new apps and games. Beyond searching for apps to try, users are increasingly browsing the Play store and finding recommendations for new apps.
To help those users discover more of your apps, we are introducing new ad placements on the home and app listing pages in the Google Play Store. These new placements, available exclusively through UAC, help you reach users in "discovery mode" as they swipe, tap and scroll in search of their next favorite app.
New ad placements reach users browsing in Google Play
Discover more of your best users with new bidding options in UAC
Some users are more valuable to your business than others, like the players who level-up in your game or the loyal travelers who book several flights a month. That's why we're expanding Smart Bidding strategies in UAC to help you acquire more of these high-value users. Using Smart Bidding, you can tailor bids for your unique business goals - target cost per acquisition (tCPA) or target return on ad spend (tROAS). UAC delivers the right users based on your objectives: installs, events and, coming soon, value. This update starts rolling out to iOS and Android developers and advertisers in the coming months.
Introducing App Attribution Partners, a new measurement program
Many developers rely on third-party measurement providers to measure the impact of ads and gain valuable insights about how users engage with your app. To help you take action on these insights in a faster and more seamless way, we are introducing App Attribution Partners, a new program designed to integrate data from 7 global companies right into AdWords.
As consumers live more of their lives online, it's increasingly important for developers to build user-centric experiences in everything that you do—from the apps you design, to the experiences you deliver, to the ways you help people transact. We know it's not always easy, so Google is here to help.
Welcome to adjust, Adways, AppsFlyer, Apsalar, CyberZ, Kochava and TUNE... we're thrilled to have them onboard!
AdWords' integration with these partners ensures that you have consistent, reliable and more granular data where you review app metrics. Now you can take action with confidence and stay on top of your business performance.
We look forward to continuing on this journey with you.
Originally posted on the Firebase Blog
Posted by Francis Ma, Firebase Product Manager
Almost eight months ago, we launched
the expansion of Firebase to help developers build high-quality apps, grow their
user base, and earn more money across iOS, Android and the Web. We've already
seen great adoption of the platform, which brings together the best of Google's
core businesses from Cloud to mobile advertising.
Our ultimate goal with Firebase is to free developers from so much of the
complexity associated with modern software development, giving them back more
time and energy to focus on innovation.
As we work towards that goal, we've continued to improve Firebase, working
closely with our user community. We recently introduced
major enhancements to many core features, including Firebase Analytics, Test Lab
and Cloud Messaging, as well as added support for game developers with a C++ SDK
and Unity plug-in.
We're deeply committed to Firebase and are doubling down on our investment to
solve developer challenges.
Fabric and Firebase Joining Forces
Today, we're excited to announce that we've signed an agreement to acquire
Fabric to continue the great work that Twitter put into the platform. Fabric
will join Google's Developer Product Group, working with the Firebase team. Our
missions align closely: help developers build better apps and grow their
business.
As a popular, trusted tool over many years, we expect that Crashlytics will
become the main crash reporting offering for Firebase and will augment the work
that we have already done in this area. While Fabric was built on the foundation
of Crashlytics, the Fabric team leveraged its success to launch a broad set of
important tools, including Answers and Fastlane. We'll share further details in
the coming weeks after we close the deal, as we work closely together with the
Fabric team to determine the most efficient ways to further combine our
strengths. During the transition period, Digits, the SMS authentication services, will be maintained by Twitter.
The integration of Fabric is part of our larger, long-term effort of delivering
a comprehensive suite of features for iOS, Android and mobile Web app
development.
This is a great moment for the industry and a unique opportunity to bring the
best of Firebase with the best of Fabric. We're committed to making mobile app
development seamless, so that developers can focus more of their time on
building creative experiences.
Originally posted on the Firebase Blog
Posted by Francis Ma, Firebase Product Manager
Almost eight months ago, we launched
the expansion of Firebase to help developers build high-quality apps, grow their
user base, and earn more money across iOS, Android and the Web. We've already
seen great adoption of the platform, which brings together the best of Google's
core businesses from Cloud to mobile advertising.
Our ultimate goal with Firebase is to free developers from so much of the
complexity associated with modern software development, giving them back more
time and energy to focus on innovation.
As we work towards that goal, we've continued to improve Firebase, working
closely with our user community. We recently introduced
major enhancements to many core features, including Firebase Analytics, Test Lab
and Cloud Messaging, as well as added support for game developers with a C++ SDK
and Unity plug-in.
We're deeply committed to Firebase and are doubling down on our investment to
solve developer challenges.
Fabric and Firebase Joining Forces
Today, we're excited to announce that we've signed an agreement to acquire
Fabric to continue the great work that Twitter put into the platform. Fabric
will join Google's Developer Product Group, working with the Firebase team. Our
missions align closely: help developers build better apps and grow their
business.
As a popular, trusted tool over many years, we expect that Crashlytics will
become the main crash reporting offering for Firebase and will augment the work
that we have already done in this area. While Fabric was built on the foundation
of Crashlytics, the Fabric team leveraged its success to launch a broad set of
important tools, including Answers and Fastlane. We'll share further details in
the coming weeks after we close the deal, as we work closely together with the
Fabric team to determine the most efficient ways to further combine our
strengths. During the transition period, Digits, the SMS authentication services, will be maintained by Twitter.
The integration of Fabric is part of our larger, long-term effort of delivering
a comprehensive suite of features for iOS, Android and mobile Web app
development.
This is a great moment for the industry and a unique opportunity to bring the
best of Firebase with the best of Fabric. We're committed to making mobile app
development seamless, so that developers can focus more of their time on
building creative experiences.
Originally posted on the Firebase blog by Doug Stevenson /Developer Advocate
I've got to come clean with everyone: I'm making no new year's resolutions for
2017. Nor did I make any in 2016. In fact, I don't think I've ever made one!
It's not so much that I take a dim view of new year's resolutions. I simply
suspect that I would likely break them by the end of the week, and feel bad
about it!
One thing I've found helpful in the past is to see the new year as a pivoting
point to try new things, and also improve the work I'm already doing. For me
(and I hope for you too!), 2017 will be a fresh year for boosting app quality.
The phrase "app quality" can take a bunch of different meanings, based on what
you value in the software you create and use. As a developer, traditionally,
this means fixing bugs that cause problems for your users. It could also be a
reflection of the amount of delight your users take in your app. All of this
gets wrapped up into the one primary metric that we have to gauge the quality of
a mobile app, which is your app's rating on the store where it's published. I'm
sure every one of you who has an app on a storefront has paid much attention to
the app's rating at some point!
Firebase provides some tools you can use to boost your app's quality, and if
you're not already using them, maybe a fresh look at those tools would be
helpful this year?
Firebase Crash Reporting
The easiest tool to get started with is Firebase Crash Reporting. It takes
little to no lines of code to integrate it into your iOS and Android app, and
once you do, the Firebase console will start showing crashes that are happening
to your users. This gives you a "hit list" of problems to fix.
One thing I find ironic about being involved with the Crash Reporting team is
how we view the influx of total crashes received as we monitor our system. Like
any good developer product, we strive to grow adoption, which means we celebrate
graphs that go "up and to the right". So, in a strange sense, we like to see
more crashes, because that means more developers are using our stuff! But for
all of you developers out there, more crashes is obviously a *bad* thing, and
you want to make those numbers go down! So, please, don't be like us - make
your crash report graphs go down and to the right in 2017!
Firebase Test Lab for Android
Even better than fixing problems for your users is fixing those problems
before they even reach your users. For your Android apps, you can use
Firebase Test Lab to
help ensure that your apps work great for your users among a growing variety of
actual devices that we manage. Traditionally, it's been kind of a pain to
acquire and manage a good selection of devices for testing. However, with Test
Lab, you simply upload your APK and tests, and it will install and run them to
our devices. After the tests complete, we'll provide all the screenshots,
videos, and logs of everything that happened for you to examine in the Firebase
console.
With Firebase Test Lab for Android now available with generous daily quotas at
no charge for projects on the free Spark tier, 2017 is a great time to get
started with that. And, if you haven't set up your Android app builds in a
continuous integration environment, you could set that up, then configure it to
run your tests
automatically on Test Lab.
If you're the kind of person who likes writing tests for your code (which is,
admittedly, not very many of us!), it's natural to get those tests running on
Test Lab. But, for those of us who aren't maintaining a test suite with our
codebase, we can still use Test Lab's automated Robo test to
get automated test coverage right away, with no additional lines of code
required. That's not quite that same as having a comprehensive suite of tests,
so maybe 2017 would be a good time to learn more about architecting "testable"
apps, and how those practices can raise the bar of quality for your app. I'm
planning on writing more about this later this year, so stay tuned to the Firebase Blog for more!
Firebase Remote Config
At its core, Firebase
Remote Config is a tool that lets you configure your app using parameters
that you set up in the Firebase console. It can be used to help manage the
quality of your app, and there's a couple neat tricks you can do with it. Maybe
this new year brings new opportunities to give them a try!
First of all, you can use Remote Config to carefully roll out a new feature to
your users. It works like this:
This is much safer than publishing your new feature to everyone with a single
app update, because now you have the option to immediately disable a serious
problem, and without having to build and publish a whole new version of your
app. And, if you can act quickly, most of your users will never encounter the
problem to begin with. This works well with the email alerts you get from
Firebase Crash Reporting when a new crash is observed.
Another feature of Remote Config is the ability to experiment with some aspect
of your app in order to find out what works better for the users of your app,
then measure the results in Firebase Analytics. I don't know about you, but I'm
typically pretty bad at guessing what people actually prefer, and sometimes I'm
surprised at how people might actually *use* an app! Don't guess - instead, do
an experiment and know /for certain/ what delights your users more! It stands
to reason that apps finely tuned like this can get better ratings and make more
money.
Firebase Realtime Database
It makes sense that if you make it easier for you user to perform tasks in your
app, they will enjoy using it more, and they will come back more frequently.
One thing I have always disliked is having to check for new information by
refreshing, or navigating back and forward again. Apps that are always fresh
and up to date, without requiring me to take action, are more pleasant to use.
You can achieve this for your app by making effective use of Firebase Realtime Database
to deliver relevant data directly to your users at the moment it changes in the
database. Realtime Database is reactive by nature, because the client
API is designed for you set up listeners at data locations that get triggered in
the event of a change. This is far more convenient than having to poll an API
endpoint repeatedly to check for changes, and also much more respectful of the
user's mobile data and battery life. Users associate this feeling of delight
with apps of high quality.
What does 2017 have in store for your app?
I hope you'll join me this year in putting more effort into making our users
even more delighted. If you're with me, feel free to tweet me at @CodingDoug and tell me what you're up
to in 2017!
Originally posted on the Firebase blog by Doug Stevenson /Developer Advocate
I've got to come clean with everyone: I'm making no new year's resolutions for
2017. Nor did I make any in 2016. In fact, I don't think I've ever made one!
It's not so much that I take a dim view of new year's resolutions. I simply
suspect that I would likely break them by the end of the week, and feel bad
about it!
One thing I've found helpful in the past is to see the new year as a pivoting
point to try new things, and also improve the work I'm already doing. For me
(and I hope for you too!), 2017 will be a fresh year for boosting app quality.
The phrase "app quality" can take a bunch of different meanings, based on what
you value in the software you create and use. As a developer, traditionally,
this means fixing bugs that cause problems for your users. It could also be a
reflection of the amount of delight your users take in your app. All of this
gets wrapped up into the one primary metric that we have to gauge the quality of
a mobile app, which is your app's rating on the store where it's published. I'm
sure every one of you who has an app on a storefront has paid much attention to
the app's rating at some point!
Firebase provides some tools you can use to boost your app's quality, and if
you're not already using them, maybe a fresh look at those tools would be
helpful this year?
Firebase Crash Reporting
The easiest tool to get started with is Firebase Crash Reporting. It takes
little to no lines of code to integrate it into your iOS and Android app, and
once you do, the Firebase console will start showing crashes that are happening
to your users. This gives you a "hit list" of problems to fix.
One thing I find ironic about being involved with the Crash Reporting team is
how we view the influx of total crashes received as we monitor our system. Like
any good developer product, we strive to grow adoption, which means we celebrate
graphs that go "up and to the right". So, in a strange sense, we like to see
more crashes, because that means more developers are using our stuff! But for
all of you developers out there, more crashes is obviously a *bad* thing, and
you want to make those numbers go down! So, please, don't be like us - make
your crash report graphs go down and to the right in 2017!
Firebase Test Lab for Android
Even better than fixing problems for your users is fixing those problems
before they even reach your users. For your Android apps, you can use
Firebase Test Lab to
help ensure that your apps work great for your users among a growing variety of
actual devices that we manage. Traditionally, it's been kind of a pain to
acquire and manage a good selection of devices for testing. However, with Test
Lab, you simply upload your APK and tests, and it will install and run them to
our devices. After the tests complete, we'll provide all the screenshots,
videos, and logs of everything that happened for you to examine in the Firebase
console.
With Firebase Test Lab for Android now available with generous daily quotas at
no charge for projects on the free Spark tier, 2017 is a great time to get
started with that. And, if you haven't set up your Android app builds in a
continuous integration environment, you could set that up, then configure it to
run your tests
automatically on Test Lab.
If you're the kind of person who likes writing tests for your code (which is,
admittedly, not very many of us!), it's natural to get those tests running on
Test Lab. But, for those of us who aren't maintaining a test suite with our
codebase, we can still use Test Lab's automated Robo test to
get automated test coverage right away, with no additional lines of code
required. That's not quite that same as having a comprehensive suite of tests,
so maybe 2017 would be a good time to learn more about architecting "testable"
apps, and how those practices can raise the bar of quality for your app. I'm
planning on writing more about this later this year, so stay tuned to the Firebase Blog for more!
Firebase Remote Config
At its core, Firebase
Remote Config is a tool that lets you configure your app using parameters
that you set up in the Firebase console. It can be used to help manage the
quality of your app, and there's a couple neat tricks you can do with it. Maybe
this new year brings new opportunities to give them a try!
First of all, you can use Remote Config to carefully roll out a new feature to
your users. It works like this:
This is much safer than publishing your new feature to everyone with a single
app update, because now you have the option to immediately disable a serious
problem, and without having to build and publish a whole new version of your
app. And, if you can act quickly, most of your users will never encounter the
problem to begin with. This works well with the email alerts you get from
Firebase Crash Reporting when a new crash is observed.
Another feature of Remote Config is the ability to experiment with some aspect
of your app in order to find out what works better for the users of your app,
then measure the results in Firebase Analytics. I don't know about you, but I'm
typically pretty bad at guessing what people actually prefer, and sometimes I'm
surprised at how people might actually *use* an app! Don't guess - instead, do
an experiment and know /for certain/ what delights your users more! It stands
to reason that apps finely tuned like this can get better ratings and make more
money.
Firebase Realtime Database
It makes sense that if you make it easier for you user to perform tasks in your
app, they will enjoy using it more, and they will come back more frequently.
One thing I have always disliked is having to check for new information by
refreshing, or navigating back and forward again. Apps that are always fresh
and up to date, without requiring me to take action, are more pleasant to use.
You can achieve this for your app by making effective use of Firebase Realtime Database
to deliver relevant data directly to your users at the moment it changes in the
database. Realtime Database is reactive by nature, because the client
API is designed for you set up listeners at data locations that get triggered in
the event of a change. This is far more convenient than having to poll an API
endpoint repeatedly to check for changes, and also much more respectful of the
user's mobile data and battery life. Users associate this feeling of delight
with apps of high quality.
What does 2017 have in store for your app?
I hope you'll join me this year in putting more effort into making our users
even more delighted. If you're with me, feel free to tweet me at @CodingDoug and tell me what you're up
to in 2017!
Originally posted on Firebase blog
Posted by Fabian Schlup, Software Engineer
At Google I/O this May, Firebase announced a new suite of products to help developers build mobile apps. Firebase Analytics, a part of the new Firebase platform, is a tool that automatically captures data on how people are using your iOS and Android app, and lets you define your own custom app events. When the data's captured, it’s available through a dashboard in the Firebase console. One of my favorite cloud integrations with the new Firebase platform is the ability to export raw data from Firebase Analytics to Google BigQuery for custom analysis. This custom analysis is particularly useful for aggregating data from the iOS and Android versions of your app, and accessing custom parameters passed in your Firebase Analytics events. Let’s take a look at what you can do with this powerful combination.
How does the BigQuery export work?
After linking your Firebase project to BigQuery, Firebase automatically exports a new table to an associated BigQuery dataset every day. If you have both iOS and Android versions of your app, Firebase exports the data for each platform into a separate dataset. Each table contains the user activity and demographic data automatically captured by Firebase Analytics, along with any custom events you’re capturing in your app. Thus, after exporting one week’s worth of data for a cross-platform app, your BigQuery project would contain two datasets, each with seven tables:
Diving into the data
The schema for every Firebase Analytics export table is the same, and we’ve created two datasets (one for iOS and one for Android) with sample user data for you to run the example queries below. The datasets are for a sample cross-platform iOS and Android gaming app. Each dataset contains seven tables — one week’s worth of analytics data.
The following query will return some basic user demographic and device data for one day of usage on the iOS version of our app:
Since the schema for every BigQuery table exported from Firebase Analytics is the same, you can run any of the queries in this post on your own Firebase Analytics data by replacing the dataset and table names with the ones for your project.
The schema has user data and event data. All user data is automatically captured by Firebase Analytics, and the event data is populated by any custom events you add to your app. Let’s take a look at the specific records for both user and event data.
User data
The user records contain a unique app instance ID for each user (user_dim.app_info.app_instance_id in the schema), along with data on their location, device and app version. In the Firebase console, there are separate dashboards for the app’s Android and iOS analytics. With BigQuery, we can run a query to find out where our users are accessing our app around the world across both platforms. The query below makes use of BigQuery’s union feature, which lets you use a comma as a UNION ALL operator. Since a row is created in our table for each bundle of events a user triggers, we use EXACT_COUNT_DISTINCT to make sure each user is only counted once:
User data also includes a user_properties record, which includes attributes you define to describe different segments of your user base, like language preference or geographic location. Firebase Analytics captures some user properties by default, and you can create up to 25 of your own.
A user’s language preference is one of the default user properties. To see which languages our users speak across platforms, we can run the following query:
Event data
Firebase Analytics makes it easy to log custom events such as tracking item purchases or button clicks in your app. When you log an event, you pass an event name and up to 25 parameters to Firebase Analytics and it automatically tracks the number of times the event has occurred. The following query shows the number of times each event in our app has occurred on Android for a particular day:
If you have another type of value associated with an event (like item prices), you can pass it through as an optional value parameter and filter by this value in BigQuery. In our sample tables, there is a spend_virtual_currency event. We can write the following query to see how much virtual currency players spend at one time:
Building complex queries
What if we want to run a query across both platforms of our app over a specific date range? Since Firebase Analytics data is split into tables for each day, we can do this using BigQuery’s TABLE_DATE_RANGE function. This query returns a count of the cities users are coming from over a one week period:
We can also write a query to compare mobile vs. tablet usage across platforms over a one week period:
Getting a bit more complex, we can write a query to generate a report of unique user events across platforms over the past two weeks. Here we use PARTITION BY and EXACT_COUNT_DISTINCT to de-dupe our event report by users, making use of user properties and the user_dim.user_id field:
If you have data in Google Analytics for the same app, it’s also possible to export your Google Analytics data to BigQuery and do a JOIN with your Firebase Analytics BigQuery tables.
Visualizing analytics data
Now that we’ve gathered new insights from our mobile app data using the raw BigQuery export, let’s visualize it using Google Data Studio. Data Studio can read directly from BigQuery tables, and we can even pass it a custom query like the ones above. Data Studio can generate many different types of charts depending on the structure of your data, including time series, bar charts, pie charts and geo maps.
For our first visualization, let’s create a bar chart to compare the device types from which users are accessing our app on each platform. We can paste the mobile vs. tablet query above directly into Data Studio to generate the following chart:
From this chart, it’s easy to see that iOS users are much more likely to access our game from a tablet. Getting a bit more complex, we can use the above event report query to create a bar chart comparing the number of events across platforms:
Check out this post for detailed instructions on connecting your BigQuery project to Data Studio.
What’s next?
If you’re new to Firebase, get started here. If you’re already building a mobile app on Firebase, check out this detailed guide on linking your Firebase project to BigQuery. For questions, take a look at the BigQuery reference docs and use the firebase-analytics and google-bigquery tags on Stack Overflow. And let me know if there are any particular topics you’d like me to cover in an upcoming post.
Originally posted on Google Cloud Platform Blog
Posted by Sara Robinson, Developer Advocate
At Google I/O this May, Firebase announced a new suite of products to help developers build mobile apps. Firebase Analytics, a part of the new Firebase platform, is a tool that automatically captures data on how people are using your iOS and Android app, and lets you define your own custom app events. When the data's captured, it’s available through a dashboard in the Firebase console. One of my favorite cloud integrations with the new Firebase platform is the ability to export raw data from Firebase Analytics to Google BigQuery for custom analysis. This custom analysis is particularly useful for aggregating data from the iOS and Android versions of your app, and accessing custom parameters passed in your Firebase Analytics events. Let’s take a look at what you can do with this powerful combination.
How does the BigQuery export work?
After linking your Firebase project to BigQuery, Firebase automatically exports a new table to an associated BigQuery dataset every day. If you have both iOS and Android versions of your app, Firebase exports the data for each platform into a separate dataset. Each table contains the user activity and demographic data automatically captured by Firebase Analytics, along with any custom events you’re capturing in your app. Thus, after exporting one week’s worth of data for a cross-platform app, your BigQuery project would contain two datasets, each with seven tables:
Diving into the data
The schema for every Firebase Analytics export table is the same, and we’ve created two datasets (one for iOS and one for Android) with sample user data for you to run the example queries below. The datasets are for a sample cross-platform iOS and Android gaming app. Each dataset contains seven tables — one week’s worth of analytics data.
The following query will return some basic user demographic and device data for one day of usage on the iOS version of our app:
Since the schema for every BigQuery table exported from Firebase Analytics is the same, you can run any of the queries in this post on your own Firebase Analytics data by replacing the dataset and table names with the ones for your project.
The schema has user data and event data. All user data is automatically captured by Firebase Analytics, and the event data is populated by any custom events you add to your app. Let’s take a look at the specific records for both user and event data.
User data
The user records contain a unique app instance ID for each user (user_dim.app_info.app_instance_id in the schema), along with data on their location, device and app version. In the Firebase console, there are separate dashboards for the app’s Android and iOS analytics. With BigQuery, we can run a query to find out where our users are accessing our app around the world across both platforms. The query below makes use of BigQuery’s union feature, which lets you use a comma as a UNION ALL operator. Since a row is created in our table for each bundle of events a user triggers, we use EXACT_COUNT_DISTINCT to make sure each user is only counted once:
User data also includes a user_properties record, which includes attributes you define to describe different segments of your user base, like language preference or geographic location. Firebase Analytics captures some user properties by default, and you can create up to 25 of your own.
A user’s language preference is one of the default user properties. To see which languages our users speak across platforms, we can run the following query:
Event data
Firebase Analytics makes it easy to log custom events such as tracking item purchases or button clicks in your app. When you log an event, you pass an event name and up to 25 parameters to Firebase Analytics and it automatically tracks the number of times the event has occurred. The following query shows the number of times each event in our app has occurred on Android for a particular day:
If you have another type of value associated with an event (like item prices), you can pass it through as an optional value parameter and filter by this value in BigQuery. In our sample tables, there is a spend_virtual_currency event. We can write the following query to see how much virtual currency players spend at one time:
Building complex queries
What if we want to run a query across both platforms of our app over a specific date range? Since Firebase Analytics data is split into tables for each day, we can do this using BigQuery’s TABLE_DATE_RANGE function. This query returns a count of the cities users are coming from over a one week period:
We can also write a query to compare mobile vs. tablet usage across platforms over a one week period:
Getting a bit more complex, we can write a query to generate a report of unique user events across platforms over the past two weeks. Here we use PARTITION BY and EXACT_COUNT_DISTINCT to de-dupe our event report by users, making use of user properties and the user_dim.user_id field:
If you have data in Google Analytics for the same app, it’s also possible to export your Google Analytics data to BigQuery and do a JOIN with your Firebase Analytics BigQuery tables.
Visualizing analytics data
Now that we’ve gathered new insights from our mobile app data using the raw BigQuery export, let’s visualize it using Google Data Studio. Data Studio can read directly from BigQuery tables, and we can even pass it a custom query like the ones above. Data Studio can generate many different types of charts depending on the structure of your data, including time series, bar charts, pie charts and geo maps.
For our first visualization, let’s create a bar chart to compare the device types from which users are accessing our app on each platform. We can paste the mobile vs. tablet query above directly into Data Studio to generate the following chart:
From this chart, it’s easy to see that iOS users are much more likely to access our game from a tablet. Getting a bit more complex, we can use the above event report query to create a bar chart comparing the number of events across platforms:
Check out this post for detailed instructions on connecting your BigQuery project to Data Studio.
What’s next?
If you’re new to Firebase, get started here. If you’re already building a mobile app on Firebase, check out this detailed guide on linking your Firebase project to BigQuery. For questions, take a look at the BigQuery reference docs and use the firebase-analytics and google-bigquery tags on Stack Overflow. And let me know if there are any particular topics you’d like me to cover in an upcoming post.
Fabulous use Firebase Auth to quickly implement sign-in
- Amine Laadhari, Fabulous CTO.Malang Studio cut time-to market by months using Firebase Auth
- Marc Yeongho Kim, CEO / Founder from Malang StudioFabulous use Firebase Auth to quickly implement sign-in
- Amine Laadhari, Fabulous CTO.Malang Studio cut time-to market by months using Firebase Auth
- Marc Yeongho Kim, CEO / Founder from Malang Studio