In Firebase Crashlytics, you can view crashes and non-fatals by versions. Several of our customers take advantage of this filtering, especially to focus on their latest releases.
But sometimes too many versions can be a bad thing. Firebase Crashlytics - by default - shows you the last 100 versions we have seen. If you have a lot of debug versions created by developers, and by continuous Integration and deployment pipeline, you might soon start to not see the versions that really matter e.g., production builds.
So how do you make sure that this does not happen? Disabling Crash reporting initialization for debug builds is the simplest way of achieving this. Let's explore how to do this on iOS and Android.
For iOS apps, first check if you are manually initializing Crashlytics (this happens for Fabric apps that were linked to a Firebase app).
If you use Swift, search for the line Fabric.with([Crashlytics.self]) in AppDelegate.swift. If this line is present, then you are manually initializing Crashlytics, otherwise you are using automatic initialization.
Fabric.with([Crashlytics.self])
If you use ObjectiveC, search for the line [Fabric with:@[[Crashlytics class]]]; in AppDelegate.m. If this line is present, then you are manually initializing Crashlytics, otherwise you are using automatic initialization.
[Fabric with:@[[Crashlytics class]]];
For apps that are using manual initialization, you can just not initialize Crashlytics for DEBUG versions.
For Swift
#if !DEBUG Fabric.with([Crashlytics.self]) #endif
For ObjectiveC
#if !DEBUG [Fabric with:@[[Crashlytics class]]]; #endif
Firebase Crashlytics apps are automatically initialized by Firebase. You can turn off automatic collection with a new key to your Info.plist file:
Info.plist
firebase_crashlytics_collection_enabled
no
Then you can initialize it as shown in the examples above for Swift and ObjectiveC
For Android apps, first check if you are manually initializing Crashlytics (this happens for Fabric apps that were linked to a Firebase app). Search for Fabric.with in your project. If this line is present, then you are manually initializing Crashlytics. Otherwise, Crashlytics is being automatically initialized through Firebase.
Fabric.with
To disable Crashlytics in debug builds, you can make use of the BuildConfig.DEBUG flag. Edit the Fabric.with statement you found previously, adding a check for the DEBUG flag:.
BuildConfig.DEBUG
if (!BuildConfig.DEBUG) { Fabric.with(this, new Crashlytics()); }
Turn off Crashlytics initialization in your debug builds by creating a debug folder in your src directory and creating an AndroidManifest.xml with this snippet:
debug
src
<manifest xmlns:android="http://schemas.android.com/apk/res/android"> <application> <meta-data android:name="firebase_crashlytics_collection_enabled" android:value="no" /> </application> </manifest>
This snippet will be merged into the manifest of all of your debug variants, and will disable Crashlytics in those builds. If you'd prefer finer-grained control, you can use this approach for any variants you'd like to exclude.
Firebase Auth client SDKs make it possible to sign in as a Firebase user from federated identity providers, including Google, Facebook, and Twitter. The Firebase Auth team is always looking for opportunities to improve the auth experience for developers and users. We know that more sign-in options mean more opportunities to create the best app experience. That's why we are pleased to announce that you can now sign in to Firebase Auth using Microsoft and Yahoo!
Firebase Auth has added two new federated identity providers! Today, Microsoft and Yahoo join our growing list of providers. Applications that rely on these providers no longer have to handle custom credentials on the backend. With this simplified auth flow, developers can spend less time on implementing authentication and more time to spend on the core features of your application. Developers who implement Microsoft or Yahoo sign in for Firebase Auth will also get the benefit of a new, simpler way to get the provider credentials.
Signing in to Firebase with a given identity provider requires garnering a credential from that provider. This often involves including the provider's SDK and implementing the provider's sign-in methods before passing the credentials to Firebase Auth. For some providers, this can be particularly difficult on a native client, especially ones which do not support their own native SDKs. In order to remove the headache of implementing sign-in flows for these identity providers, we now offer generic OAuth2 provider sign-in.
Generic identity provider sign-in provides an easy means for developers to get that credential and use it to sign in by popping up a ChromeCustomTab on Android or a SafariViewController on iOS which will use the Web flow to generate the Identity Provider Credential, and then continue the sign in. Generic sign-in gives you many benefits:
Generic sign-in is available for Microsoft and Yahoo, and will be a feature of other identity providers in the future.
Ready to get started with Microsoft and Yahoo sign-in for Firebase Auth? Check out the guides linked below:
Microsoft Authentication for iOS
Microsoft Authentication for Android
Microsoft Authentication for Web
Yahoo Authentication for iOS
Yahoo Authentication for Android
Yahoo Authentication for Web
Quickstart for iOS
Quickstart for Android
Quickstart for Web
Hey, there Firebase Developers! We wanted to let you know of a new feature we added to Cloud Firestore, and that's the ability to increment (or decrement) numeric values directly in the database! Why is this a big deal? Because previously, if you wanted to increment a value in the database, you would need to use a transaction to keep it safe from concurrent writes.
For instance, imagine that your fitness app has a feature that allows groups of friends to pool their steps together for a "team step counter". Then, imagine Bob and Alice both have their current team's total steps recorded locally and try to add their values to it…
If both clients send down these new values at around the same time, it's possible for Alice's changes to be written first...
...and then for Bob's changes to come in and overwrite Alice's changes.
In the past, if you wanted to prevent this from happening, you would have to use a transaction. And while transactions are still a fine solution, they are a little more difficult to write, they don't support cases where the user is offline, and frankly, they seem a bit heavy-handed for something as simple as adding two numbers together.
So now, if you want Bob to record his 500 steps in the app, you can simply do that by asking the server to increment the step_counter value. In an iOS app, for instance, you would write code that looks a little something like this.
document("fitness_teams/Team_1"). updateData(["step_counter" : FieldValue.increment(500)])
With this call, the database would instantly make the change based on whatever value it has. So even if Alice sneaks in a change before Bob's request reaches the server, everything still works.
Now, there are two things to keep in mind when it comes to performing these operations:
First of all, if you do want to add some logic to your operation (like, for instance, making sure this new value doesn't go over or under a certain limit), you'll still need to use a transaction. Luckily, we will soon release a fantastic video all about transactions that I can heartily recommend as a completely unbiased observer.
Second, don't forget that documents are still limited to a sustained write limit of 1 QPS per document. I know it's tempting to look at these numeric functions and start making counters left and right in your database, but if you think these are values you're going to be updating more than once per second, you're still going to want to rely on something like our distributed counter solution.
As always, if you have questions, feel free to contact us on any of our support channels, or post questions on Stack Overflow with the google-cloud-firestore and firebase tags. Good luck, and have fun!
google-cloud-firestore and firebase tags
Firebase is returning to the Game Developers Conference this year in San Francisco to share how we're making Firebase even more powerful for game developers!
At the Google Mobile Developer Day on Monday, we announced:
In case you missed these announcements on stage, read on below for a quick recap. We'll also be at booth #P1501 starting tomorrow until the end of the week, and have a special session on Firebase for Games in the Cloud Developer Day track, so if you're at the GDC this year, please come say hello! We're excited to get your feedback, and learn more about how we can make these features and Firebase for Games even better in the future.
Here's a recap of the new Firebase updates for games developers:
Firebase Crashlytics is now available for Unity! Firebase Crashlytics helps you track, prioritize, and fix stability issues in real time. It synthesizes an avalanche of crashes into a manageable list of issues, provides contextual information, and highlights the severity and prevalence of crashes so you can pinpoint the root cause faster. You can also easily reproduce issues by reviewing breadcrumbs, a list of actions that the user performed before the error occurred.
Crashlytics was previously only available for Android and iOS, but you can now use that same powerful crash-reporting functionality in your Unity games!
With the same simplicity of all our Firebase for Unity SDKs, Crashlytics can be integrated directly via your Unity IDE with no extra steps required. Your team can also be alerted of issues using our Email, Slack, Jira and PagerDuty Integrations, or write your own triggers using Cloud Functions with Firebase Crashlytics triggers.
And last, but not least, you can export Crashlytics data into BigQuery for deeper-dives. For example, let's say you log a custom key when reporting a Crashlytics event like so:
Crashlytics.SetCustomKey("current_level", "3");
After you export your Crashlytics data to BigQuery, you will be able to see the distribution of crashes by level 3, or any other level or custom key you've used for your events! And you can use our Data Studio template to quickly analyze this data. This will make tracking and fixing issues in your Unity game development a whole lot easier.
Refer to our documentation to get started with Firebase Crashlytics for Unity.
For C++ developers out there, you can now use an open source SDK for your Firebase for Games integration! This means more control than ever when integrating with the Firebase toolset. You can now easily dig into the code to see or change what's happening within the SDK to better suit your game, or maintain your own branch of the client SDK and cherry pick specific changes you care about. And if there are other platforms you want to use that we haven't yet built support for, you have the option to extend the SDK.
Firebase Test Lab is a cloud-based app-testing infrastructure. With one operation, you can test your Android or iOS app across a wide variety of devices and device configurations, and see the results in the Firebase console. For native Android apps, what are called Robo tests can intelligently analyze the UI elements on-screen and crawl through them. For games, however, this isn't possible because all of your elements are typically in a GL/Vulkan/Metal View. Instead Robo will resort to Monkey Actions, where it will tap randomly.
It could take quite some time for a smoke test like this to complete though, which is why we're happy to announce new AI-assisted Monkey Actions to help test your games with Firebase Test Lab. This will significantly reduce the time it takes for a robot to make progress through your game's user interface and provide useful test results. Check out the before / after videos for Monkey Actions with and without AI-assistance to see the difference. Note the before video showing Monkey Actions without AI assistance takes about 35 seconds to start a game, versus 13 seconds with AI-assistance (the orange dots on the screen represent where the robot is tapping on the screen):
Monkey Actions without AI assistance starting a game.
AI-assisted Monkey Actions starting a game.
Firebase Authentication provides an end-to-end identity solution for your app, which allows you to authenticate and verify users with passwords, phone numbers and popular federated identity providers like Google, Facebook and Twitter.
For iOS games developers, we are pleased to announce that Firebase Authentication now also supports Game Center Authentication, so if an iOS user is already signed into Game Center, they can also sign-in to your app without having to go through an additional sign-in flow.
We'll be at booth #P1501 all throughout the conference starting from March 20th - March 22nd, and have a special presentation on the Cloud Developer Day track on Wednesday at 5:00PM! We hope to see you there.
And of course, you can always learn more about Firebase for Games at:
https://firebase.google.com/games/
Firebase is a great platform for developing rich mobile and web applications by leveraging the power and scale of the Google Cloud Platform. Firebase provides a wide range of composable backend services and SDKs that help developers overcome numerous challenges in app development including user authentication, data storage, notification delivery, and more.
In addition to the services and the SDKs, Firebase also offers security rules -- a powerful mechanism that helps enforce the security and logical correctness of your apps. The backend services use security rules to authorize and validate the requests made by client apps, and make sure they adhere to the policies that app developers have put in place. Today, you can use security rules to govern how your users interact with the Firebase Realtime Database, Cloud Storage, and Cloud Firestore. Rules in these Firebase products help you achieve two critical goals:
If you're using any Firebase product mentioned above, rules are essential. But you may have questions about how they fit into your application architecture. In order to shed some light on this subject, we'd like to share a few tips related to security rules and the Admin SDK.
As you explore security rules in depth, you will eventually discover that requests from the Firebase Admin SDK are not gated by rules. The Admin SDK is initialized with a service account, which gives the SDK full access to your data. In Firebase Realtime Database, you can scope the Admin SDK's privileges to a user ID, and enforce rules as usual. But other products, most notably Google Cloud Firestore, don't support this feature yet. You should be mindful about that when implementing server-side data access operations.
Because of the elevated privileges of service accounts and the Admin SDK, you should also make sure that they only get deployed in environments that you trust with administrative control of your project. Typical environments include servers controlled by the developers, and managed cloud environments like Google Cloud Functions and App Engine. On the other hand, end-user devices and web browsers where the application code is open for modification are inherently untrusted, and the Admin SDK should never be deployed in them.
Many applications have data that is critical to the operation of the app, but should never be modified by the users. Consider a forum app that promotes user engagement by awarding its participants points (think StackOverflow). Each forum post needs to be scored in near real-time so the users can track their progress, but the users themselves should never be able to change anyone's points, not even their own.
The simplest way to protect such application-managed data is to specify a rule that prevents all writes to the data from the users.
service cloud.firestore { match /databases/{database}/documents { function isAuthorized() { // Some function that grants users read access. } match /scores/{uid}/{document} { allow write: if false; // Nothing gets past me (except Admin of course). allow read: if isAuthorized(); // Grant read access as necessary. } } }
Then you can use the Admin SDK to implement backend services that keep the data up-to-date. For instance, you can implement a serverless function using Cloud Functions for Firebase that automatically executes whenever a user posts something in the forum. This function can determine how many points to award the user, and update the respective entries in the read-only scores collection.
scores
import * as admin from 'firebase-admin'; admin.initializeApp(); export const updateScores = functions.firestore.document('posts/{userId}/{postId}') .onCreate((snapshot, context) => { const score = calculateScore(snapshot); const userId = context.params.userId; const doc = admin.firestore().collection('scores').document(userId); return admin.firestore().runTransaction((txn) => { return txn.get(doc).then((snap) => { const current = snap.data().total || 0; txn.set(doc, {total: current + score}, {merge: true}); }); }); });
Since Cloud Functions is a trusted environment, the backend code can continue to update your data, while keeping users from doing something they are not allowed to.
Many applications need to deal with users in different roles. What individual users can do in the app usually depends on their roles. Let's take a MOOC (Massively Open Online Courses) app as an example, where there are teachers, students and TAs. Teachers and TAs should be able to view and update course content, but students should only be able to view the material.
In a Firebase app, user roles can be managed by setting custom claims on user accounts. This is a privileged operation that can only be performed in a backend environment, typically using the Admin SDK. Custom claims are additional information that we associate with user accounts in Firebase Auth, and this information becomes available in the ID tokens that Firebase issues to users upon sign in. You can inspect these claims via security rules to facilitate role-based access control.
Going back to our example MOOC app, we can use the following backed code to grant a user teacher role.
import * as admin from 'firebase-admin'; admin.initializeApp(); async function grantTeacherRole(userId: string) { await admin.auth().setCustomUserClaims(userId, {role: 'teacher'}); }
Now you can define a rule that only allows teachers and TAs write-access to the courses collection.
courses
service cloud.firestore { match /databases/{database}/documents { function isTeacher() { return request.auth.token.role == "teacher"; } function isTA() { return request.auth.token.role == "ta"; } match /courses/{doc} { allow write: if isTeacher() || isTA(); // Only teachers and TAs can write. allow read: if true; // But anybody can read. } } }
Note that Firebase client SDKs cache ID tokens up to an hour. Therefore changes to a user's custom claims may take up to an hour to take effect.
Sometimes you want the ability to withhold some data from users until an administrator or a backend service determines it's time to release the data. For example, consider an automated process that grades tests in a MOOC app. You would want this process to finish grading all the tests before any scores are shared with the students. In this case the grading process should be able to update any Firestore document, and it can be deployed in a trusted backend environment. Therefore you can use the Admin SDK to implement it.
To make sure the intermediate states of data are not visible to users, you can create each document with a visibility attribute set to "private". Then in security rules, restrict access to only those documents whose visibility attribute is set to "public". Here's what this rule would look like:
visibility
"private"
"public"
service cloud.firestore { match /databases/{database}/documents { function isPublic() { return resource.data.visibility == "public"; } match /grades/{document} { allow read: if isPublic(); // Cannot read unless marked as "public". allow write: if false; // Nobody except Admin can update the documents. } } }
With the above rules configuration in place, all documents created with the visibility attribute set to "private" are inaccessible to the end-users. When the backend process is ready to release a document to the users, it can use the Admin SDK to change the visibility attribute of the target document to "public".
import * as admin from 'firebase-admin'; admin.initializeApp(); async function gradeTests() { // Create a new document and continue to write to it. const doc = await createNewDoc(); await updateGrades(doc); // Later, make the document visible when ready. await releaseGrades(doc); } async function createNewDoc() { const doc = admin.firestore().collection('grades').document(); // Make the new doc hidden by default await doc.set({visibility: 'private'}); return doc; } async function releaseGrades(doc) { await doc.update({visibility: 'public'}); }
As soon as the visibility attribute is set to "public" on a document, it will start appearing in matching Firestore queries executed by users.
It can be tempting to write rules that apply across collections -- for example, writing a rule that grants teachers in the MOOC app access to all documents in the database. In such situations, remember that rules will grant access to a document if any match statement in the rules configuration grants access. When multiple rules apply to the same document, it is easy to forget that any rule that allows access, overrides all the other rules that deny access.
service cloud.firestore { match /databases/{database}/documents { match /reports/{document} { // This rule is intended to selectively grant users read-only access to the // documents in the 'reports' collection. But the rule below inadvertently // grants teachers read-write access to these documents. allow read: if isConditionMet(); allow write: if false; } match /{document=**} { // This rule matches all documents in the database, including the 'reports' // collection. In case of teachers, this will override the previous rule. allow read, write: if isTeacher(); } } }
To avoid accidentally granting users access to protected data in your app, you should try to write rules in a manner so that each document only matches a single rules statement. One way to make that easier is to avoid wildcards that match collections ({document=**}), and only use wildcards that match documents ({document}). If you're tempted to define overarching rules, consider if the Admin SDK would be a better fit, because as we learned in the Tip #1, requests from the Admin SDK bypasses security rules.
{document=**}
{document}
As your apps grow and evolve over time, you may implement various administrative tools to manage your app's data. For example, you may want to implement a tool that backs up certain Firestore collections or RTDB paths. Or you are trying to meet specific privacy requirements, and you want to implement a service that deletes user data when the data becomes obsolete or when the users demand it. Such tools typically require unrestricted access to large portions of your database.
At first this may look like a good reason to have a relaxed set of security rules. But you should strive to write the most detailed and restrictive rules that describe the access patterns of your app. Administrative tools should be implemented using the Admin SDK, and deployed in a privileged environment that you control. This way your admin tools can retain full access to all the data, while closely regulating what end-users can do in the app.
In some situations you may want to temporarily deny a user access to data. Perhaps the monitoring infrastructure of your forum app has just detected a user posting spam, and you want to prevent that user from posting any more content until you can conduct a thorough investigation of the incident. You can use security rules to implement a simple access control list (ACL) on top of Firestore, and use the Admin SDK to dynamically manage it. You would start by declaring a rule like the following:
service cloud.firestore { match /databases/{database}/documents { function isBlackListed() { return exists(/databases/$(database)/documents/blacklist/$(request.auth.uid)) } // Collections are closed for reads and writes by default. This match block // is included for clarity. match /blacklist/{entry} { allow read: if false; allow write: if false; } match /posts/{postId} { allow write: if !isBlackListed() } } }
This mentions a Firestore collection named blacklist that no user can read or write. It also uses the exists built-in function to check if a document with a given key exists in the Firestore database. If you haven't seen this pattern before, built-in functions like exists and get enable us to access Firestore documents from security rules. In this case, if we find a user ID in the blacklist collection, we prevent the corresponding user from writing to the posts collection. Now we can use the Admin SDK to add users to the blacklist collection, and revoke their write-access:
blacklist
exists
get
posts
await revokeWriteAccess('bAdAgEnT'); async function revokeWriteAccess(userId) { const user = admin.firestore().collection('blacklist').document(userId) await user.set({ reason: 'possible bad agent', blacklisted_at: admin.firestore.FieldValue.serverTimestamp(), }); }
Since you have already locked down all access to the blacklist collection, you can rest assured that only the Admin SDK (i.e. our backend code) can make modifications to it. Changes to the ACL take effect immediately. To grant a user access to the data again, simply remove the corresponding document with the user ID from the blacklist collection.
Note that we are also writing the current timestamp to the same document when adding a user to the blacklist. If you want, you can write a rule that references this property to automatically grant blacklisted users access after a cool off period.
service cloud.firestore { function isTwoDaysElapsed() { return request.time > timestamp.value(get(/databases/$(database)/documents/ blacklist/$(request.auth.uid)).data.blacklisted_at.seconds*1000) + duration.value(2, 'd'); } match /databases/{database}/documents { match /posts/{postId} { // allow if blacklisted more than 2 days ago allow write: if isTwoDaysElapsed(); } } }
Firebase takes a declarative approach to ensuring the security and logical correctness of your apps. By keeping the rules separate from application code, you can easily update your security policies, while keeping the application code simple. As many developers know by experience, code changes are harder to make, and even harder to test and deploy. But with Firebase, you can rapidly iterate on your rules without having to touch the application code at all. Moreover, you can patch any detected security vulnerabilities instantly, without having to go through a long and arduous app rollout.
You can also use rules in conjunction with the Firebase Admin SDK to implement sophisticated use cases that involve server-side code. Admin SDK is not subjected to rules checks, but this extra degree of freedom enables some useful patterns that can be applied to multiple real world applications. You can implement any server-side components using the Admin SDK and deploy them in trusted environments like Google Cloud Functions, while subjecting the client-side apps to stricter constraints.
Read more about Firebase security rules and the Admin SDK in our documentation. If you have used these tools to solve any interesting problems, we'd love to hear about your experience. Happy coding with Firebase!
Here at Firebase, we work hard to keep your apps secure and protect your users. In keeping with that mission, we're proud to announce that we recently implemented Certificate Transparency for the Realtime Database.
Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates. These attack vectors are rare but serious ways of circumventing the protections that SSL/TLS grants to online communication.
Part of Certificate Transparency is the issuance of a Signed Certificate Timestamp (SCT), which Realtime Database responses now include. We have already been sending the SCT when browsers like Chrome requested it, but now it is always bundled in the response.
From today on, every connection from one of your users to your database will be protected by the SCT. Please be aware that the SCT creates a little more SSL overhead, so each response gets slightly larger. The percentage increase for your app is dependent on many factors, such as your average response size, and which clients your customers use. Since outgoing bandwidth (egress) is billed, you may see a slight bill increase as a result.
Certificate Transparency is a great enhancement to SSL/TLS, and we Firebasers are excited about what it means for the security of the internet going forward. We're delighted to bring this protection to you and your users.
If you are a user of Firebase Cloud Messaging (FCM), you know that there are many different ways to send messages. You can target an application on a device, or target millions of them through the topics API. FCM APIs tell you if there was a failure during the acceptance of the request by returning an error code and an explanation for the failure, but this only covers the part of the request between you and the FCM backend. What happens after FCM accepts your message request?
In this post, we will look into the Firebase Cloud Messaging infrastructure and how messages are actually delivered to devices.
When FCM returns a successful response to your API request, it simply means that FCM will start trying to deliver this message to the device or to the service responsible for delivering the message to the device (for example: Apple Push Notification service for delivery to iOS devices or Mozilla Push Service for delivery to Firefox browsers). It will try this until:
Note: If the time to live of the pending messages has expired, the above functions will not be triggered.
There are many factors that affect the actual delivery of the message to the device and the amount of information FCM can provide about the delivery.
Note: If you'd like to analyze message delivery events for your project, you can do so by exporting FCM data into BigQuery.
On iOS, there are two ways in which FCM can send a message to a device:
Note: If you'd like to access iOS notification delivery information for display notifications, you can use the FCM Reporting Dashboard. This dashboard leverages Google Analytics for Firebase data sharing features to collect delivery information through Firebase Android and iOS SDKs for display notifications.
See Lifetime of a Message and Understanding Message Delivery if you'd like to learn more about message acceptance and delivery.
This article originally appeared on the Google Marketing Platform blog.
For businesses to make the best decisions about where to invest their marketing budget, it's critical that they understand user behavior on both their web and app properties. And while a website is often the first customer touchpoint, for many businesses, apps are where customers are spending more of their time. As a result, marketers need to capture audience insights from their app analytics that they can then take action on, both within and outside of their apps.
Google Analytics for Firebase, our app analytics solution, has historically given you the ability to organize your audiences around events, device type, and other dimensions. These criteria were not exhaustive, however, or dynamic as user behavior changed over time.
That's why we've made enhancements to the audience builder experience, with a few major updates to help you identify relevant app audiences more easily and with greater precision:
These new tools make audiences more powerful, flexible and actionable than before, so you can be confident that your insights reflect relevant users and activity on your apps. In 2019, we will continue to enhance the Google Analytics for Firebase audience builder, offering even more ways to precisely create audiences.
Take action once you've identified relevant audiences
Once you've improved your understanding of users, you can also deliver personalized experiences based on varying user needs. For example, through push notifications or Remote Config in Firebase, or customized ads in Google Ads.
Let's say you have an e-commerce app. Using these advanced audience capabilities, you can build an audience of users that visit your app for the first time and add an item to their cart, but don't make a purchase—and only include those who do so in a 30 day window.
Build a dynamic audience for first time users that have abandoned their cart.
You can now reach that audience with tailored messaging relevant to their experience with the app, and encourage them to make the purchase through an in-app promotion, email notification, or personalized ad. Once these users have returned to the app, made a purchase, and/or exceeded the 30 day window however, they will no longer meet the criteria for that audience, and you will not adversely affect their experience with marketing that is no longer relevant to them.
With the ability to create dynamic audiences, you are able to understand your users with better precision. A better view into your audiences means more insight into the customer journey, so you can invest in your marketing activities with confidence and see better results—keeping users happy, and your app growing.
Hey there, Firebase developers! Did you hear the news? Cloud Firestore — our NoSQL database in the cloud for mobile and web apps — is officially out of beta and in General Availability!
Great! So… why's that a big deal?
The move from beta to GA is significant for a number of reasons. For starters, it's Google's way of saying that we're confident in Cloud Firestore's ability to handle your toughest database needs. And you can rely on Cloud Firestore to power all kinds of apps — from experimental prototypes to mission critical enterprise-scale applications.
Moving into GA also has some practical benefits. One of the most important is that Cloud Firestore is now included in GCP's official Service Level Agreements (or SLAs, as they're commonly known). This means you now have guaranteed uptime — 99.999% for multi-region instances of Cloud Firestore, and 99.99% for regional instances.
In addition, now that Cloud Firestore is out of beta, important programs like GCP's deprecation policy officially apply to Cloud Firestore, and Cloud Firestore is now included among our list of services that support HIPAA compliance.
New lower pricing tier — coming soon!
We're also excited to announce a new lower pricing tier (up to 50% off) for most regional instances of Cloud Firestore. And if you're wondering what exactly I mean by "regional" and "multi-region", let's explain:
To over-simplify things a bit, when you have a Cloud Firestore database installed in a multi-region location, exact copies of your database are created in multiple data centers at least a few hundred miles apart from each other. This is great from a reliability standpoint; even if one region were to completely go offline due to a natural disaster or giant radioactive lizard attack, your database would continue to be hosted from the other two.
Even better, this whole setup is completely transparent to you. When you write new values to the database, you're able to read them right away, and not have to worry about whether or not they've fanned out to all of the other regions properly. This is known as being strongly consistent, and honestly, it's a pretty amazing piece of tech that will impress your database aficionado friends.
That said, creating a strongly consistent multi-region database is pretty heavy-duty tech that requires a lot of infrastructure. And while all of that is important for mission critical applications, it might be overkill for some of your other apps, and you might be perfectly happy with the guaranteed 99.99% uptime that comes from having Cloud Firestore hosted in a single region. (Usually just referred to as "regional" locations.)
So to help reflect these differences, we're going to start lowering prices on most of our regional instances of Cloud Firestore in the next month or two. The price will vary by location, but the discount will be as much as 50%. Once this new pricing goes into effect on March 3rd, 2019, it will be applied automatically to those of you who have Cloud Firestore databases hosted in those regional instances.
New locations, too!
As long as we're talking about data center locations, we've added several new locations around the world to host your Cloud Firestore data. There will be a new multi-region location in Europe, and then 9 additional regional locations, including a few in Asia, Australia, North and South America, and Europe. Be sure to check out the Google Cloud blog post for the complete list.
We believe these new locations will give you the tools to help address your local regulations around data storage, and better serve the needs of your customers who might be concentrated in certain areas around the globe. You can select your Cloud Firestore location when you first create your Firebase project, so make sure to pick the location that will provide the best experience for your customers.
Better usage tracking, powered by Stackdriver
One of the biggest concerns we've heard from developers when they're using a tool like Cloud Firestore is that they're not very confident in their app's database usage, and they're worried about the day when a bill arrives in the mail for more than they expected because they had underestimated their app's database usage.
So to help address this, we're going to be adding a new "Usage" tab in the Firebase console to show you exactly how many reads, writes, and deletes your database has received over time. These are the operations that drive the majority of your Cloud Firestore pricing, so making sure you know what your traffic is like in these three areas is critical to keeping a handle on your costs.
These graphs are certainly helpful, but what's really exciting about these usage reports is that they're being powered by Stackdriver, Google Cloud's incredibly flexible monitoring and reporting toolkit. And one really nice feature about Stackdriver is that you can set up your own custom alerts if any of the metrics its measuring go outside certain ranges.
So if you want to receive an email (or PagerDuty notification, or a Slack message) when your database receives more reads than you were expecting in a one-hour period, you can do that. You can also receive alerts if your traffic spikes an unusual amount compared to normal, or if your overall traffic drops below a certain level.
Please note that this usage tab is currently in beta, and while there's a lot more you already can do with Stackdriver (including building your own custom dashboards), we'll be looking to add more Cloud Firestore metrics to Stackdriver in the future. Look for this new Usage tab to appear in the Firebase console in the next few days!
Give it a try today!
Even in beta, Cloud Firestore was driving some fantastic app experiences — with partners like The New York Times, Skip Scooters, QuintoAndar, Nerdery, and more building some really great features powered by Cloud Firestore.
And now that we're in General Availability, this a great time to get started using Cloud Firestore to power your apps. We've got a lot of documentation and samples get started with, and a fun little video series that I am legally obligated to plug. So give it a look, and happy databasing!
What's the deal with audiences?
So if you've never used audiences before, they can be a really powerful way to segment your user base so that you can deliver tailored and relevant experiences to specific groups of users. Maybe that's sending them a customized notification in Firebase Cloud Messaging, maybe that's creating a unique experience for them in Remote Config, or maybe that's targeting them with a remarketing campaign in Google Ads.
We at the Firebase office all enjoyed playing with Hanley Weng's "CoreML-in-ARKit" project. It displays 3D labels on top of images it detects in the scene. While the on-device detection provides a fast response, we wanted to build a solution that gave you the speed of the on-device model with the accuracy you can get from a cloud-based solution. Well, that's exactly what we built with our MLKit-ARKit project. Read on to find out more about how we did it!
This image takes a while to load, but it’s worth it.
ML Kit for Firebase is a mobile SDK that enables developers to bring Google's machine learning (ML) expertise to their Android and iOS apps. It includes easy-to-use on-device and cloud-based Base APIs and also offers the ability to bring your own custom TFLite models.
ARKit is Apple's framework that combines device motion tracking, camera scene capture, advanced scene processing, and display conveniences to simplify the task of building an AR experience. You can use these technologies to create many kinds of AR experiences using either the back camera or front camera of an iOS device.
In this project we are pushing ARKit frames from the back camera into a queue. ML Kit processes these to find out the objects in that frame.
When the user taps the screen, ML Kit returns the detected label with the highest confidence. We then create a 3D bubble text and add it into the user's scene.
ML Kit makes ML easy for all mobile developers, whether you have experience in ML or are new to the space. For those with more advanced use cases, ML Kit allows you to bring your own TFLite models, but for more common use cases, you can implement one of the easy-to-use Base APIs. These APIs cover use cases such as text recognition, image labeling, face detection and more. We'll be using image labeling in our example.
Base APIs are available in two flavors: On-device and cloud-based. The on-device APIs are free to use and run locally, while the cloud-based ones provide higher accuracy and more precise responses. Cloud-based Vision APIs are free for the first 1000/API calls and paid after that. They provide the power of full-sized models from Google's Cloud Vision APIs.
We are using the ML Kit on-device image labeling API to get a live feed of results while keeping our frame rate steady at 60fps. When the user taps the screen we fire up an async call to the Cloud image labeling API with the current image. When we get a response from this higher accuracy model, we update the 3D label on the fly. So while we are continuously running the on-device API and using its result as the initial source of information, the higher accuracy Cloud API is called on-demand and its results replaces on-device label eventually.
Which result to show?
While the on-device API is real-time with all the processing happening locally, the Cloud Vision API makes a network request to the Google Cloud backend, leveraging a larger, higher accuracy model. Once the response arrives, we replace the label provided by the on-device API with the result from Cloud Vision API.
1. Clone the project
$ git clone https://github.com/FirebaseExtended/MLKit-ARKit.git
2. Install the pods and open the .xcworkspace file to see the project in Xcode.
$ cd MLKit-ARKit
$ pod install --repo-update
$ open MLKit-ARKit.xcworkspace
GoogleService-Info.plist
At this point, the app should work using the on-device recognition.
★ The cloud label detection feature is still free for first 1000 uses per month. Click here to see additional pricing details.
At this point, the app should update labels with more precise results from the Cloud Vision API.
Firebase launched over six and a half years ago as a database, but since then we've grown into a platform of eighteen (18!!) products. And over the last year we've announced a number of new features to help you build better apps and grow your business. We also infused Firebase with more machine learning super-power, so you can make your apps smarter, and matured the platform, so Firebase works better for developers at large, sophisticated enterprises.
Since the end of the year is a great time for top-ten lists, we were going to cap off the year with our own "Top Ten List of Firebase launches." But, then, we realized we had more than ten launches we wanted to talk about, and we really don't like playing favorites. So instead, here's our "Thirteen Firebase Launches In No Particular Order Because They're All Great In Their Own Way" list for 2018. Enjoy!
At Google I/O, we launched one of our most exciting features of 2018: ML Kit for Firebase, a machine learning SDK for Android and iOS. ML Kit lets you add the power of machine learning to your app, without needing an advanced degree in neutral networks. It provides a number of out-of-the-box solutions for performing tasks like recognizing text in images, labeling objects in photos, or detecting faces. And it will also let you use custom models, for those of you who are into building your own. (Bespoke artisanal neural networks are big among hipster data scientists these days.)
Notifications are a great way to get latent users back into your app, but how do you communicate with active users who are actively using your app? In 2018, we launched Firebase In-App Messaging to help you send targeted and contextual message to users who are actively using your app. In-app messages are a great way to encourage app exploration and discovery, and guide users towards discovering new features in your product, or working their way towards that important conversion event.
At Firebase, we're big fans of building scripts to make our lives easier; whether that's to automate common tasks, or to perform custom logic. To help with that goal, we launched three new REST APIs that you can use to automate your life (at least from a Firebase perspective). The Firebase Management API is great for automating tasks like creating new projects, the Remote Config REST API can be useful for customizing the way you update Remote Config values, and the Firebase Hosting API can be used to automatically upload certain files to your site.
Recently, StackBlitz and Glitch used the Management API to build integrations that allow you to deploy projects directly to Firebase Hosting. Start a project, write some code, click a few buttons, and voila! You've deployed your Firebase project to the web!
Good performance is one of the key factors for creating a great user experience. Firebase Performance Monitoring automatically collects performance metrics where it matters the most: the real world.
This year, Performance Monitoring graduated from beta into general availability. Along the way, we added helpful new features like an issue feed in the dashboard to highlight important performance problems your users are encountering. We've also added session view support for network class and traces, which lets you dig deeper into an individual session of a trace, so you see attributes and events that happened leading up to a performance issue.
We also released Firebase Predictions into GA. Predictions uses machine learning to intelligently segment users based on their predicted future behavior. Along the way, we added health indicators and evaluation criteria to every prediction, so you can better understand how reliable a prediction is, as well as the data being used to make it. We also integrated Predictions with BigQuery, so you have more control over your data.
Getting started with Predictions is as easy as flipping a switch in the console. We predict you're going to love it! (Sorry.)
The general availability party keeps on going! Cloud Functions hit GA and we also released a new version of the SDK. The new SDK adds "callable" functions that make it much easier to call server functions from the client, especially if your function requires authentication.
Cloud Functions also released a brand new library, firebase-functions-test, to simplify unit testing functions. This library takes care of the necessary setup and teardown, allowing easy mocking of test data. So in addition to simple standalone tests, you can now write tests that interact with a development Firebase project and observe the success of actions like database writes.
firebase-functions-test
Firebase Test Lab went cross-platform in 2018 by adding support for iOS. Now you can write and run tests on real iOS devices running in our data centers. Test Lab supports ten models of iPhones and iPads running seven different versions of iOS, including iOS 12.
Test Lab also launched a number of improvements to Robo, a tool which runs fully automated tests on Android devices. Testing games is now easier, thanks to 'monkey actions' (which can randomly click on your screen), and game loops (which perform pre-scripted actions). You can also customize Robo better now, in case you need to sign-in at the start of your app or add intelligent text to a search field.
Continuing the theme of testing, in 2018, we launched emulators for Firestore and the Realtime Database, so you can more easily unit test your security rules and incorporate them into a continuous integration environment. These emulators run locally and allow you to test your security rules offline so you can be confident before deploying to production. We also created a testing library that simplifies your test code.
From the beginning, Cloud Functions has tightly integrated important usage metrics with Stackdriver, Google Cloud's powerful monitoring service. To deepen our integration further, we linked the Realtime Database with Stackdriver. You can now see even more metrics than the Firebase console provides, such as load broken down by operation type and information about your downloaded bytes.
The real power of this integration is to set up alerts on metrics or errors so you can detect and respond to issues before your customers notice them.
Sometimes the reporting dashboards in the Firebase console don't give you the level of granularity or specific data slice that you need. That's where BigQuery - Google Cloud's data warehouse - and Data Studio - Google Cloud's data visualization tool - come into play.
We've given you the ability to export your Analytics data to BigQuery for a while now. This year, we added integrations with Predictions and Crashlytics, so you can export even more of your Firebase data into one central warehouse. Learn more about using Firebase and BigQuery together here.
Cloud Firestore is our next generation database with many of the features you've come to love from the Realtime Database, combined with the scale and sophistication of the Google Cloud Platform. Over the course of 2018, we've launched a number of improvements to Firestore, to make it better suited for complex enterprises.
We also added some nice features along the way -- we expanded offline support for the web SDK from one browser tab to multiple. We've added better support for searching documents by the contents of their arrays. And we added multiple new locations where you can store your Firestore data: Frankfurt, Germany and South Carolina, USA. (We'll be adding even more locations in 2019.)
The Firebase console is a crucial part of the Firebase workflow for just about any team. We spent a lot of time in 2018 making the console better than ever. Here's a few things we added:
These features make you more productive and confident in your app's security and performance. We can't wait to add more to the console in 2019!
For a while now, we've been hearing from some of you that you'd like an option to get enterprise-grade support for Firebase. To address that request, we added support for Firebase to our Google Cloud Platform (GCP) support packages, available in beta right now.
If you already have a paid GCP support package, our beta will let you get your Firebase questions answered through the GCP support channel - at no additional charge. When this new support graduates to general availability, it will include target response times, technical account management (for enterprise tier), and more. You can learn more about GCP support here.
If you're planning to stick with Firebase's free support, don't worry - we don't plan to change anything about our existing support model. Please continue to reach out to our friendly support team for help as needed!
It's been a great year, so we're going to take a little time with friends and family before we hit the ground running in January. However you celebrate the end of your year, we hope your December is full of happiness and relaxation. And if it happens to be full of building mobile or web apps, we hope you use Firebase! Happy building!
Hi, there, Firebase developers! We wanted to let you know about some important changes coming your way from Google Analytics for Firebase that will affect how we help you measure user engagement and sessions. This might also affect any BigQuery queries you might have written, so let's get right into the changes, shall we?
Up until now, sessions were measured using the following formula:
session_start
pseudo_user_id
session_started
With the latest version of the Firebase SDK, we're going to be changing how a session is measured. Specifically:
extend_session
ga_session_id
ga_session_number
In the Firebase console, the biggest change you'll notice is that your app will have more sessions, because we'll be counting instances where users interact with your app for less than ten seconds. This also means that any kind of "average some_event per session" stat will decrease, since the number of sessions is going up.
On the BigQuery side of things, these new event parameters will make your life a whole lot easier. Analyzing anything by session should be really straightforward now -- you just need to group them by ga_session_id. So calculating your own "average xxx per session" values will be a lot easier in BigQuery.
For example, here's a query where we calculate how many level_complete_quickplay events an average user generates per session:
level_complete_quickplay
SELECT AVG(total_quickplays) as average_quickplays_per_session FROM ( SELECT COUNT(event_name) as total_quickplays, (SELECT value.string_value FROM UNNEST (event_params) WHERE key = "ga_session_id") as session_id FROM `firebase-public-project.analytics_153293282.events_xxxxxxxx` WHERE event_name = "level_complete_quickplay" GROUP BY session_id HAVING session_id IS NOT NULL )
And if you want to figure out, say, how many sessions it typically takes before somebody makes a purchase, you can do that by analyzing the ga_session_number parameter.
In the past, Firebase measured total user engagement by recording the amount of time your user spent with the app in the foreground and then sending down those values (as incremental measurements) as user_engagement events. You could then calculate the total amount of time a user spent within your app by adding up the values of the engagement_time_msec parameter that were sent with each of these events.
user_engagement
engagement_time_msec
These user_engagement events were typically sent when a user a) Sent your app into the background, b) Switched screens, c) Crashed, or d) Used your app for an hour. As a result, it was very common to see user_engagement events sent alongside events like app_exception or screen_view events. To the point where we asked ourselves, "Why are we sending down all these extra events? Why not just send engagement time as a parameter with these other events we're already generating?"
app_exception
screen_view
And so that's exactly what we're going to do, starting in early 2019. You will still occasionally see separate user_engagement events, but you will also start seeing engagement_time_msec parameters added to other events automatically generated by Google Analytics for Firebase. We're going to start with screen_view, first_open and app_exception events, but you might see them added to other events in the future.
screen_view, first_open
On the Firebase console, nothing should change. Your app might end up using a little less data, since you're no longer sending down so many separate user_engagement events, but otherwise, nothing else should look different.
On the BigQuery side of things, you'll need to alter your queries slightly if you were calculating important metrics by filtering for user_engagement events. If you were, you'll need to alter those queries by looking for events that contain an engagement_time_msec parameter.
For example, here's a query that calculates the total user_engagement time for each user by summing up the engagement_time_msec parameter for user_engagement events. This might work today, but it will be inaccurate in the future.
SELECT SUM(engagement_time) AS total_user_engagement FROM ( SELECT user_pseudo_id, (SELECT value.int_value FROM UNNEST(event_params) WHERE key = "engagement_time_msec") AS engagement_time FROM `firebase-public-project.analytics_153293282.events_20181003` WHERE event_name = "user_engagement" ) GROUP BY user_pseudo_id
So here's that same query, modified to look for all events that might have a engagement_time_msec parameter
SELECT SUM(engagement_time) AS total_user_engagement FROM ( SELECT user_pseudo_id, (SELECT value.int_value FROM UNNEST(event_params) WHERE key = "engagement_time_msec") AS engagement_time FROM `firebase-public-project.analytics_153293282.events_20181003` ) WHERE engagement_time > 0 GROUP BY user_pseudo_id
The nice thing about that second query is that it works both with the old way of measuring user engagement and the new one, so you can modify your BigQuery queries today, and everything will still work just fine when the new changes go into effect.
Update: Well, it took a little longer than planned, but this feature launched in April of 2020. If you've been using this second BigQuery query all along, then congratulations! Everything should continue working as before. If not, well, there's no better time to switch over.
We hope that these changes make your life a little easier in the long run, and offer only a minimal amount of disruption in the short term. In the meantime, if you have any questions, feel free to reach out on StackOverflow, or any of our official support forums.
Happy analyzing!
