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.
