#46 Google Analytics for apps (i.e. Firebase) vs. websites
This week Dan and Dara discuss the differences in setting up and using the data from Google Analytics on apps versus websites. Dan recently built an Android app using Unity, and they both chat through how he found the process of ‘tagging’ it us with Firebase Analytics/Google Analaytics for Firebase/Google Analytics!
Check out Dan’s GA and GTM resources when using Unity for app development on his blog – https://bit.ly/3crM4h8.
This blog from Todd Kerpelman is a funny account of all the confusion around the Firebase/Google/Analytics names, well worth a read! – https://bit.ly/3PHEgGp.
In other news, Dan is HOT and Dara is HOT!
Follow Measurelab on LinkedIn for all the latest podcast episodes, analytics resources and industry news at https://bit.ly/3Ka513y.
Intro music composed by the amazing Confidential (Spotify https://spoti.fi/3JnEdg6).
If you’re liking the show, please show some support and leave a rating on Spotify.
If you have some feedback or a suggestion for Dan and Dara, fill in the form https://bit.ly/3MNtPzl to let them know. Alternatively, you can email podcast@measurelab.co.uk to drop them a message.
Transcript
[00:00:00] Dara: Hello and welcome back to The Measure Pod, episode number 46. This is a place for people in the analytics world to talk about all things analytics. I’m Dara, MD at Measurelab.
[00:00:26] Daniel: My name’s Dan, I’m an analytics consultant and trainer at Measurelab. So this week Dara, there’s been an announcement from Google Analytics 4, and I think it’s been the one that a lot of people have been waiting for, for quite some time. So the hill that Google Analytics decided to die on was the fact that they deprecated bounce rate and so they introduced this new metric called engagement rate, which is meant to be like a spiritual successor or the inverse, the kind of glass half full, rather than the glass half empty kind of metric.
[00:00:50] Daniel: However they have caved and they’re introducing bounce rate back into the reports. But alongside the bounce rate introduction, they’re actually releasing a couple of quite sought after metrics too. So they’re finally going to introduce conversion rate at a session level and user level. And finally they are going to start supporting the UTM_content and the UTM_term. So like, it’s been a long time coming, but they’re starting to realise that we kind of used this stuff and needed it.
[00:01:15] Dara: They held off as long as they could and just waited until the complaints reached a certain level.
[00:01:20] Daniel: Yeah, exactly. I mean who knows what was going through their minds? I can kind of see the bounce rate argument because it’s easy enough to do the inverse of an existing metric. Conversion rates in a report seemed pretty obvious, but also not supporting some of the UTMs that have always been supported, that felt a bit odd.
[00:01:34] Dara: Yeah that one didn’t make a lot of sense. I would’ve been secretly quite happy if they stuck to their guns and didn’t bring back bounce rate, but maybe that’s just me.
[00:01:42] Daniel: I think our thoughts on the bounce rate are pretty well known by now, but yeah, it is really interesting, you ask a marketer and they love bounce rate and you ask an analyst, they hate bounce rate. So there is a fence and you either fall one side or the other.
[00:01:52] Dara: True, it’s like Marmite. So onto our topic this week, so we are going to be talking about Google Analytics for apps versus websites. Hopefully clearing up a little bit of confusion that we ourselves have suffered from. And just talking about some of the differences between the two.
[00:02:07] Daniel: This is actually spun out of some work I’ve been doing this week. So I’ve always dabbled in a platform called Unity, which is like an app development framework for the last couple of years. It was a lockdown project back in early 2020, but actually it’s kind of blossomed into something a bit more. I’ve kind of dabbled in building different games and applications for Android over the last couple of years. This week I was chatting to some of our colleagues at Measurelab and we decided to build a new Android app with the idea of testing the implementation from end to end of Google Analytics and also seeing if we can get Google Tag Manager set up alongside of it. So we’ll talk about the tag manager side probably another time, but actually there’s a lot of interesting stuff that came out of someone that’s very much web focused in their day to day diving into the other swimming pool and start playing with the app dev side of things.
[00:02:53] Daniel: So I think actually we will talk a bit about kind app development cycle or process that we do with analytics with apps, is slightly different, but more importantly, it’s more like a change of mindset or a change of the way to approach things. Fundamentally we’re tracking pretty much the exact same data. Everything from the jargon, terminology, to the actual implementation is completely different. And it’s always good to have a lay of the land in a way to get a bit of a feel for how it works so that we can best advise on approaches and implementation requirements, that kind of thing.
[00:03:22] Dara: Okay before we get too into the details, it’s really worth backing up and taking a little trip just down recent history in terms of how app tracking has evolved from the Google perspective. Previously there was Google Analytics for mobile, and this was a set of SDKs (Software Development Kits) that worked with Universal Analytics, but it was always a little bit hacky or shoehorned because it was basically collecting data within apps, but then shoehorning that data into the familiar Universal Analytics reporting interface. Which never really worked brilliantly well and was never going to be a long term solution for Google in terms of tracking apps. So they then bought a platform called or a tool called Firebase.
[00:04:08] Daniel: And when they bought Firebase, that’s where it really started taking shape. So Firebase is a suite of products, kinda like the Google Marketing Platform, but for app development. So it’s a set of, or a suite of tools that helps everything from the building, monitoring, optimising and monetisation of any Android and iOS apps. In 2016, they actually built a Firebase Analytics (FA) platform. So analytics was rolled up in part of this suite and this is the first time that we had this whole I suppose this is the, the originator of where the confusion starts with all these names, whether it’s Firebase, Google Analytics, all of that stuff. So originally Firebase Analytics, 2016, it came out, very rocky start. It’s made a huge amount of improvement since then. It’s come on leaps and bounds. But what they did is after a while, as they were developing this product, they were taking more and more from Google Analytics and actually the teams behind the scenes, from what I understand, were kind of talking together and collaborating.
[00:04:56] Daniel: And so eventually they did a rebrand of Firebase Analytics and they called it Google Analytics for Firebase (GAFF). So this is the first name change, that’s almost not changed at all. And then since the release of Google Analytics 4, and especially coming into 2022 at the beginning of 2022, it rebranded again and was all officially Google Analytics, just Google Analytics. And I suppose from people like us Dara from the web side, we’ll think of that as Google Analytics 4, but again, from the app perspective, it’s just called Google Analytics. So it’s gone from Firebase Analytics to Google Analytics for Firebase to Google Analytics (within Firebase). There’s the kind of secret silent sort of, part of that name there. And this is where still to this day, everyone gets very confused when we talk about, is it Firebase or Google Analytics or is it Google Analytics for Firebase or GA4? We’ve got a lot of these names flying around, but actually we are talking about the same thing.
[00:05:45] Daniel: And actually when I built this little Android app over the last week or so, I was implementing all the GA4 tracking and in my head I know it’s GA4 and I log into Google Analytics in the GA4 property and have a data stream and I can see the data there. However, everything to do with the implementation has got references to Firebase Analytics because when they set up Firebase Analytics back in 2016, they kind of made their bed and they have to lay in it. So all of the SDKs (Software Development Kits), all of the frameworks, all of the codes you use. Everything, I was using all the libraries I’m using are all reference to Firebase Analytics. And actually if they change that to Google Analytics now it’s probably going to mess up every app out there that has a, has Google Analytics implemented on it.
[00:06:21] Daniel: So from an implementation perspective, when we’re talking to app devs, in a sense we’re translating, we’re saying implement Firebase or Firebase Analytics, but in the back of our mind, we know we’re talking about Google Analytics and GA4. Because from an app dev perspective, or if you’re an app developer, you never actually have to see Google Analytics and you never even have to hear about Google Analytics. That’s almost like a front-end reporting set up that they don’t really care about. It’s kind of unavoidable in websites, right? So if you’re doing the GTM (Google Tag Manager) implementation, you are using the GA4 tags, the GA4 config tag, and the event tags, and you can’t avoid the term Google Analytics. Whereas in app development, we are kind of stuck in the past a little bit, not so far in the past, this is 2016, we’re talking about, but we’re still stuck with this, this term Firebase Analytics, even though it’s had two name changes since then, we still can’t get away from the fact that we are implementing the Firebase Analytics, SDK (Software Development Kit), and even the SDK (Software Development Kit) is still named FirebaseAnalytics.
[00:07:10] Dara: But despite that obvious confusion with the naming and the transition between the products or arguably some poor choices of names along the way, the end result is pretty good in that you now have the right technology to track websites and apps, and they’re both actually feeding into a reporting interface that’s built to handle both of those different types of data. In the past it was tending to be, either be that the data collection was okay, but the reporting interface was wrong and then there was also some confusion around where to find the data when you could access it in Firebase or in GA (Google Analytics). And now you have a single reporting interface with the right data collection to collect data from both apps and websites and report on either or both of those within a reporting interface that’s suitable for the challenge and it’s in theory, at least faster and built for the kind of volume of data and scale that’s needed these days as opposed to something that was 15 years old.
[00:08:07] Daniel: Yeah, for sure. But it’s interesting you mentioned the UI because there’s a lot of tension I think still within the Firebase community, just because what they’ve been doing over the last, especially the last year for the last couple of years is they’ve been actually scaling down the analytics part of the Firebase interface and forcing everyone to go over to Google Analytics, the actual domain analytics.google.com to go and see the data. And in a sense, from the app dev perspective, they’re kind of removing features, they’re removing functionality and they’re removing the kind of stuff and they’re moving it and porting it over to Google Analytics. And for people like us, again, coming from the web side, it’s amazing. We now have this better, well, I suppose this better schema, let’s not say it’s a better tool, but a better schema and we can now integrate app and web together and it’s pretty cool. So there is this kind of like bone of contention I think a little bit, with the two sides of that of the fence from the app and the web side, of like, you are taking my stuff is definitely all coming over to the web side or at least all centralising in Google Analytics, which is perceived as a web product because historically it always has been.
[00:09:04] Daniel: Another thing which is really interesting is when I run Google Analytics 4 training sessions, quite often I have a mix of app people and web people. And I like to ask the question at the beginning of the session, who’s here to measure apps, who’s here to measure websites and especially on some of the public training sessions we do there’s a nice mix of different people. It’s quite predominantly web-focused because there’s a big shift happening at the moment obviously with the deadline next year to move over, but it’s always a mix. What I find really interesting is that if you are from the app world and from the Firebase world, actually GA4 is not scary and it’s not that new, and it’s not that different. Because it is fundamentally Firebase Analytics just made compatible for websites.
[00:09:40] Daniel: Whereas if you’re coming from the web perspective, which, you know, a lot of people in our circles Dara are, it’s hugely different because we are basically having to throw away all of the knowledge we’ve got on Universal Analytics and starting again. The only commonality is that some of the names are the same of some of the features, you know, fundamentally it’s a different technology, sort of driving everything, powering everything behind the scenes. There’s an interesting mix here of, you know there’s this kind of like battle or this kind of contention that’s created through moving things out Firebase and into Google Analytics but then also we’ve got the two sides of the fence again where they’re saying, oh, this is absolutely fine, Google Analytics is not scary, it’s not daunting because it’s what they already knew. And then the other side of it are coming at it saying, well, this is so different, how the hell do I use this thing?
[00:10:19] Dara: And in a year’s time, it’s all anyone will know and all previous knowledge will be forgotten and everybody will just talk about, I guess it won’t be GA4 then maybe it’ll just be GA (Google Analytics) and that’ll include apps and websites.
[00:10:33] Daniel: Do you reckon they’ll drop the numbering system then? Or do you reckon they’ve kind of lost that battle and it’s going to be number 4 forever.
[00:10:37] Dara: It’ll make me laugh. I’ll enjoy it if they drop it and make it just Google Analytics.
[00:10:42] Daniel: They’ve done that with 360, right? I’m talking to the wrong person here, but this is a video gaming analogy Dara, but when Nintendo released the 3DS they released then another console called the New 3DS so it’s called exactly the same thing, but with the word new in front of it, and it just reminds me of the 360 contract, you’ve got the 360 contract, and then you’ve got the ‘new’ 360 contract. Yeah, I wonder if they will eventually drop it, but yeah, it’s interesting for now they’re trying to kind of differentiate it, but eventually it will be the only one left.
[00:11:06] Dara: Exactly and it’s confusing. So if you’re listening and you’re confused by all of this, you’re not alone. It is confusing and has been, but yeah hopefully the paths are narrowing and it’s going to become clearer as time goes on. In terms of setting it up within GA4, you could have a single property, and then you could be tracking a website in one data stream and an app or apps in additional data streams, all tracked under the one property. So within the data streams themselves, are there kind of major differences between how it works if it’s an app data stream versus a website data stream?
[00:11:40] Daniel: Fundamentally, it’s very similar. So the thing that changes is the jargon, is the names of things. So when you are building something for an app environment, whether it’s Android or iOS, you always have to start in Firebase. So you always start in Firebase, actually part of the workflow now when you’re creating a new project in Firebase, is that it automatically creates a GA4 property for you. You can optionally tick a box to not do that, if you’ve already got the web property set up, but actually it’s part of the workflow now, when you create a new project, it creates Google Analytics over here. But that’s the terminology is that it is a one-to-one mapping between a Firebase project and a GA4 property. And so this is another kind of confusion or point of confusion when it comes to these two kind of worlds colliding, is that we have this confusion around the relationship between properties and projects and they’re actually one-to-one.
[00:12:26] Daniel: In GA4, you can only link a GA4 property to one project. So the same way you would in GA4, you might have one property and you might track a bunch of sub domains or domains within that property. It’s the same in Firebase, where you have one project and you’ll have different apps doing the same thing basically within there. So you will have your Android and your iOS apps within one project and In GA4 you’ll have one property which connects to that project in Firebase and pulls in those app data streams. But then of course you can add in the web side on top within GA4. But you can’t create the Android and iOS tracking from the Google Analytics interface, you are forced into Firebase to create a project. The workflow is really detailed in there. And again, I used Unity, which is an app development framework and there’s crazy amounts of documentation. The process was pretty straightforward, I just followed their tool tips and prompts on the screen and I got it up and running. So yeah, it’s relatively straightforward, but you have to start in Firebase and then you go and connect the dots back over to Google Analytics.
[00:13:23] Daniel: If you don’t have a web component, it will do that for you automatically as part of this workflow nowadays. It’s unavoidable, the worlds are, I don’t know if they’re ever going to get closer. I wonder if they’ll roll it up into one. I don’t know if they will do it into one platform eventually, but yeah. So projects, properties are the same thing just in the different worlds. And they’re connected one-to-one and you have to be in Firebase to set up your apps and then the kind of GA (Google Analytics) side of it is purely a reporting aesthetic that sits on top. That’s the way I’m thinking about it at least.
[00:13:51] Dara: And are there any differences in terms of the configurable, so not at the code level, but at the kind of admin level in GA4, are there any major differences in terms of what’s configurable for, effectively is an app data stream the same as a web data stream?
[00:14:07] Daniel: So the data’s the same, even if you go into the real time data, the reports, it’s exactly the same. There isn’t a difference, it’s the same data in the same format. It’s just that in the GA interface, you have more configuration options. In terms of the administration side and the configuration everything has to be done from Google Analytics now. So configuring things like custom dimensions, audiences, any of the time zone settings, data retention policies, the Google Signal stuff, all of that is done from the Google Analytics side. You’re just forced over into the Google Analytics interface. Something you can do actually from both sides is set up the BigQuery export, but it’s not different, they’re not different datasets, the Firebase data is the GA (Google Analytics) data, it’s the same thing. So if you set it up in the Firebase side, you’ll see the connection appear in the GA (Google Analytics) side and vice versa. So it is confusing because there is sometimes two places to do something, but it is one data set.
[00:14:53] Dara: Even though the porting is the same, there’ll be differences in terms of like, for example, any the automatically tracked events, there’d be certain events that would only be kind of app specific. Things like different versions of app, for example, or uninstalls, things like that. First open, they’re all going to be specific to apps, right?
[00:15:12] Daniel: Just like on the web side, there’s a lot of automatically collected events. On the app side there’s actually a lot more, which is really interesting. So like in app purchases, the uninstalls, as you mentioned, but also app updates, OS updates, even if you’re doing push notifications, all of these things attract automatically and it’s a really, really quite healthy dataset you get out of the box just by implementing the Firebase Analytics SDK, however there’s some things that aren’t maybe that we expect to have that, you know, because we are kind of biassed from the web perspective, but things like the Enhanced Measurement events. So the outbound link clicks, the file downloads, the YouTube video plays, things like that, the scroll depth things. None of that is collected automatically because in a sense there isn’t a href link, there isn’t a standard format for PDF downloads. So what you are forced into doing is using the same naming convention as the Enhanced Measurement events, but you’re going to have to track them as a custom event purely because there’s no way to scrape that kind of interactive stuff on the app.
[00:16:08] Daniel: So it’s good in some ways, you get a lot of automatically collected data, but that’s more from the uninstalls, updates, iOS updates, things like that. You don’t get any of the behavioural stuff that you would expect to get from the Enhanced Measurement events on the website. That’s all stuff you have to do yourself.
[00:16:23] Dara: And you said you should use the same naming convention, do you have to do that? Why would you need to use the same naming convention if you’re replicating them as custom events.
[00:16:32] Daniel: So, no, you’re right you don’t have to. It’s purely like best practice. And it’s the same way I would say, if you are posting frequently on Facebook, use the same UTM codes. You don’t have to, but you want to keep a consistency so that you can aggregate super easily all of the same data together if you so choose, but you still have the opportunity to separate them out.
[00:16:50] Dara: I feel like I’m interrogating you here, but that leads me onto my next question. So in terms of aggregating the data, is there a way to do that within the reporting interface, would you have to do that in BigQuery or outside of GA4 in some way? Is there an equivalent of a, is there a roll-up data stream?
[00:17:06] Daniel: There’s no roll-up data stream, but by default, the Google Analytics 4 reporting is at the property level. If you’ve got three data streams, Android, iOS, and web, all of your reports out of the box are going to be by default, a roll-up view of everything. And then you can use tools like comparisons within the reporting interface to then pick out the platforms of choice, if you so choose. In a sense, you’re kind of starting with everything you have to unpick what you want, which coming from a web world of Universal Analytics is the opposite way round. You start with your filtered view and you have the option of going up to the roll up if you would like. So it’s a different way round of thinking, I don’t know if it’s better or worse, but there is inherently a roll up, which is the default.
[00:17:42] Dara: Are there any other differences? Presumably there’s no difference in the limits or anything else if it’s given that they’re effectively the same kind of data stream, you’re just defining what source the data is coming from.
[00:17:53] Daniel: Yes I think there are some arbitrary limits on the tech side of how many events you can log per hour, per day, per user, those kind of things, but nothing that we probably ever will come up against. The only fundamental difference from the kind of app world that’s worth noting is that apps, well, most apps don’t have to be online to be used, which websites do. And so this is the big difference. If you’ve got a game, for example, let’s say you’ve got a solitaire game, app that you’ve built, most likely that’ll be able to be run online and offline. And so what happens to the offline activity when someone’s playing the game and they don’t have an internet connection to send that data to Google Analytics. And actually what happens is it batches the data so the events. So if you can imagine like while you’re offline or while there’s no internet connection, or if there’s a, just a glitch, which with any tech can always happen. It banks all of these events in a cache and then if you connect to the internet at a later point, it’ll then batch those off into Google Analytics.
[00:18:48] Daniel: However, Google Analytics will only accept data within the last 72 hours, and this is a really important note to make. So that technically, if you’re tracking apps, there is a variability to your data for three days, which means that that’s a good thing if someone has played the game or browsed the app or done whatever they’re doing on the app and they connect to wifi later on that day. But especially in India, that I was reading about where it is quite common for people to connect to wifi maybe once or twice a day, but not have sort of 4G, 5G network throughout the day. So these are the kind of things that it accounts for. However, it just means that it’s a bit of an odd system where on websites, you expect everything to happen in real time. If you don’t have an internet connection, you can’t load the website full stop. Whereas on an app it’s not quite the same thing.
[00:19:27] Daniel: So first of all, if they don’t connect to the internet ever, or if it’s outside of that 72 hours, you’re never going to get that data. They’re going to be using the app, they’re going to be doing all sorts of cool stuff, but you are never going to know, that’s just something we have to accept. However, there is a three day variability to the data in case something pops in from two days ago, which it’s just more of a question for us to look into I think Dara. But actually, how does that affect things like the BigQuery export, how does that affect the audience creations and things you might be doing in kind of syncing that data outside of Google Analytics, I have no idea. And all I know is it’s a bit fickle and the Google Analytics has a window, which it accounts for this, but I actually don’t know the extent of what it means by ‘accounts for’.
[00:20:04] Dara: Yeah they’re really interesting questions in the, you know, for the audiences, if there’s an additional person with that data from a user who is offline and then that gets batch uploaded, are they going to then magically appear in your audience that you’ve created? Or is that just a case of tough luck and same question with the BigQuery export, are they going to redo that day’s export? Is it just a case of, well, that was the data at the time. Yeah, really good questions to figure out the answers to those. And by the way, thanks for mentioning solitaire, which is a game I actually know of so I appreciate you including me in the reference for once. But that batch data, this is an obvious question really, but it’s all timestamped. So even though it doesn’t appear at the time, it is all sequenced correctly when it does actually hit the reports.
[00:20:48] Daniel: I’m going to assume so, but I’ve learned not to make any assumptions for this kind of stuff. So when the event occurs, it does have the timestamp and I would imagine that it holds in the cache or the local storage, or again, I’m using web vernacular, but the app equivalent with that timestamp, but to be honest I have no proof of that, I haven’t tested that myself. So let’s just assume so, but another good question for us to look into.
[00:21:11] Dara: Well this is undoubtedly a subject we’ll come back to in a future episode and dig more into. You mentioned GTM (Google Tag Manager), I think towards the beginning. We’ll probably come back to use cases with GTM (Google Tag Manager) and apps in a future episode. And now that I’ve said that we kind of have to, but I think that’s a pretty good summary of what we’ve been talking about and what you’ve been doing a bit of your own experimentation with recently, Dan. So what have you been doing to wind down?
[00:21:35] Daniel: So Dara, this is actually not really winding down because I can’t stop thinking about the heat right now. We’re recording in the middle of the heat wave and I’m just really hot and I can’t do anything, but think about how hot I am. And so I don’t have anything interesting or exciting to talk about other than I’m hot and I hope it cools down soon. How about you? Have you been doing anything other than thinking about the heat?
[00:21:54] Dara: That’s certainly been front and centre. I mean, I feel like I said it last week, because I did. I talked about enjoying the nice weather, so it has been exceptionally hot and at the time we are recording this tomorrow is going to be the hottest apparent. So I’ve been kind of trying to avoid the worst of it. But I have been out and about, so it’s been nice to be able to sit in the garden and get out for a run in the sun when it’s not too hot. But no outside of that, it’s hard to do anything else other than just try to stay cool, but I’m not complaining. All right, so I know this very well from asking you every time, but where can our listeners find out more about you, Dan?
[00:22:29] Daniel: So it’s over on my website, which is Daralytics, I mean danalytics.co.uk. And actually I’ve been writing up a lot of the implementation steps in Unity. So if you fancy learning Unity, or if you’re interested in dabbling, like in the kind of stuff that I’ve been doing, then I’m writing up a couple of guides on there at the moment and I’ve got a newsletter. So whenever it’s published it just pings out an email to everyone. Alternatively LinkedIn, just search my name, and again all the links to these will be in the show notes.
[00:22:52] Dara: For me, the easiest way to get in touch is on LinkedIn. Okay, that’s it from us for this week as ever to hear more from Dan and myself on GA4 and analytics in general, all our previous episodes are available in our archive, which you can find at measurelab.co.uk/podcast. Or you can just use whatever app you’re using right now to listen to this.
[00:23:13] Daniel: And if you want to get in touch with me and Dara, then there’s a Google form in the show notes which you can fill out, or you can just email podcast@measurelab.co.uk and that will get through to us.
[00:23:23] Dara: Our theme music is from Confidential, you can find links to their music in our show notes. I’ve been Dara joined by Dan, so on behalf of both of us thanks for listening and see you next time.
Daniel Perry-Reed
Subscribe to our newsletter:
Further reading
Customer Data Platforms (CDPs)
Grand Designs: “The Warehouse to CDP conversion”
