Thursday 27 April 2017

Understanding Attribution in Firebase Analytics

Todd Kerpleman
Todd Kerpelman
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.
    Share:

    Wednesday 26 April 2017

    Angular 4.1.0 Now Available

    Angular version 4.1.0 - is now available. This is a minor release following our announced adoption of Semantic Versioning, meaning that it contains no breaking changes and that it is a drop-in replacement for 4.x.x.

    What's new?
    • Version 4.1 adds full support for TypeScript 2.2 and 2.3. Developers previously reported good experiences with TypeScript 2.2 and 2.3, but Angular is now built with TypeScript 2.3. This does not affect our support for TypeScript 2.1 which shipped with 4.0.
    • Angular is now compliant with TypeScript’s StrictNullChecks. This means that you can enable StrictNullChecks in your project, if desired.

    For the complete list of features and bugfixes please see the changelog.
    Share:

    Monday 24 April 2017

    React Native Router Navigations - Tutorial Part 3

    This is again the continued post on React Native series. This post explains routing and navigation to different tabs in an application using React Native. Navigation is all about how the user can access possible sequences of pages in a web application. Routing is the encoding and decoding of URLs used in the application. Routing is supported by some set of rules. Each application must provide defined set of rules. Once the routing rules are defined, we can use the URLs containing view names and their parameters to navigate to different pages/tabs in the application.

    React Native Router Navigations

    Read more »
    Share:

    Wednesday 19 April 2017

    Ionic 3 and Angular 4: Working with Signature Pad.

    This tutorial explains how to upgrade to Ionic 3 and Angular 4 and how to use signature pad for your application. If you are working with some agreement related project or something which needs some written proof from the customers, we might in need of a signature pad. The combination of Ionic 3 and Angular 4 provides some better features to achieve signature pad. This will allow you to sign/draw something on the application and save that image as data on the screen. Using this tutorial, you can also make a signature pad with Ionic 2 and Angular 3. Why late? Let’s start this small, but most commonly used task in your application.

    Ionic 2 and Angular 2: Using the Native Camera

    Read more »
    Share:

    Wednesday 12 April 2017

    Brand new course from Udacity and Google

    Jen Person
    Jen Person
    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.
    Share:

    Monday 10 April 2017

    Official languages at Google

    Following my keynote at ng-conf 2017 that seemed to indicate that Typescript is now an official language at Google, there were many questions about the status of Dart at Google.

    We would like to clarify that both Dart and Typescript are in the same category. They both are  allowed to be used for client side development. They are, however, not in the same category as more established languages like Javascript/Closure and Java — those have both more lines of code and more tooling.

    Dart has been used for unrestricted client development at Google now for 4+ years. Dart and AngularDart are used by large products such as AdWords, AdSense and Shopping, and by critical internal tools such as Google CRM. In addition, the Flutter cross-platform mobile app framework uses Dart and is used by multiple teams at Google including Google CRM and Shopping Express. The Google codebase contains many millions of lines of Dart code.

    Typescript has become allowed for unrestricted client development as of March 2017. TypeScript and Angular on TypeScript are used in Google Analytics, Firebase, and Google Cloud Platform and critical internal tools such as bug tracking, employee reviews, and product approval and launch tools.

    We are happy to say that teams at Google have a choice between many client side languages and can choose the best one for their needs.
    Share:

    Friday 7 April 2017

    Increasing the Realtime Database concurrency limits


    Tony Meng
    Tony Meng
    Software Engineer

    Alex Dufetel
    Alex Dufetel
    Product Manager
    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!
    Share:

    Thursday 6 April 2017

    Ionic 3 and Angular 2: Using the Native Camera, Take Multiple Photos with Delete Action.

    Are you searching for easy camera access for taking multiple pictures in your mobile application? Then here is the post explaining on how to access camera and take pictures. In most recent days, this is achieved easily with the combination of Ionic framework and AngularJS. We have already discussed in my previous article, how easy it is to use pre-built it in components of Ionic with AngularJS and build awesome mobile apps. Today’s article explains Cordova plugin provided by Ionic framework to access camera , take picture and see the output. The most exciting thing about this article is, it explains you to upload multiple images you take in camera. Let’s follow the article and also the video tutorial on this.

    Ionic 2 and Angular 2: Using the Native Camera

    Read more »
    Share:

    Easier configuration for Firebase on the web

    Michael Bleigh
    Michael Bleigh
    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:
      
    <!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!
    Share:

    Wednesday 5 April 2017

    Bringing Firebase Admin To Python

    Diego Giorgini
    Hiranya Jayathilaka
    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.

    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!
    Share:

    Sunday 2 April 2017

    React Native JSON Parsing and Helper Functions - Tutorial Part 2

    This is the continuation of previous article Getting started with React Native Template Design – Tutorial Part I. Today’s article and video tutorial explains how to parse and render the json data using some of the best React Native packages. It explains how to make ajax calls using fetch. Fetch is the networking API, which is chosen by React Native to get the JSON data and render it in the page. I hope embedded videos with blog posts are more advantageous for you to learn. I appreciate to take any feedback if you have, so that I can make it better.

    React Native Template Design

    Read more »
    Share: