Tag Archives: Firebase

Using BigQuery and Firebase Analytics to understand your mobile app

Originally posted on Google Cloud Platform Blog

At Google I/O this May, Firebase announced a new suite of products to help developers build mobile apps. Firebase Analytics, a part of the new Firebase platform, is a tool that automatically captures data on how people are using your iOS and Android app, and lets you define your own custom app events. When the data's captured, it’s available through a dashboard in the Firebase console. One of my favorite cloud integrations with the new Firebase platform is the ability to export raw data from Firebase Analytics to Google BigQuery for custom analysis. This custom analysis is particularly useful for aggregating data from the iOS and Android versions of your app, and accessing custom parameters passed in your Firebase Analytics events. Let’s take a look at what you can do with this powerful combination.

How does the BigQuery export work?


After linking your Firebase project to BigQuery, Firebase automatically exports a new table to an associated BigQuery dataset every day. If you have both iOS and Android versions of your app, Firebase exports the data for each platform into a separate dataset. Each table contains the user activity and demographic data automatically captured by Firebase Analytics, along with any custom events you’re capturing in your app. Thus, after exporting one week’s worth of data for a cross-platform app, your BigQuery project would contain two datasets, each with seven tables:


Diving into the data


The schema for every Firebase Analytics export table is the same, and we’ve created two datasets (one for iOS and one for Android) with sample user data for you to run the example queries below. The datasets are for a sample cross-platform iOS and Android gaming app. Each dataset contains seven tables  one week’s worth of analytics data.

The following query will return some basic user demographic and device data for one day of usage on the iOS version of our app:

SELECT
user_dim.app_info.app_instance_id,
user_dim.device_info.device_category,
user_dim.device_info.user_default_language,
user_dim.device_info.platform_version,
user_dim.device_info.device_model,
user_dim.geo_info.country,
user_dim.geo_info.city,
user_dim.app_info.app_version,
user_dim.app_info.app_store,
user_dim.app_info.app_platform
FROM
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]

Since the schema for every BigQuery table exported from Firebase Analytics is the same, you can run any of the queries in this post on your own Firebase Analytics data by replacing the dataset and table names with the ones for your project.

The schema has user data and event data. All user data is automatically captured by Firebase Analytics, and the event data is populated by any custom events you add to your app. Let’s take a look at the specific records for both user and event data.

User data


The user records contain a unique app instance ID for each user (user_dim.app_info.app_instance_id in the schema), along with data on their location, device and app version. In the Firebase console, there are separate dashboards for the app’s Android and iOS analytics. With BigQuery, we can run a query to find out where our users are accessing our app around the world across both platforms. The query below makes use of BigQuery’s union feature, which lets you use a comma as a UNION ALL operator. Since a row is created in our table for each bundle of events a user triggers, we use EXACT_COUNT_DISTINCT to make sure each user is only counted once:
SELECT
user_dim.geo_info.country as country,
EXACT_COUNT_DISTINCT( user_dim.app_info.app_instance_id ) as users
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601],
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]
GROUP BY
country
ORDER BY
users DESC

User data also includes a user_properties record, which includes attributes you define to describe different segments of your user base, like language preference or geographic location. Firebase Analytics captures some user properties by default, and you can create up to 25 of your own.

A user’s language preference is one of the default user properties. To see which languages our users speak across platforms, we can run the following query:

SELECT
user_dim.user_properties.value.value.string_value as language_code,
EXACT_COUNT_DISTINCT(user_dim.app_info.app_instance_id) as users,
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601],
[firebase-analytics-sample-data:ios_dataset.app_events_20160601]
WHERE
user_dim.user_properties.key = "language"
GROUP BY
language_code
ORDER BY
users DESC

Event data


Firebase Analytics makes it easy to log custom events such as tracking item purchases or button clicks in your app. When you log an event, you pass an event name and up to 25 parameters to Firebase Analytics and it automatically tracks the number of times the event has occurred. The following query shows the number of times each event in our app has occurred on Android for a particular day:

SELECT 
event_dim.name,
COUNT(event_dim.name) as event_count
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601]
GROUP BY
event_dim.name
ORDER BY
event_count DESC

If you have another type of value associated with an event (like item prices), you can pass it through as an optional value parameter and filter by this value in BigQuery. In our sample tables, there is a spend_virtual_currency event. We can write the following query to see how much virtual currency players spend at one time:

SELECT 
event_dim.params.value.int_value as virtual_currency_amt,
COUNT(*) as num_times_spent
FROM
[firebase-analytics-sample-data:android_dataset.app_events_20160601]
WHERE
event_dim.name = "spend_virtual_currency"
AND
event_dim.params.key = "value"
GROUP BY
1
ORDER BY
num_times_spent DESC

Building complex queries


What if we want to run a query across both platforms of our app over a specific date range? Since Firebase Analytics data is split into tables for each day, we can do this using BigQuery’s TABLE_DATE_RANGE function. This query returns a count of the cities users are coming from over a one week period:

SELECT
user_dim.geo_info.city,
COUNT(user_dim.geo_info.city) as city_count
FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
GROUP BY
user_dim.geo_info.city
ORDER BY
city_count DESC

We can also write a query to compare mobile vs. tablet usage across platforms over a one week period:

SELECT
user_dim.app_info.app_platform as appPlatform,
user_dim.device_info.device_category as deviceType,
COUNT(user_dim.device_info.device_category) AS device_type_count FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
GROUP BY
1,2
ORDER BY
device_type_count DESC

Getting a bit more complex, we can write a query to generate a report of unique user events across platforms over the past two weeks. Here we use PARTITION BY and EXACT_COUNT_DISTINCT to de-dupe our event report by users, making use of user properties and the user_dim.user_id field:

SELECT 
STRFTIME_UTC_USEC(eventTime,"%Y%m%d") as date,
appPlatform,
eventName,
COUNT(*) totalEvents,
EXACT_COUNT_DISTINCT(IF(userId IS NOT NULL, userId, fullVisitorid)) as users
FROM (
SELECT
fullVisitorid,
openTimestamp,
FORMAT_UTC_USEC(openTimestamp) firstOpenedTime,
userIdSet,
MAX(userIdSet) OVER(PARTITION BY fullVisitorid) userId,
appPlatform,
eventTimestamp,
FORMAT_UTC_USEC(eventTimestamp) as eventTime,
eventName
FROM FLATTEN(
(
SELECT
user_dim.app_info.app_instance_id as fullVisitorid,
user_dim.first_open_timestamp_micros as openTimestamp,
user_dim.user_properties.value.value.string_value,
IF(user_dim.user_properties.key = 'user_id',user_dim.user_properties.value.value.string_value, null) as userIdSet,
user_dim.app_info.app_platform as appPlatform,
event_dim.timestamp_micros as eventTimestamp,
event_dim.name AS eventName,
event_dim.params.key,
event_dim.params.value.string_value
FROM
TABLE_DATE_RANGE([firebase-analytics-sample-data:android_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP()),
TABLE_DATE_RANGE([firebase-analytics-sample-data:ios_dataset.app_events_], DATE_ADD('2016-06-07', -7, 'DAY'), CURRENT_TIMESTAMP())
), user_dim.user_properties)
)
GROUP BY
date, appPlatform, eventName

If you have data in Google Analytics for the same app, it’s also possible to export your Google Analytics data to BigQuery and do a JOIN with your Firebase Analytics BigQuery tables.


Visualizing analytics data


Now that we’ve gathered new insights from our mobile app data using the raw BigQuery export, let’s visualize it using Google Data Studio. Data Studio can read directly from BigQuery tables, and we can even pass it a custom query like the ones above. Data Studio can generate many different types of charts depending on the structure of your data, including time series, bar charts, pie charts and geo maps.

For our first visualization, let’s create a bar chart to compare the device types from which users are accessing our app on each platform. We can paste the mobile vs. tablet query above directly into Data Studio to generate the following chart:
From this chart, it’s easy to see that iOS users are much more likely to access our game from a tablet. Getting a bit more complex, we can use the above event report query to create a bar chart comparing the number of events across platforms:
Check out this post for detailed instructions on connecting your BigQuery project to Data Studio.

What’s next?

If you’re new to Firebase, get started here. If you’re already building a mobile app on Firebase, check out this detailed guide on linking your Firebase project to BigQuery. For questions, take a look at the BigQuery reference docs and use the firebase-analytics and google-bigquery tags on Stack Overflow. And let me know if there are any particular topics you’d like me to cover in an upcoming post.

How to Build Your App Growth Strategy With Firebase and AdMob

Making money from your app is a great feeling and we’re glad AdMob can help! But maybe you find yourself hopping out of AdMob to perform other activities like analyzing app analytics or refining your app code. We hear you. All this back and forth can be time-consuming. Discover how Firebase can be your single Android, iOS, and mobile web development platform for a unified experience.

Save time by linking your AdMob app to a Firebase project

If you already have an AdMob account, it’s easy to link your app to a Firebase project. Learn how to do this for both Android and iOS apps. Once linked, you can take advantage of other critical app services within Firebase including real-time storage, crash reporting, and authentication without spending time searching for and accessing these services elsewhere. It’s all right there for you to use!

Monetize smarter with Firebase Analytics

You could be earning more with more engaged and active users on your app. Firebase offers powerful analytics capabilities to help you make more intelligent monetization decisions. With Firebase insights on active users, demographics, and in-app purchase revenue, smarter monetization decisions can be made to show the right segment of users the most relevant ads. Use the “Audiences” feature in Firebase to define groups of users with common attributes and analyze in-app activity. By segmenting users, you can identify where you want to position and test specific ad formats for better revenue performance.

Help grow your users with Firebase

Firebase not only helps you build and monetize your app, but it also enables you to grow your audience with in-product notifications, dynamic links that behave across all device types, app indexing so that your app makes it to top search results, and more. It’s a complete solution with services across your app’s lifecycle.

Ready to start exploring Firebase?

Sign up for a Firebase account and link your AdMob app.

Posted by Ameeti Mishra, App Partnerships Specialist, AdMob.

Source: Inside AdMob


A sizzling open source release for the Australian Election site

Originally posted on the Geo Developers Blog

One of the best parts of my job at Google is 20 percent time. While I was hired to help developers use Google’s APIs, I value the time I'm afforded to be a student myself—to learn new technologies and solve real-world problems. A few weeks prior to the recent Australian election an opportunity presented itself. A small team in Sydney set their sights on helping the 15 million voters stay informed of how to participate, track real-time results, and (of course) find the closest election sausage sizzle!


Our team of designers, engineers and product managers didn't have an immediate sense of how to attack the problem. What we did have was the power of Google’s APIs, programming languages, and Cloud hosting with Firebase and Google Cloud Platform.



The result is a mish-mash of some technologies we'd been wanting to learn more about. We're open sourcing the ausvotes.withgoogle.com repository to give developers a sense of what happens when you get a handful of engineers in a room with a clear goal and a immovable deadline.

The Election AU 2016 repository uses:

  • Go from Google App Engine instances to serve the appropriate level of detail for users' viewport queries from memory at very low latency, and
  • Dart to render the live result maps on top of Google Maps JavaScript API using Firebase real time database updates.

A product is only as good as the attention and usage is receives. Our team was really happy with the results of our work:

  • 406,000 people used our maps, including 217,000 on election day.
  • We had 139 stories in the media.
  • Our map was also embedded in major news websites, such as Sky News.

Complete setup and installation instructions are available in the GitHub README.

By Brett Morgan, Developer Programs Engineer

Use Google Mobile Ads SDK 7.11.0 to update apps for iOS 10

With the Firebase 3.6.0 launch comes the release of version 7.11.0 of the Google Mobile Ads SDK, which has been optimized for the latest release of iOS. Any app that supports iOS 10 should be built against v7.11.0 or higher of the Mobile Ads SDK. AdMob publishers can grab the latest version of the SDK using the Firebase/AdMob CocoaPod or via the Firebase manual download. DFP publishers can get the latest version from the Google-Mobile-Ads-SDK CocoaPod or via the Mobile Ads SDK manual download.

What changed?

With the rollout of iOS 10, the App Store’s privacy policy requires apps to provide a usage description when attempting to access privacy-sensitive data, such as a user’s calendaror Bluetooth. You may have seen the following errors when attempting to upload your app to iTunes Connect:

"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSCalendarsUsageDescription key with a string value explaining to the user how the app uses this data."

"This app attempts to access privacy-sensitive data without a usage description. The app's Info.plist must contain an NSBluetoothPeripheralUsageDescription key with a string value explaining to the user how the app uses this data."

The latest version of the Mobile Ads SDK has been updated for iOS 10, and will no longer cause these errors to appear.

Information for MRAID creative designers

To comply with the App Store privacy changes, we removed support for the mraid.createCalendarEvent() and mraid.storePicture() methods. You will now see that the mraid.supports("calendar") and mraid.supports("storePicture") methods always return false. Per the MRAID v2 spec, MRAID creatives should check for support of these features before using them, and correctly handle the case where they’re unavailable.

If you have any questions regarding these changes, please contact us through our forum.

Mobile Ads Garage: Episode 6 – AdMob with Firebase

Episode six of The Mobile Ads Garage is live on YouTube! If you haven't seen it before, The Mobile Ads Garage is a video tutorial series that covers how to use the Mobile Ads SDK to display ads from AdMob and Doubleclick For Publishers. Each episode covers one aspect of the SDK, breaks down the feature, and shows screencasts of real implementations on both Android and iOS – all in a friendly format.

At I/O '16, Google announced that Firebase has become a unified mobile platform that can help you quickly develop high-quality apps, grow your user base, and earn more money. Part of that platform is AdMob, and this episode features not only Andrew and Gary, but also the Garage's first ever guest star: David East from the Firecasts series! David and Andrew will cover what the benefits of Firebase are for AdMob publishers, how to import both SDKs into a project, and how to link an AdMob app to a Firebase project so you can take advantage of Firebase's free and unlimited analytics.



If you like the video, save the Mobile Ads Garage playlist to your YouTube Playlist collection and you'll never miss an episode.

We’d love to hear which AdMob features you’d like to learn more about. The comment sections for the videos are open, and you're welcome to toss out ideas for new episodes and examples you'd like to see. If you have a technical question relating to something discussed in one of the episodes, you can bring it to our support forum. Remember to stay connected on all things AdMob by following our TwitterLinkedIn and Google+ pages

Source: Inside AdMob


Introducing Firebase Authentication

Originally posted on Firebase blog

For most developers, building an authentication system for your app can feel a lot like paying taxes. They are both relatively hard to understand tasks that you have no choice but doing, and could have big consequences if you get them wrong. No one ever started a company to pay taxes and no one ever built an app just so they could create a great login system. They just seem to be inescapable costs.

But now, you can at least free yourself from the auth tax. With Firebase Authentication, you can outsource your entire authentication system to Firebase so that you can concentrate on building great features for your app. Firebase Authentication makes it easier to get your users signed-in without having to understand the complexities behind implementing your own authentication system. It offers a straightforward getting started experience, optional UX components designed to minimize user friction, and is built on open standards and backed by Google infrastructure.

Implementing Firebase Authentication is relatively fast and easy. From the Firebase console, just choose from the popular login methods that you want to offer (like Facebook, Google, Twitter and email/password) and then add the Firebase SDK to your app. Your app will then be able to connect securely with the real time database, Firebase storage or to your own custom back end. If you have an auth system already, you can use Firebase Authentication as a bridge to other Firebase features.

Firebase Authentication also includes an open source UI library that streamlines building the many auth flows required to give your users a good experience. Password resets, account linking, and login hints that reduce the cognitive load around multiple login choices - they are all pre-built with Firebase Authentication UI. These flows are based on years of UX research optimizing the sign-in and sign-up journeys on Google, Youtube and Android. It includes Smart Lock for Passwords on Android, which has led to significant improvements in sign-in conversion for many apps. And because Firebase UI is open source, the interface is fully customizable so it feels like a completely natural part of your app. If you prefer, you are also free to create your own UI from scratch using our client APIs.

And Firebase Authentication is built around openness and security. It leverages OAuth 2.0 and OpenID Connect, industry standards designed for security, interoperability, and portability. Members of the Firebase Authentication team helped design these protocols and used their expertise to weave in latest security practices like ID tokens, revocable sessions, and native app anti-spoofing measures to make your app easier to use and avoid many common security problems. And code is independently reviewed by the Google Security team and the service is protected in Google’s infrastructure.

Fabulous use Firebase Auth to quickly implement sign-in

Fabulous uses Firebase Authentication to power their login system. Fabulous is a research-based app incubated in Duke University’s Center for Advanced Hindsight. Its goal is to help users to embark on a journey to reset poor habits, replacing them with healthy rituals, with the ultimate goal of improving health and well-being.

The developers of Fabulous wanted to implement an onboarding flow that was easy to use, required minimal updates, and reduced friction with the end user. They wanted an anonymous option so that users could experiment with it before signing up. They also wanted to support multiple login types, and have an option where the user sign-in flow was consistent with the look and feel of the app.

“I was able to implement auth in a single afternoon. I remember that I spent weeks before creating my own solution that I had to update each time the providers changed their API”
- Amine Laadhari, Fabulous CTO.

Malang Studio cut time-to market by months using Firebase Auth

Chu-Day is an application (available on Android and iOS) that helps couples to never forget the dates that matter most to them. It was created by the Korean firm Malang Studio, that develops character-centric, gamified lifestyle applications.

Generally, countdown and anniversary apps do not require users to sign-in, but Malang Studio wanted to make Chu-day special, and differentiate it from others by offering the ability to connect couples so they could jointly countdown to a special anniversary date. This required a sign-in feature, and in order to prevent users from dropping out, Chu-day needed to make the sign-in process seamless.

Malang Studio was able to integrate an onboarding flow in for their apps, using Facebook and Google Sign-in, in one day, without having to worry about server deployment or databases. In addition, Malang Studio has also been taking advantage of the Firebase User Management Console, which helped them develop and test their sign-in implementation as well as manage their users:

“Firebase Authentication required minimum configuration so implementing social account signup was easy and fast. User management feature provided in the console was excellent and we could easily implement our user auth system.”
- Marc Yeongho Kim, CEO / Founder from Malang Studio

For more about Firebase Authentication, visit the developers site and watch our I/O 2016 session, “Best practices for a great sign-in experience.”

Behind the scenes: Firebass ARG Challenge

Originally posted on Firebase blog

Posted by Karin Levi, Firebase Marketing Manager

This year's Google I/O was an exciting time for Firebase. In addition to sharing the many innovations in our platform, we also hatched a time-traveling digital fish named Firebass.

Firebass is an Alternate Reality Game (ARG) that lives across a variety of static web pages. If you haven’t played it yet, you might want to stop reading now and go fishing. After you’ve caught the Firebass and passed the challenge, come back -- we’re going to talk about how we built Firebass.

How we began

We partnered with Instrument, a Portland-based digital creative agency, to help us to create an ARG. We chose ARG because this allowed us to utilize developers’ own software tools and ingenuity for game functionality.

Our primary objective behind Firebass was to make you laugh, while teaching you a little bit about the new version of Firebase. The payoff for us? We had a blast building it. The payoff for you? A chance to win a free ticket to I/O 2017.

To begin, we needed to establish a central character and theme. Through brainstorming and a bit of serendipity, Firebass was born. Firebass is the main character who has an instinctive desire to time-travel back through prior eras of the web. Through developing the story, we had the chance to revisit the old designs and technologies from the past that we all find memorable -- as you can imagine, this was really fun.

Getting started

We put together a functional prototype of the first puzzle to test with our own developers here at Google. This helped us gauge both the enjoyment level of the puzzle and their difficulty. Puzzle clues were created by thinking of various ways to obfuscate information that developers would be able to recognize and manipulate. Ideas included encoding information in binary, base64, hex, inside images, and other assets such as audio files.

The core goal with each of the puzzles was to make them both logical but not too difficult -- we wanted to make sure players stayed engaged. A bulk of the game’s content was stored in Firebase, which allowed us to prevent players from accessing certain game details too early via inspecting the source code. As an added bonus, this also allowed us to demonstrate a use-case for Firebase remote data storage.

Driving the game forward

One of our first challenges was to find a way to communicate a story through static web pages. Our solution was to create a fake command line interface that acted as an outlet for Firebass to interact with players.

In order to ground our time travel story further, we kept the location of Firebass consistent at https://probassfinders.foo/ but changed the design with each puzzle era.

Continuing the journey

After establishing the Pro Bass Finders site and fake terminal as the centerpieces of the game, we focused on flushing out the rest of the puzzle mechanics. Each puzzle began with the era-specific design of the Pro Bass Finders home page. We then concepted new puzzle pieces and designed additional pages to support them. An example of this was creating a fake email archive to hide additional clues.

Another clue was the QR code pieces in puzzle 2.

The QR codes demonstrate Firebase time-based read permissions and provide a way to keep players revisiting the site prior to reaching the end of puzzle 2. There were a total of three pieces of a QR code that each displayed at different times during the day. It was really fun and impressive to see all of the different ways players were able to come up with the correct answer. The full image translates to ‘Locating’, making the answer the letter ‘L’, but many players managed to solve this without needing to read the QR code. You're all smart cookies.

Final part of the Puzzle

Puzzle 3 encompassed our deep nostalgia for the early web, and we did our best to authentically represent the anti-design look and feel of the 90s.

In one of the clues, we demonstrated Firebase Storage by storing an audio file remotely. Solving this required players to reference Firebase documentation to finish writing the code to retrieve the file.


<!-- connect to Firebase Storage below -->
<script>
console.log('TODO: Complete connection to Firebase Storage');
var storageRef = firebase.app().storage().ref();
var file = storageRef.child('spectrogram.wav');

// TODO: Get download URL for file (https://developers.google.com/firebase/docs/storage/web/download-files)
</script>

The finale

While the contest was still active, players who completed the game were given a URL to submit their information for a chance to win a ticket to Google I/O 2017. After the contest was closed, we simply changed the final success message to provide a URL directly to the Firebass Gift Shop, a treasure in and of itself. :)

Until next time

This was an unforgettable experience with a fervently positive reaction. When puzzle 3 unlocked, server traffic increased 30x! The community response in sharing photos, Slack channels, music, jokes, posts, etc. was incredible. And all because of one fish. We can’t wait to see all the swimmer winners next year at I/O 2017. Until then, try playing the game yourself at firebase.foo. Thank you, Firebass. Long may you swim.

><(((°<

Introducing Firebase Remote Config

Turning a great app into a successful business requires more than simply releasing your app and calling it a day. You need to quickly adapt to your user’s feedback, test out new features and deliver content that your users care about most.

This is what Firebase Remote Config is made for. By allowing you to change the look and feel of your app from the cloud, Firebase Remote Config enables you to stay responsive to your user’s needs. Firebase Remote Config also enables you to deliver different content to different users, so you can run experiments, gradually roll out features, and even deliver customized content based on how your users interact within your app.

Let's look at what you can accomplish when your wire up your app to work with Remote Config.

Update your app without updating your app

We've all had the experience of shipping an app and discovering soon afterwards that it was less than perfect. Maybe you had incorrect or confusing text that your users don't like. Maybe you made a level in your game too difficult, and players aren't able to progress past it. Or maybe it was something as simple as adding an animation that takes too long to complete.

Traditionally, you'd need to fix these kinds of mistakes by updating those values in your app's code, building and publishing a new version of your app, and then waiting for all your users to download the new version.

But if you've wired up your app for Remote Config in the Firebase platform, you can quickly and easily change those values directly in the cloud. Remote Config can download those new values the next time your user starts your app and address your users' needs, all without having to publish a new version of your app.

Deliver the Right Content to the Right People

Firebase Remote Config allows you to deliver different configurations to targeted groups of users by making use of conditions, which use targeting rules to deliver specific values for different users. For example, you can send down custom Remote Config data to your users in different countries. Or, you can send down different data sets separately to iOS and Android devices.

You can can also deliver different values based on audiences you've defined in Firebase Analytics for some more sophisticated targeting. So if you want to change the look of your in-app store just for players who have visited your store in the past, but haven't purchased anything yet, that's something you can do by creating Remote Config values just for that audience.

Run A/B Tests and Gradual Rollouts

Remote Config conditions also allow you to deliver different values to random sets of users. You can take advantage of this feature to run A/B tests or to gradually rollout new features.

If you are launching a new feature in your app but aren't sure if your audience is going to love it, you can hide it behind a flag in your code. Then, you can change the value of that flag using Remote Config to turn the feature on or off. By defining a "My New Feature Experiment" condition that is active for, say, 10% of the population, you can turn on this new feature for a small subset of your users, and make sure it's a great experience before you turn it on for the rest of your population.

Similarly, you can run A/B tests by supplying different values to different population groups. Want to see if people are more likely to complete a purchase if your in-app purchase button says, "Buy now" or "Checkout"? That's the kind of experiment you can easily run using A/B tests.

If you want to track the results of these A/B tests, you can do that today by setting a user property in Firebase Analytics based on your experiment. Then, you can filter any of your Firebase Analytics reports (like whether or not the user started the purchase process) by this property. Watch this space for news on upcoming improvements to A/B testing.

A Fabulous Improvement in Retention

Many of our early partners have already been using Firebase Remote config to test out changes within their app.

Fabulous, an app from Duke University's designed to help people adopt better lifestyle habits, wanted to experiment with their getting started flow to see which methods were most effective for getting their users up and running in their app. They not only A/B tested changes like images, text, and button labels, but they also A/B tested the entire onboarding process by using Remote Config to determine what dialogs people saw and in what order.

Thanks to their experiments with Remote Config, Fabulous was able to increase the number of people who completed their onboarding flow from 42% to 64%, and their one-day retention rate by 27%.

Research has shown that an average app loses the majority of their users in the first 3 days, so making these kinds of improvements to your app's onboarding process -- and confirming their effectiveness by conducting A/B tests -- can be crucial to ensuring the long-term success of your app.

Is Your App Wired Up?

When you use remote config Remote Config, you can supply all of your default values locally on the device, then only send down new values from the cloud where they differ from your defaults. This gives you the flexibility to wire up every value in your app to be potentially configurable through Remote Config, while keeping your network calls lightweight because you're only sending down changes. So feel free to take all your hard-coded strings, constants, and that AppConstants file you've got sitting around (it's okay, we all have one), and wire 'em up for Remote Config!

Firebase Remote Config is part of the Firebase platform and is available for free on both iOS and Android. If you want to find out more, please see our documentation and be sure to explore all the features of the Firebase SDK.

AdMob and Firebase have teamed up

During the keynote at I/O 2016, we announced that Firebase has become a complete mobile platform that helps developers build high-quality apps, grow their user base, and earn more money. AdMob is part of how Firebase helps publishers earn revenue, and now that the dust has settled on I/O, you might have some questions about what the change means and how it affects people already monetizing with AdMob ads.

How does this affect my existing apps?

The short answer is: however you want it to. The apps you've already built are just fine the way they are, and they can keep monetizing with AdMob exactly as they do now, without changes. We've also made sure that when you do make the decision to integrate Firebase, the process is simple and straightforward. You can link your AdMob apps to Firebase projects right from the AdMob console. Firebase Analytics comes out of the box with the Firebase SDK, and you're free to choose the particular combination of Firebase services that fits your app.

Do I have to use Firebase with my new apps?

Nope. If you prefer to use AdMob by itself, that's just fine. You can import the Google Mobile Ads SDK the same way you do now, and continue to create ad units, campaigns, and reports at apps.admob.com.

My app is small! How big is the Firebase SDK?

We know SDK size is a big deal for mobile developers, and Firebase has been designed from the start to minimize its footprint. Publishers can pick and choose which services they're interested in, and only need the gradle libraries and frameworks they actually use. In our testing on Android, for example, importing the Mobile Ads SDK using the firebase-ads:9.0.0 gradle library instead of play-service-ads:9.0.0 increased the post-ProGuard size of our banner example's APK by about 100kB (though your results may vary).

Which Firebase service should I start with first?

All of the services are built to help mobile developers through the “develop, grow, and earn" lifecycle, so it depends which stage you’re at. Analytics, though, is something that every app can benefit from. Just by registering a Firebase project and importing the Firebase SDK into your app, you can start monetizing more intelligently with Firebase's free and unlimited analytics solution. Things like sessions, user demographics, revenue from in-app products, and a lot more will appear in the Firebase Analytics dashboard, with no extra code required.

Publishers can also add their own Analytics events and track them to improve their monetization strategy. For example, by adding events to monitor how users navigate between screens within an app, publishers can better understand the flow of action and find the best places to show interstitials without disrupting their users.

Are AdMob's developer resources going away?

No. The developer site has moved to a new domain, and we've added new content where appropriate, but everything you're used to is still there.

Our samples for iOS and Android now include the Firebase SDK when they build. We've also changed our quick-start guides for iOS and Android to help publishers get on board with Firebase, and the guys behind the Mobile Ads Garage are cooking up a new episode right now.

For more direct support, Firebase has a bunch of options, and as always, If you have technical questions about the Mobile Ads SDK, you're welcome to stop by our support forum.

Google Cloud Messaging and Firebase

Posted by Laurence Moroney, Developer Advocate

With the announced expansion of Firebase at Google I/O recently, we also introduced Firebase Cloud Messaging (FCM) and Firebase Notifications (FN). As a developer, there are lots of updates that you might be able to take advantage of.

Despite the switch to FCM, we’ll continue to support Google Cloud Messaging on Android, iOS and the Web because we know that you have applications using the previous SDKs to handle notifications. However, all new client side features will be added to FCM SDKs moving forward. As such, we strongly recommend that you upgrade to the FCM SDKs. You can learn more about them here.

FCM supports everything that you’ve come to know with Google Cloud Messaging including addressing single devices, groups of devices or topics.

The FCM SDK simplifies client development. For example, you no longer need to write your own registration or subscription retry logic. When it comes to your server (if you still want to use one), updates to the endpoints and protocol don’t incur breaking changes, so as to maintain backwards compatibility. The updated details are available in the FCM Server documentation.

We’re investing heavily in making Firebase our unified mobile platform. We’re also continuing to expand our messaging platform beyond Android, including iOS and the Web. Firebase is well known for it’s cross-platform capabilities, so FCM is a natural fit for the ongoing Firebase releases. If you want to learn how to migrate your current app from Google Cloud Messaging to FCM, we’ve provided guides here for Android and iOS.

We think that Google Cloud Messaging will be even more useful to you when integrated into Firebase, including the new Firebase Notifications console. With that you’ll be able to send messages to apps directly from the console -- without you needing to build a messaging server.

To upgrade from Google Cloud Messaging to FCM or to learn more, see our guides for Android and iOS apps.