Pop quiz, hot-shot! Let's say you've spent some money on two different ad campaigns to bring users into your app. After a few weeks, you discover:

• Ad campaign #1 resulted in 500 clicks.
• Ad campaign #2 resulted in 300 clicks.

So, which ad campaign performed better? Seems like a no-brainer, right? Should you double-down on ad campaign #1?

Well, hang on. What if you were to then discover...

• Ad campaign #1 resulted in 500 clicks
  • But only 80 users installed and opened your app
  • ...and they spent an average of $1.20 each
• Ad campaign #2 resulted in 300 clicks...
• But 230 of those users installed and opened your app
• ...and they spent an average of $6 each
• ...and over 100 of them signed up for your newsletter?

Well, suddenly, that second ad campaign seems like a much better deal, doesn't it?

That's the idea behind attribution. It's a powerful form of app analytics that not only determines which campaigns are bringing you users, but also which campaigns are bringing you valuable users that you care most about.

While attribution is a complex topic that can be studied for many months by people with marketing degrees, let's give you a brief overview of how it works and what it can mean for your business.

Typically, when an app requests any kind of banner ad or video ad, the network that delivers this ad makes a note of the user's ID For Advertisers (on iOS devices), also known as the IDFA, or your Advertising ID (on Android devices). These are unique device IDs that serve as a way for an in-app advertiser to remember information about the individual user, while doing so in a way that respects the user's privacy. They're not tied to any personally identifiable information, and users have the ability to hide or reset these identifiers if they'd like.

If a user clicks on that advertisement, the network that was serving the ad makes a note on its servers that the user (as identified by this IDFA / Advertising ID) has clicked on it.

Then it sends your user to the appropriate app store so that they can check out your app. Assuming all goes well from here, this user will then install your app from the App Store or Play Store, and open it. Hooray!

Now, let's say you want to use Firebase Analytics to help track how successful this particular ad campaign is in bringing you valuable users. The way this would work is, on the Firebase Analytics "Attribution" panel, you select what ad networks you're working with -- right now there are about 50 networks that we partner with, and we're adding more every month.

By filling in some details about your ad campaign, you get back a Campaign URL, which you can then send on to the original advertiser.

The information shared about the ad network is generally broken up into three parts -- the source, the medium, and the campaign. Different networks like to record this information in slightly different ways, but you can think of them as generally hierarchical categories.

• The source is typically the ad network itself. (Vungle, AdWords, etc.)
• The medium generally records the type of ad that was shown. (In game banner, full-screen interstitial video, etc.)
• The campaign usually identifies the specific ad campaign that was being run. (Elevator fight, Swimsuit model on a horse, etc.)

With this new URL, the advertising network can let Firebase know that the user clicked on one of their ads before redirecting them to the App / Play Store.


From that point on, when a user performs important events in the app that you have designated as Conversion Events -- things like opening the app for the first time, making a purchase, or sharing the app with their friends -- Firebase Analytics will also note what ad campaign was responsible for bringing you this user.

You'll then be able to filter those events within Firebase Analytics by any of these ad campaign parameters. For instance, you can see what ad network is responsible for giving you the most overall users, by looking at the attribution reports for your first_open event.

You can also see what particular ad campaign is responsible for giving you the most money in an in_app_purchase event, or which ad network gives you users who have clicked your "Yes, I'll review your app!" button. Whatever you can track in a Firebase Analytics event, you can designate as a conversion event.

Postbacks

In addition to receiving attribution information from these ad networks, Firebase Analytics can report back information to these ad networks, in a concept known to most marketing professionals as "completing the circle of life". Actually, nobody calls it that; I just made it up. (But it sounds good, right?) You can ask Firebase to tell these ad networks that a user has completed an important conversion event within your app, which is done via a call known as a Postback.

For instance, if your app were to report back to an ad network that a particular user (as identified by their IDFA / Advertising ID) has gone ahead and opened your app for the first time, that ad network could take advantage of this information to improve its own offerings in a couple of ways. For starters, it now knows that this user has installed your app, so it can stop showing them ads for an app they've already installed. It might also use this information to determine what kinds of apps this user might enjoy in the future.

Setting up a postback in Firebase Analytics is fairly easy. You'll use the Firebase console to determine which conversion events you want to post back to the network, and usually add a little information specific to that advertising network.

You'll also have the option of posting all of your conversion events back to this network, or just the ones that came from this original network. Posting back all conversion events means you'll be doing a better job of training all of your ad networks, and Firebase takes some time to anonymize the other ad networks involved before sending it over. So an ad network might find out that a particular user completed a conversion event in your app, but it won't know which competing ad network was responsible for it.
What about Dynamic Links? So you might have noticed that when you use Firebase Dynamic Links, there's also a space for you to set up tracking parameters with a source, medium, and campaign name. Gosh, sounds awfully familiar, right?

Well, in the same way you can measure the effectiveness of ad campaigns with Firebase Analytics, you can also measure the effectiveness of Firebase Dynamic Links. By adding these tracking parameters to your Dynamic Links, Firebase Analytics can treat them like any other campaign it's measuring attribution reporting for, and you can view conversion events not just by the ad campaigns responsible for bringing in those users, but also by which Dynamic Links might have brought them in.

It's worth noting, however, that Firebase Dynamic Links works best when used in non-marketing contexts -- actions like user-to-user sharing, directing users to your app from your website, or linking to your app in social media posts. If you want to measure the effectiveness of an advertising campaign, you should stick with the traditional methods that these ad networks have already set up and use the Campaign URLs that Firebase provides for you.
Give it a try! So that's the general overview of attribution information in Firebase Analytics. If you haven't yet tried it within your app, I encourage you to give it a try. You might learn something surprising about those ad networks you've been spending your money on.

What separates apps that are good ideas from apps that are really great? Analytics! Successful app developers rely on analytics to determine how users are really interacting with their app. Analytics are at the core of Firebase, helping you make actionable decisions to build products that people love.

We partnered with Udacity to offer a free 2-day interactive course that will help you learn how to use Firebase Analytics to grow your userbase on iOS and Android. Specifically, you'll see how to set goals and how to log users' interactions with an app. You'll even analyze real data from an app that's live in the Google Play Store and in the App Store! And you'll learn from people who live and breathe Firebase: experts Steve Ganem and Todd Kerpelman from Google, as well as Android and iOS developers from Google and Udacity.





The new course will include a combination of short videos, quizzes, code snippets, and a robust online community to help you learn. Check out the course on Android or iOS for free, and see all of our courses at udacity.com/google.

We have some exciting news for Realtime Database developers on the Flame and Blaze plans: we're increasing your concurrent connections limit from 10,000 to 100,000!

Concurrent connections are the number of users simultaneously connected to your database. For context, it's useful to keep in mind that this number is generally one to three full orders of magnitude lower than your daily active users. To reach 100,000 concurrent users, you usually first need to accumulate tens of millions of daily actives.

Historically, we limited the concurrent connections to 10,000 per database. We requested that you reach out to us to raise this limit, which allowed us to do a quick verification of your app's health. We looked for things like unindexed queries or very heavy reads to make sure your app was ready to scale.

Recent improvements to our infrastructure have made it possible to increase that threshold to 100,000 concurrent connections (but you should still index your queries and never add listeners to the root path!). If you need to support even more concurrent connections, please contact us.

We're excited to bring this change to the Firebase Realtime Database. We've been working hard on improving scalability, and we hope this increase will make scaling more seamless for you. As usual, let us know if you have any questions or feedback. We're always excited to hear from you!

Mature applications separate configuration from code. Doing so lets you easily switch between staging and production, deploy an open-source code sample, or spin up a new QA environment (see also "store config in the environment" from the 12 Factor App pattern).

Historically, this has been difficult for Firebase projects on the web, because you needed to keep track of the configuration options for firebase.initializeApp(). You might have had to write code that looked like this:

// DON'T DO THIS ANYMORE!
switch (location.hostname) {
  case 'myapp.com': firebase.initializeApp(prodConfig); break;
  case 'myapp-staging.com': firebase.initializeApp(stagingConfig); break;
  default: firebase.initializeApp(devConfig); break;
}

Not the best experience, plus it exposes your various staging environments in public-facing code. Today we're excited to announce some new features of Firebase Hosting and the Firebase CLI that makes configuring Firebase on your Web app and working with multiple environments much simpler.

On-Demand Firebase SDK Auto-configuration

We've introduced some new reserved URLs to Firebase Hosting that will let you load the Firebase SDK and automatically configure it for the current environment without having to write any custom code. All you have to do is include the right script tags:

  
<!doctype html>
<html>
  <body>

    ...

    <!-- Import and initialize the Firebase SDK -->
    <script src="/__/firebase/3.7.4/firebase-app.js"></script>
    <script src="/__/firebase/3.7.4/firebase-auth.js"></script>
    <script src="/__/firebase/init.js"></script>
    <script>
      // The Firebase SDK is ready to rock!
      firebase.auth().onAuthStateChange(function(user) { /* … */ });
    </script>
  </body>
</html>
 

This works on sites deployed to Firebase Hosting, and also works locally when using firebase serve! The new URLs available are:

• /__/firebase/{VERSION}/firebase-{app,auth,database,messaging,storage}.js - modular SDK files (recommended)
• /__/firebase/{VERSION}/firebase.js - the complete Firebase JS SDK
• /__/firebase/init.js - script that auto-initializes the SDK when included. Must be loaded after any Firebase SDKs.
• /__/firebase/init.json - JSON representation of the configuration for firebase.initializeApp(). You can use this to fetch config and initialize Firebase SDKs asynchronously.

When serving locally, init.js initializes the currently selected project for your project directory (see "Using Project Aliases" for more information). When deployed, it initializes for the deployed project. In addition, when deployed, the scripts are served over HTTP/2 and you can enjoy the benefits of loading the SDK from the same origin without having to manage your own dependencies.


Note: You will need at least version 3.6.0 of the Firebase CLI to use these features, and may need to reauthenticate. If you see a warning message when running firebase deploy, run firebase login --reauth to enable init.js.

Integrating into Existing Toolchains

What if you're not on Firebase Hosting or already bundle or otherwise build your JavaScript? You may want to have other ways to get the configuration for a given project. We've added the new firebase setup:web command to version 3.6.0 of the Firebase CLI. This can serve as a handy reference for copy and paste. The command prints out config information, but can also be integrated with your existing Node.js build process by using the Firebase CLI as a module.
To do so, first install firebase-tools as a dependency:

$ npm install --save firebase-tools@^3.6

Next, require it and call the command. For example:

const fbcli = require('firebase-tools');
const fs = require('fs');

// by default, uses the current project and logged in user
fbcli.setup.web().then(config => {
  fs.writeFileSync(
    'build/initFirebase.js',
    `firebase.initializeApp(${JSON.stringify(config)});`
  );
});

// alternatively, you can pass project or token information
fbcli.setup.web({
  project: 'my-custom-project',
  token: process.env.FIREBASE_TOKEN
});

We think these updates will make it much simpler to build mature, multi-environment web applications on Firebase, and we're excited to see the creative ways you use them. Let us know what you think!

After announcing the Firebase Admin SDKs for Node.js and Java at the Firebase Dev Summit in Berlin last year, we received many feature requests to bring the platform to Python developers as well. Now, we're pleased to announce that first release of the Firebase Admin Python SDK, focusing on Firebase Auth token minting and verification. 

What are the Admin SDKs?

The Firebase Admin SDKs provide developers with programmatic, second-party auth access to Firebase services from trusted environments. Second-party here refers to the fact that the SDKs are granted elevated permissions that allow them to do more than a normal, untrusted client device can. The Admin SDKs get these elevated permissions since they are authenticated with a service account, a special Google account that can be used by applications to access Google services programmatically. The Admin SDKs are meant to complement the existing Firebase web and mobile clients which provide third-party, end-user access to Firebase services on client devices.

What is available in the Admin Python SDK?

As with the other Firebase Admin SDKs, the Python SDK can be initialized using a variety of built-in credential types. The following code shows how to authenticate the SDK using your own service account key file:

import firebase_admin
from firebase_admin import credentials

cred = credentials.Certificate("path/to/service.json")
firebase_admin.initialize_app(cred)

If you are running your code on Google infrastructure, such as Google App Engine or Google Compute Engine, the SDK can auto-discover the credential, allowing you to initialize the SDK with no arguments:

firebase_admin.initialize_app()

The Python Admin SDK contains Firebase Auth custom token minting and ID token verification. The custom token minting gives you complete control over authentication by allowing you to authenticate users or devices using your own authentication system.

uid = "some-uid"
additional_claims = {
  "premiumAccount": True
}

custom_token = auth.create_custom_token(uid, additional_claims)

ID token verification allows you to securely identify the currently signed-in user on your server.

decoded_token = auth.verify_id_token(id_token)
uid = decoded_token["uid"]

The best place to start is with our Admin SDKs setup guide. The guide will walk you through how to download the SDK, generate a service account key file, and use that key file to initialize the Admin SDK.

What is coming next?

We plan to continue to build out the Admin Python SDK to include features already available in the other Admin SDKs, such as a user management API and an FCM API to send messages. We also plan to bring these token minting and verification features to even more languages. To see what APIs are available in each of the Admin SDKs, see our new feature matrix.

To all those Python developers out there, happy hacking!