We’re happy to see many developers experimenting with Firebase! Some of you have been transitioning your experiments to production, and that’s raised some questions about how to manage the builds of your Android projects. The most common question goes something like this: "How do I keep my everyday development data separate from my release data?"
We'd all like our analytics to reflect only the actual usage of the app (as opposed to artificial usage during development). Also, it's not useful to see crashes from moment-to-moment development interleaved with those from our publicly released versions. On top of that, as your team grows and your app becomes more complex, you may want to separate each team member’s working space into separate sandboxes so that their work won’t collide with each other.
So, let’s explore some ways to configure your project to best handle these cases. For Android app builds, the preferred path is to take advantage of some configuration features of the Android Gradle plugin. These can be applied alongside some configurations in the Firebase Console.
But before I discuss these configurations, let's get some terminology settled! Here are some terms we'll use:
Firebase project
Firebase app
Android Gradle build type
Android Gradle build flavor
Android Gradle build variant
Android Application ID
The key concept, for effective configuration of an app with Firebase, is to assign a distinct application ID to each build variant of an app that requires its own collection of data. This is something you do in your app's build.gradle first, then mirror in the Firebase Console. But first, to make a decision about configuration that's best for your app, there are some more things you need to know about how the different Firebase features work between your Firebase projects and apps.
Some Firebase features share their data between all the apps (Android, iOS, and web) within the same project. You could say that the data for these features are "scoped" to an entire Firebase project:
Some Firebase features have independent data for all the apps within the same project. You could say that these features are scoped to the individual apps in your Firebase project:
You'll notice that the dashboards for both Analytics and Crash Reporting have an app selector near the top of their dashboards that let you select the individual app (of all those created in the project) whose data you want to view.
Some Firebase features have a hybrid scope, where any number of apps may be affected by a particular operation:
Firebase Test Lab for Android has its own special case because it requires a project with billing enabled, but it can be used with any APK without any constraint in a single project. So, if you want to develop with Firebase on a free plan, but test the APK using Test Lab on a paid plan, it's recommended to create a whole new project and enable billing just for use of Test Lab. You can test any app in this project, with or without Firebase integrated.
Now, this is a all good to knowledge to have, but why don't we make this more practical with some actual examples? I'll share some recipes for configuration next. The best case for your situation might be one of these exactly, or some hybrid.
Let's say you're an individual developer or on a small team, your app is relatively simple, and you just need to separate your analytics and crash reports between your daily debug and published release builds. In this case, it would suffice to configure your app to have a different application ID for debug and release. Here's a bit of a Gradle configuration that might help:
defaultConfig { applicationId "com.company.project" // etc... } buildTypes { debug { applicationIdSuffix ".debug" } release { // etc... } }
Here, the application ID is "com.company.project", which gets applied to the release build. But the application ID for the debug build becomes "com.company.project.debug". You don't have to use a suffix like this - instead you could specify a whole new value with applicationId.
Then, in the Firebase Console, you would create a single project, and within that project, create two apps, one for each build type. The debug app would use the application ID "com.company.project.debug", and the release app would use "com.company.project". The SHA-1 hashes would also have to reflect the different keys used to sign each build, if you're using Firebase features that require it.
After both apps are created, download a google-services.json file from the console and place it into your app. If you look inside that file, you'll notice that both apps will appear in there. The Google Services plugin will figure out which set of configurations to use during the build of each variant.
"client_info": { "mobilesdk_app_id": "...", "android_client_info": { "package_name": "com.company.project.debug" } }, "client_info": { "mobilesdk_app_id": "...", "android_client_info": { "package_name": "com.company.project" }
google-services.json will contain info for all Android apps in a project.
It's important to know that if this project is on a billing plan, you'll be billed for all bandwidth and storage generated by both apps. So if you're pulling lots of data during development, that may result in additional charges. Be sure to understand the [pricing plans] to plan for this so you're not surprised by the bill.
It's also important to note that, with this configuration, you will be working against all the same data during development as your active users on your fully released app. This may not be the safest thing, if you intend to disrupt your Realtime Database data or experiment with Remote Config values during development!
The prior recipe of doing development against your live data may be problematic. If you have a large team with lots of people making unsafe updates to the data, or you generally want to prevent the risk of corrupting production data, you'll need to set up multiple projects to isolate development data from production data. In fact, you could have everyone on the team use their own individual "sandbox" projects on the free tier so they can experiment safely without affecting others or incurring any billing.
To set this up, you don't really need to do anything special in your build.gradle. Everyone can use the same application ID to create an app in their sandbox project. However, they'll each need their own unique debug key to sign with. The Android SDK tools create a unique debug key for each user of the SDK, so normally that shouldn't be a problem. But it should be known that the Firebase Console will not allow an app to be created that has a duplicate pair of application ID and SHA-1 key as any other app in any project in any account. So if your team members were sharing a debug key, that won't work with this setup.
This arrangement is great to keep everyone isolated, but there's one caveat. Since all the developers will be creating their own project, they may also have to duplicate some configurations to make the project work correctly. For example, the database for a new project may need to be bootstrapped with some useful data. And the correct security rules should be duplicated. Remote Configs may need to created with appropriate values. Authentication may need to be configured as well. And, of course, every developer will need to use the google-services.json file generated for their own project, and should not be checked into source control, in order to avoid conflicts between team members.
If you have a situation where you need data isolation between different environments, the best way to set that up is similar to the large team setup above. You'll definitely need to create different projects for each environment. They can all be owned by the same account or by different accounts.
To make it easy to select the environment to build for, you can take advantage of build flavors to configure each version of the app. For example, if you need isolation for development, QA, and production, you could define three build flavors in the productFlavors block, which goes next to the buildTypes block in the app’s build.gradle:
productFlavors { dev { } qa { } prod { } }
Here, we're not indicating that there's anything different between the variants except that they exist separately. They'll all have the same application ID, which is OK. Or you could assign them distinct IDs if that helps your situation. In either case, you'll need to use a flavor-specific directory to contain the google-services.json file from each project. By default, the Android Gradle plugin recognizes the following convention for organizing the directories for each flavor as defined above:
app/ src/ main/ dev/ google-services.json (for dev only) qa/ google-services.json (for qa only) prod/ google-services.json (for prod only)
Notice that each named flavor becomes the name of a directory that sits in src adjacent to the main directory where your project code typically lives. With this structure, you can drop the google-services.json for each project directly into its dedicated directory. Now, if you want to build the “dev” flavor of the app, you can select "devDebug" from the build variants window in Android Studio, or target the variant's build task "assembleDevDebug" on the Gradle command line.
If you have an unusual situation with your app build that isn't really helped by the information here, please don't hesitate to ask a question at the firebase-talk Google Group. And, for more urgent support matters, please file an issue on the Firebase Support site. And please follow me on Twitter as CodingDoug!
Generating insights from data and acting upon it appropriately can often make or break a company. In the past few years, the field has grown leaps and bounds with a lot more app developers tracking a lot more events. Yet, truth be told, it’s easy to get overloaded with data and, hence, make it tougher for yourself to find what you were looking for.
So, what metrics should you be tracking to help improve your product?
Analytics is a vast field, with several popular practices and frameworks being employed across the world in every industry. One of the most popular frameworks, particularly in the tech products sector, is Pirate Metrics. The term was coined by Dave McClure, founder of 500 Startups, and is very popular amongst product managers and growth hackers across the world for how it simplifies and breaks down a product’s user lifecycle.
In this post, we’ll cover the five metrics that are collectively called Pirate Metrics and understand their importance. In following posts in the series, we will see how we can use Firebase products to boost these metrics and, hence, build more engaging products.
: The first element in user lifecycle of any product is the acquisition, meaning user install your app. Users are acquired in many different ways, either organically, such as through social media communications, App Store optimization, search, news, content marketing etc., or inorganically which is usually ads.
Congratulations, you have acquired a user! However, your job is less than half done and there is still a need to convince the user that the app is worth keeping around. To give yourself the best chance, you want to activate the user by getting them to experience what makes your app special. For example, a game might want the user to go through a training level or a photo filter application might want the user to experiment with any one image.
The biggest challenge most products face is to retain the users that they acquired. A typical person only uses about 26% of their installed apps daily. People tend to either uninstall or simply forget about the applications they downloaded after the first few days. The goal for any new healthy product is to find a strategy to retain them, and have them keep coming back.
You also want your users to be your biggest advocates. No acquisition strategy is as powerful as an organic, referral campaign. If users love your product, they genuinely want their friends to try it out as well, and you want to really encourage your users to do so, and reduce any friction that might stop a user.
Ultimately, you want to monetize your app in order to grow your company and reach more users.
These five stages - Acquisition, Activation, Retention, Referral, and Revenue are collectively called Pirate Metrics. These are fairly general and can be applied to most digital products. Product managers use a wide variety of tools to track these different metrics. However, with the new Firebase, not only can you track these in one single place, you can also use the suite of different tools to boost them.
We’ll see how in the coming posts. Stay tuned!
One of Firebase Analytics' most powerful features is the ability for you to view and analyze your Analytics data directly in BigQuery. By linking your Firebase apps with BigQuery, all of your raw, unsampled, app data is exported into BigQuery on a daily basis. This gives you the ability to run powerful ad-hoc queries on your data, combine your Firebase Analytics data with that from other analytics libraries, or run your own custom reporting tools directly on top of your data.
And while this feature is quite popular with developers, it comes with one occasionally-frustrating limitation: You typically have to wait about 24 hours for your daily analytics data to be collected and exported into a BigQuery table. This was often inconvenient from a development-and-testing standpoint. But it also meant that app developers were a little less nimble than they could have been. After all, if your latest A/B test was causing people to abandon your app, wouldn't it be nice to find that out in 20 minutes, rather than 24 hours?
So starting this week, we're happy to announce that you will now be able to see your Firebase Analytics data in BigQuery in near real-time!
Here's how it works: If you've gone ahead and linked up BigQuery with your Firebase project, then Firebase Analytics will, by default, send all of its data to BigQuery as soon as it receives it. In addition to your usual appevents_ tables, there's now a special appevents_intraday_ table that will collect all of your incoming data for that day.
appevents_
appevents_intraday_
You're welcome to analyze and run queries against this intraday table to your heart's content. It looks just like your other BigQuery analytics tables; the only data you won't find there is lifetime value data and campaign information (the traffic_source record). At the end of the day [1], this data will be moved into its permanent appevents_ home, and the old intraday table will be automatically cleaned up for you.
intraday
traffic_source
Of course, BigQuery usage and storage charges still apply. Which does mean that you'll need to upgrade your Firebase project to the Blaze plan in order to receive these benefits. But considering that BigQuery exporting is a feature analytics customers typically had to pay quite a bit of money for in the past, I still think it's a pretty good deal.
If you're new to BigQuery, you can find out more here and start playing around with it. It's fun! Or, as fun as running fast queries against large sets of data gets, I suppose.
[1] This is determined by looking at the developer's time zone.
We know that it's important for you to make sure your apps can run on the latest and greatest technology out there. And in the world of iOS development, there's this little release on the horizon called iOS 10 that many of you are excited about supporting with your apps.
Well, we here on the Firebase team also want to make sure your apps are up and running on iOS 10 as soon as it's made available to the general public. So we're going to go over some of the changes that we've included in the latest version (3.5.1) of the Firebase Cocoapod, and let you know about upcoming changes that will affect you as we move into the exciting new world of iOS 10 development.
Dynamic Links, Invites, App Indexing
With the latest version of the Firebase library, we've added support for handling deep links on iOS 10. If your app uses a feature that relies on deep links -- specifically, Dynamic Links, Firebase Invites, and App Indexing -- go ahead and update to the latest version of the library. Rebuild your app (no code changes needed!), and these features should all work properly.
Firebase Analytics
The latest version of the Firebase SDK includes some changes to more accurately track app installs resulting from AdWords search and display ads. If this sounds familiar, it’s because this feature was also included in version 3.3.0 of Firebase, but now we've added support for this on iOS 10 as well. Like the new deep link support, this should work automatically if you rebuild your code with the new library.
Firebase Cloud Messaging
iOS 10 made a lot of exciting changes around notifications, along with new ways for you as a developer to handle incoming user notifications. Specifically, notifications are now handled by methods belonging to the UNUserNotificationCenterDelegate protocol, while the old UIApplicationDelegate methods like application:didReceiveRemoteNotification are now deprecated.
UNUserNotificationCenterDelegate
UIApplicationDelegate
application:didReceiveRemoteNotification
That said, you might notice that the most recent release of the Firebase SDK is still calling the older appDelegate methods. We hope to have support for these new UNUserNotificationCenterDelegate protocol methods soon, so do keep an eye out for any future announcements as we update our libraries.
A Quick Note About Firebase Auth and Xcode 8
We've noticed what seems to be an issue with the latest iOS 10 simulators (up to beta 6 at the time of this writing) that causes Firebase Auth to throw an error due it to not being able to write values to the keychain. This issue does not affect real devices.
We have filed a radar with Apple and are hoping to get this issue resolved shortly, but you may encounter errors when testing Firebase Auth in the simulator. As a workaround, we recommend testing Auth on a physical device running iOS 10. If you do not have access to a real device, you also can try enabling Keychain Sharing in the Capabilities section of your app, as described in this StackOverflow post.
What about Swift 3?
You might have noticed that the code samples in our documentation still reflect Swift 2.3. With all the changes that are still happening in Swift 3, we've decided to wait until version 3.0 has been officially released before switching over the code samples in our documentation.
Of course, if you're interested in trying out our samples in Swift 3, you can always download our latest sample code and let Xcode's Swift conversion tool convert the samples for you. It does a remarkably good job. And, in the next few days, we'll be creating a specific Swift 3 branch of our sample apps, so you can check out those branches from GitHub and see the source code without having to go through the conversion process.
Send us Feedback!
Obviously, releasing a library to support an operating system that's still in beta is a tricky proposition. Issues may still arise here and there as new versions of iOS 10 are made available, and if they do, we'll try to address them as quickly as we can. So if you encounter an error that seems to be specific to iOS 10, please let us know! Our Google Group is a good place to start.
sendNotificationToUser("puf", "Hi there puf!");
public static void sendNotificationToUser(String user, final String message) { Firebase ref = new Firebase(FIREBASE_URL); final Firebase notifications = ref.child("notificationRequests"); Map notification = new HashMap<>(); notification.put("username", user); notification.put("message", message); notifications.push().setValue(notification); }
notificationRequests $pushid message: "Hello there" username: "puf"
var firebase = require('firebase-admin'); var request = require('request'); var API_KEY = "..."; // Your Firebase Cloud Messaging Server API key // Fetch the service account key JSON file contents var serviceAccount = require("path/to/serviceAccountKey.json"); // Initialize the app with a service account, granting admin privileges firebase.initializeApp({ credential: firebase.credential.cert(serviceAccount), databaseURL: "https://<your database>.firebaseio.com/" }); ref = firebase.database().ref(); function listenForNotificationRequests() { var requests = ref.child('notificationRequests'); requests.on('child_added', function(requestSnapshot) { var request = requestSnapshot.val(); sendNotificationToUser( request.username, request.message, function() { requestSnapshot.ref.remove(); } ); }, function(error) { console.error(error); }); }; function sendNotificationToUser(username, message, onSuccess) { request({ url: 'https://fcm.googleapis.com/fcm/send', method: 'POST', headers: { 'Content-Type' :' application/json', 'Authorization': 'key='+API_KEY }, body: JSON.stringify({ notification: { title: message }, to : '/topics/user_'+username }) }, function(error, response, body) { if (error) { console.error(error); } else if (response.statusCode >= 400) { console.error('HTTP Error: '+response.statusCode+' - '+response.statusMessage); } else { onSuccess(); } }); } // start listening listenForNotificationRequests();
String username = "puf"; FirebaseMessaging.getInstance().subscribeToTopic("user_"+username);
The transformation of Firebase into a unified mobile platform brought with it new Gradle artifacts and CocoaPods that mobile developers can use to import the Mobile Ads SDK. With these additions, there are now several alternatives for each platform. Thanks to your feedback, we wanted to share a little more information about which ones we recommend and what libraries they include, so here's a quick run-down.
This is the best way to get the Mobile Ads SDK into your project. With the firebase-ads artifact, you get everything you need to load and display ads from AdMob, DFP, or AdX, plus Firebase Analytics built in. You'll also be ready to add the client components for any other Firebase services you want to use, like firebase-crash or firebase-config. Unless you have a specific need to use the SDK without Firebase, this is your jam.
firebase-ads
firebase-crash
firebase-config
If you'd like to see a screencast of how to get up and running with AdMob using firebase-ads, check out this episode of the Firecasts series:
For those not using Firebase, this Gradle artifact contains the Mobile Ads SDK on its own. You'll get the client code for AdMob, DFP, and AdX, but no Firebase services.
This is the full Google Play services client, also without Firebase. This gives you not only the Mobile Ads SDK, but all the other Google Play services SDKs as well: Maps, Drive, Fit, and so on. Since you're probably not using every API that Play services offers, it's better to import them individually. If you need mobile ads and Play games, for example, just include play-services-ads and play-services-games.
play-services-ads
play-services-games
The SDK team developed this new Gradle artifact for a very specific use-case. It contains a slimmed-down version of the Mobile Ads SDK designed to work only on devices that have Google Play services installed. If reducing app size is extremely important for you, this can help lessen the impact of the Mobile Ads SDK, but it won't be able to load and display ads on devices that don't have Play services. Make sure you're intimately familiar with your app's install base before considering this tradeoff, and see the Lite SDK guide for more details.
This is the Firebase CocoaPod for AdMob and the Mobile Ads SDK. While it's labelled as "AdMob," this pod gives you the iOS client code for DFP and AdX as well. You'll get everything you need to load and display ads from all three sources, plus Firebase Analytics built in. This CocoaPod is also easy to combine with any other Firebase pods your app needs, like Firebase/Crash and Firebase/Database. For most developers, this is the one you want.
Firebase/Crash
Firebase/Database
The Firecasts series has an episode that shows how to import AdMob and Firebase into an app using Firebase/AdMob, so check that out for a detailed screencast:
Firebase/AdMob
For developers not yet using Firebase, this pod contains just Mobile Ads SDK. You get everything necessary to show ads from AdMob, DFP, and AdX, but no Firebase services.
This is an older, alternate CocoaPod for the Mobile Ads SDK that should no longer be used. Google-Mobile-Ads-SDK is the better choice if you aren't using Firebase.
Google-Mobile-Ads-SDK
If you've got questions about Firebase and the best ways to get started, the Firebase support page also has a bunch of options that can help. If you've got technical questions about the Mobile Ads SDK itself, you're welcome to stop by the SDK support forum.
