Developer Advocate
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.
Course Developer
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!
Engineer, Firebase Hosting
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:
...
This works on sites deployed to Firebase Hosting, and also
works locally when using firebase serve! The new URLs available
are:
/__/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!
Software Engineer
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.
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!