How Campaign Attribution Works in Google Analytics for Firebase

December 14, 2018
How Campaign Attribution Works in Google Analytics for Firebase blog image

Understanding campaign attribution for mobile apps is definitely a challenge there are many options out there and not a lot of clear resources on exactly how they work. There are also quite a few key points to understand regarding the way that Google Analytics for Firebase handles attribution, which can be tricky to wrap your head around at first if you're coming from a more traditional Google Analytics perspective, like me. This article is the first in my attempt to help clear things up.

First, we’ll focus on how campaigns are given credit with Google Analytics for Firebase  that’s what we’ll cover in this post. In future posts, we will dive into the methods in which you can track your campaigns with Google Analytics for Firebase.

Note: this post will focus on the topics specific to Google Analytics for Firebase, which is now generally considered the recommended approach to app tracking. Check out the docs for campaign tracking information specific to the older Software Development Kits (SDKs).

We have a lot of ground to cover, so let's get started! If you don’t have a Firebase project to follow along with, I recommend that you check out the demo project.

Finding Your Attribution Data

In Google Analytics for Firebase, your most significant interactions are tracked as events and marked as "conversion events" in the interface. Some are marked as conversion events automatically, such as the "first_open" and "session_start" events. You may also mark up to 15 additional events (per project, not per app) as conversion events by using the toggle in the Events report under "Mark as conversion."

Google Analytics for Firebase screen shot

Attribution data is ONLY available for events marked as conversion events. 

Click on any one of your conversion event names to view the traffic sources given credit for those conversions. You’ll see a trendline of how frequently that event has occurred, along with a traffic source breakdown below it. Here’s a look at the "completed_5_levels" conversion event drill-down:

cross channel last click report screen shot

Technically, there is no such thing as a "channel" in Google Analytics for Firebase. You’ll see source as the primary dimension in this table, and you can switch between that, medium and campaign name if you’d like.

Note that "value" is an optional, additional parameter you can specify on your event which would accumulate. There is a great article about that on the Firebase blog.

The Attribution Models

Just above that last table you probably noticed Cross-channel last click as the default attribution model, where essentially the latest source that an individual used to engage with the app prior to a conversion is the one that receives credit.

Cross-channel last engagement is similar but will also provide credit to an ad impression if there is no recent click. This is often referred to as a "view-through conversion" in other platforms, where Firebase will determine whether or not an impression was seen within a given time range prior to the conversion.

And then there are Google Ads preferred last click and Google Ads preferred last engagement which will allow Firebase to attribute a conversion to the latest Google Ads click or impression, regardless of whether there was a more recent engagement via another source (you’ll need to link your Ads account to your Firebase project - we’ll cover this in a future post as well).

Mobile App Campaign Types

There are two primary campaign types for driving traffic to a mobile app: install campaigns and re-engagement campaigns. You'll hear this terminology all over the place, regardless of where you're driving traffic from (Google Ads, AdMob, Facebook, your own website, etc). This is because mobile devices behave differently depending on whether or not the app is already installed, which is important for two reasons:

  1. We have to set up our tracking appropriately for each of these scenarios (we’ll cover this in more detail in a future post!)
  2. Firebase’s attribution windows (the amount of time that Firebase will "look back" for campaign data) are based on the campaign type (we’ll cover this today!)

You must have a solid understanding of these campaign types before you try to interpret the data you see in your reports.

Note that attribution windows are not adjustable in Firebase reports.

Install Campaigns

As you can probably guess, the goal of an install campaign is to drive new installations of your app  you are targeting users who do not currently have the app on their device, and they must be routed through the appropriate app store to download it prior to opening it up. This brings us to the biggest challenge with app campaigns  finding a way to make sure that your campaign data is somehow retained as the user goes through the app store and opens the device, where you can collect it. We’ll save that challenge for the next post, though.

Attribution Window for Install Campaigns

The attribution window for install campaigns is 30 days, and it is based on the "first_open" event. The "first_open" event is an automatically logged event that fires "the first time a user launches an app after installing or re-installing it."

Additionally, if a "first_open" event is attributed to a campaign, "then all other conversion events for that same combination of user and app are attributed to that same campaign until the attribution window expires in one year. The attribution window is renewed for one year with each subsequent conversion that occurs before expiration." This means that as soon as a campaign gets credit for a "first_open" event, that campaign also gets credit for other conversion events for up to one year, and that's a rolling one year where each new conversion within the year extends the window another year from that date.

So if I install your app today, say Google Ads gets credit for the "first_open", if I continue to engage with your app and trigger another type of conversion two months from now, Google Ads gets credit for that conversion, too, and the window is extended to one year from two months from now. This ensures that the initial campaign receives credit for all future conversion events.

For this reason, the "first_open" conversion event also shows purchases, revenue, and lifetime value in its drill-down table (Conversions > select "first_open"):

first open event screen shot

The "first_open" event is the ONLY conversion event that includes these additional metrics - all other conversion events only show a count of conversion events, such as in our very first example above. These additional metrics are generated by Firebase and are designed to help you understand how the sources that led to "first_open" events were also responsible for generating revenue.

***Although the documentation is a little vague, it is my understanding that "first_open" campaigns only get credit for "eCommerce_purchase" and "in_app_purchase" conversion events, NOT all other conversion events, because purchases, revenue, and LTV are all eCommerce-specific metrics.***

  • Purchases: sum of "eCommerce_purchase" (custom) and/or "in_app_purchase" (auto) events
  • Revenue: sum of revenue collected with one of the above events
  • Lifetime Value: average value per user  accumulates only on first_open-associated campaigns

Re-Engagement Campaigns

Re-engagement campaigns are designed to encourage customers to continue using your app after they have installed it. These campaigns tend to be easier to track because you don't have to deal with the hurdle of passing campaign data through an app store because the app is already installed on your target audience's device.

Attribution Window for Re-Engagement Campaigns

For all conversion events other than "first_open" events, the attribution window is six months (Note: after June 29, 2020, this will change to 90 days). Sources identified for these conversion events are basically considered re-engagement campaigns.

A note to call out from the documentation is this:

A conversion from a re-engagement campaign gets attributed twice:

  • To the campaign that got credit for the first_open event. LTV accrues with that campaign.
  • To the re-engagement campaign. No LTV accrues with that campaign.

As I said, it is my understanding that this refers to eCommerce-specific conversions and the fact that they result in the additional metrics you see for the "first_open" event, specifically (in other words, this is basically describing the fact that the campaigns you see when you drill into the "first_open" event also have purchase, revenue and LTV metrics associated with them).

Traffic Sources & Channels

In regular old Google Analytics, “channel” is a construct Google Analytics uses to group traffic from specific combinations of sources and mediums together into more general buckets. For instance, all traffic that has a medium of "email" is grouped into the Email channel. Referral traffic from a known social network is grouped into the Social channel. You’re probably familiar with this concept already.

Firebase does not have the concept of a “channel” at all. Instead, you only see the source, medium and campaign values that it had identified in your reports. Keep in mind that if you are exporting your data to BigQuery, you could come up with your own channel definitions and group your traffic sources accordingly if you want to. Perhaps you could even do this with Data Studio's custom fields (you must pull the Firebase data from BigQuery though).

Where do these values come from? Well, it depends. Firebase is designed to identify these in many cases for you, but there are times when you have to do some extra work to get your campaign data, however. In future posts, we’ll talk more about some of the various types of mobile app campaigns and how you can track them. There is simply not enough room to fit enough detail about each of those into this post.

For starters, take a look at the documentation under “How different conversions are attributed”  here you can see what the typical source and medium would be for various types of campaigns.

A Note About Direct

You'll still see (direct) / (none) in Firebase as a potential source / medium combination. This is basically "campaignless" traffic that has not yet had any campaign data associated with it.

This can happen when a user engages with the app but they have come from a source that Firebase hasn't recognized. Some examples of that include Apple Search organic links, Google Ads iOS Search App install campaigns, and other untagged/untracked campaigns.

Direct will only receive credit for a conversion if no campaign data has been collected within the given attribution window.

Up Next: Options for Tracking Mobile App Campaigns

There is a lot more detail to cover on this topic but we just couldn’t fit it all in here. So in future posts, we’ll take a closer look the options for how you can track various mobile app campaigns with Google Analytics for Firebase, such as for Google Ads campaigns, campaigns on social networks or even web to app campaigns.