jumper0k jumper0k - 1 month ago 8
iOS Question

Google Analytics iOS Campaign Tracking and URL Builder

We want to track installs with Google Analytics for our iOS app.
What we already done:

  • we have last iOS SDK 3.10

  • we enabled idfa collection like it says here

idfa enabled

enter image description here

Seems everything OK. But tracking link doesn't work.
For user, that was redirected from this link, ga:campaign and ga:source are empty in GA database:

enter image description here

And there is nothing in Google Analytics Acquisition, only direct traffic:

enter image description here

We are very confusing about the field Device ID Macro in URL Builder. Is it filled right? Any other ideas how to make the GA tracking work?


The information below is only valid for iOS Install Tracking, Campaigns that target users that already have the app and deeplink into them are handled completely different.

This was designed to work with mobile adNetworks. When you create this campaign for your app in an adNetwork you can work with them to know how to pass the deviceId, each network might have its own syntax, and they can work in 2 different methods (ping or redirect).

If you are planning to use this url in a social campaign of some sort, or if you are testing it out by just visiting that url it won't work. Because a browser can't figure out the IDFA only an App can.

This is also the id used by Google Analytics to link an Ad click with the actual installation of the App.

Here's how it works for Google Analytics on redirect mode:

  1. The user is playing candy crush and sees a banner for your app.

  2. The user thinks it's a very sweet app so he clicks on it to install your app.

  3. The mobile network grabs the IDFA from inside candy crush and sends the user to a google analytic redirect url that looks like this: https://click.google-analytics.com/redirect

  4. Google Analytics registers that specific IDFA clicked on your banner for your AppId and stores the campaign parameters for a while associated with this.

  5. The redirect takes place and the user lands straight at the AppStore for your App.

  6. If everything goes according to plan, the user hopefully installs your app and launches it.

  7. When he/she does so Google Analytics grabs the IDFA and start to register stats for your app, including appId.

  8. Then Google Analytics notice that's the same IDFA that clicked on that link for the same appId just a few minutes ago.

  9. Google Analytics assumes the click generated an install and assigns the campaign information to that user.

Ping mode is pretty much the same except that the adNetwork sends the url to analytics themselves so the user doesn't have to go through a redirect.

So as you can see it's quite a journey, but it should work fine if you:

And for testing you will need to do that through either a live ad or a test version of your ad, if the network provides that.

UPDATE (2015-02-25)

Q: How can you do install tracking for campaigns that don't go through an adNetwork? eg (social campaigns, email campaigns, ...)

A: Google Analytics doesn't have support for that. Other attribution tools might try to fingerprint the user without using the IDFA, using IP address for instance, but that's not reliable, so Google Analytics opted to use only the IDFA.

If the campaign is through email you might have other ways to fingerprint. You obviously know the user email, so you can store it in your database and give it a uniqueId. When the user clicks on your mail marketing you can go through a redirect on your systems where you register that userId as a custom dimension and send a hit to GA with campaign information using the measurement protocol through your BackEnd. Then when/if the user logs in your application you get the same userId and send other hits associated with it.

You have to use a uniqueId because the email itself is forbidden inside Google Analytics per TOS. You can't send it there.

This solution has other drawbacks as you will get hits for every user that clicks in your campaign in GA, but only those that actually install the APP will have future hits. So you might have inflated sessions with a single hit that never install the App. For that reason I'd recommend sending this to a secondary Google Analytics Web Property to avoid polluting your main property.

As you can see it's not a great solution, but it's the only way you can do it. I wouldn't recommend spending time with a solution like this that creates other problems and is not reliable.