Working with mobile apps and the teams around them can be tricky, especially since as technical marketers or analysts we love to have control over the tracking implementation, the changes we want to make, and especially the time we spend doing these things.
When it comes to mobile apps, control is the last thing we have over the implementation, unless of course, we are secretly also an Android/iOS developer, in which case this article might not be for you.
Also, to set the right expectations here, in this article, I write about mobile app analytics from the perspective of someone using Firebase. This doesn’t represent the full ecosystem of mobile app development or mobile app analytics, just a part of it.
So, if you are just like how I was a year ago, just trying to figure out what can you actively do to be able to accomplish everything you are set to do with your mobile app or your client’s mobile app that uses Firebase, I hope this article will give you a good introduction into the mobile app ecosystem.
PS: If I forgot to cover something, please let me know in the comments and I will take care of it.
Table of Contents
Mobile App Market
The mobile app economy is now a half-a-trillion-dollar market, with nearly $1.5 billion in spending each day in 2023 across app store spend and mobile ad spend. This included $362 billion in mobile ad spend, an 8% YoY increase.
According to Data.AI State of Mobile Report 2024, app usage is at an all-time high. While in-game spending seems to be affected by inflation, apps stand resilient. In fact, across the top 10 markets in this report, the weighted average of time spent on mobile surpasses 5 hours in 2023, up 2% from the previous year. And after declining 2% YoY in 2022, global consumer spending bounced back 4%.
The shift towards mobile-first strategies has been a fundamental change in how businesses connect with their audiences for a long time. Even though many markets or businesses struggle to adapt to mobile channels still. Embracing this shift requires a deep dive into mobile app analytics foundations, understanding the ecosystem, the caveats, and well, the opportunities.
The Mobile App Ecosystem: Mobile App Types
Generally, there are 3-4 types of apps you will bump into: web apps, progressive web apps (PWAs), and Native Apps. And potentially hybrid apps. Of course, there are other types of apps out there like utility apps, cross-platform apps, business apps, etc. but we won’t be covering these in this article.
Web apps are accessible via web browsers and don’t require downloading from app stores. They’re built using HTML, CSS, and JavaScript but may lack the functionality and speed of their counterparts.
PWAs offer a hybrid experience with modern web capabilities to provide an app-like user experience. They can work offline, send push notifications, and access device hardware through a browser, standing between web apps and native apps in functionality.
Native apps are developed for specific platforms, generally Android and iOS, and installed directly on a device, delivering the highest performance, best user experience (ideally), and access to all device features. However, they require separate development for each platform, increasing complexity and costs.
Tracking user interactions and optimizing user experience makes the integration of analytics SDKs like Firebase essential and it varies based on platform-specific permissions and configurations. Notably, iOS’s privacy measures, such as the App Tracking Transparency framework, require obtaining user consent differently than on Android, impacting how analytics data can be collected.
In addition to web apps, PWAs, and native apps, hybrid apps also are popular among developers and businesses due to their cost-effectiveness and the ability to reach a wider audience without the to have separate codebases for each platform.
Hybrid apps are essentially a blend of native and web app technologies, allowing developers to write code once and deploy it across multiple platforms, including iOS and Android. This is achieved by embedding web content within a native container, enabling the app to access device features while still offering the flexibility and speed of web app development.
Tools like Apache Cordova, Ionic, or the most modern option ReactNative, are commonly used to develop these apps, providing a framework that bridges web technology with native device functionality. While hybrid apps can offer a compromise between the speed of development and access to device features, they may sometimes lag behind native apps in terms of performance and user experience.
Mobile App Privacy Considerations
Talking to Aurelie Pols, DPO, Privacy engineer, European Center for Privacy & Cybersecurity (ECPC) board member, about Apple’s App Tracking Transparency (ATT) initiative and its implications, especially in light of recent privacy concerns, the trigger seems to be a complaint from noyb about Apple’s use of IDFA for tracking, which kind of pushed Apple to adopt a stance similar to the old “Do Not Track” but with a new twist according to Aurelie. They’ve made it clear that apps bypassing ATT to use IDFA risk being removed from the App Store, though there’s not much evidence about actual enforcement or apps being kicked out.
Interestingly, Aurelie mentions a shift towards using IDFV as an alternative, raising questions about Apple’s genuine commitment to privacy despite their public declarations.
Then there’s the Digital Markets Act (DMA), seemingly a push towards improving privacy and competition, partly motivated by the challenges in enforcing GDPR, particularly with the Irish DPC. Aurelie mentions also that Apple’s introduction of Privacy Manifests is a step in the right direction, but it’s just part of a larger, more complex picture that includes balancing user experience with privacy education.
Shifting gears to Google, their Consent Mode V2 has raised eyebrows in terms of compliance with ePrivacy regulations. And while Google’s dominance with Chrome is well-discussed, the mobile apps market share dynamics present a different picture. Are apps flying under the radar?
Lastly, Google’s Privacy Sandbox is under review by the UK’s Competition and Markets Authority, but with the UK outside the EEA, the impact and relevance of their findings on European legislation remain to be seen.
Aurelie describes the Google Privacy Sandbox as: “Google seems to have put everything in their “Privacy Sandbox”, which reminds me of how we depicted Covid: this big ball with tons of spikes?” which seriously made me giggle a lot.
Today, it’s about differential privacy and then some other techniques Matt Gershoff talked about like k-anonymity, t-closeness, etc at Superweek. It’s not very different than stating some years ago that the data was anonymous because it was hashed; it doesn’t support fundamental rights, just makes the data processing somewhat justifiable and certainly less easy to understand. Opacity is certainly on the rise, Aurelie adds.
Mobile App Stores
In terms of where apps are distributed after being built, Google Play Store and App Store are the primary platforms due to their big user base, security, and app diversity.
These platforms are essential for app distribution, offering good monetization opportunities, especially the App Store, which is often associated with higher revenue per user. The Google Play Store, on the other hand, is known for its big reach of Android devices and a relatively straightforward app submission process.
Beyond these main two app stores, a variety of alternative app stores offer unique advantages, targeting niche audiences, providing different monetization strategies, or presenting fewer restrictions and lower fees. I randomly started wondering about what else was out there a while ago when one of my clients decided to build toward a PWA because of the big costs with their native app and the revenue-sharing model on App Store.
There are alternative stores like Amazon App Store, which integrates with Amazon’s ecosystem, also manufacturer-specific stores like Samsung Galaxy Apps and Huawei’s AppGallery that cater to users of those devices with tailored app selections. TBH, I never used the device-based stores ever, but I am pretty sure there must be users that prefer them.
Also, there are some community-driven open-source app stores like Aptoide, an open-source platform with a community-driven approach, or F-Droid which focuses on free and open-source software, appealing to privacy-conscious users and developers.
DISCLAIMER: This is not a recommendation of using any alternative open-source app stores, this is simply informative and should be treated as such.
Every time you decide to explore any other app stores and tools you have to discuss it with your legal teams and other relevant stakeholders in your organization to make an informed decision.
For sure, marketers knowing there are other app store alternatives can also present opportunities to reach specific demographics, experiment with app features, or capitalize on less crowded markets for better visibility. But as with anything in digital marketing, especially when we are talking distribution when considering these platforms, it’s important to analyze their policies, the demographic they serve, and the potential for exposure. The same goes for security standards, UX, and payment options.
I plan to do a bigger dive into app stores, how they calculate ratings, revenue sharing models, and other things to consider when you are running marketing, experimentation, or building a mobile app.
What are SDKs and why do we care about them?
SDKs (Software Development Kits) are pre-packaged sets of development tools that allow developers to create applications for a specific platform, system, or programming language. They often include libraries, documentation, code samples, processes, and guides that facilitate the development of applications with specific features or for certain platforms without having to code everything from scratch.
Main Challenges with SDKs
Incorporating SDKs into mobile apps can be a very challenging process, yet it’s a process that, when managed well, can significantly improve your app’s capabilities. This requires careful consideration, not just for the initial setup but also for ensuring seamless functionality across various platforms.
The complexity is not related to the integration per se, but more to balancing multiple SDKs to work without conflict, ensuring your app remains lean and efficient. Performance is a key concern; SDKs can impact your app’s speed and battery usage, which means prioritizing optimization to keep user experience positive is key.
Compatibility is another important area. With many types of devices, OS, and app versions in use, making sure the SDK functions correctly across all possible combinations is essential for maintaining a broader user base. i.e. if you have a global app and a region uses an older app version while another uses the latest app version, and each % of the region is spread between iOS and Android, you want to make sure that the SDK functions properly across app versions, OS, and regions.
This means that the product teams and devs need to stay on top of updates and testing extensively.
Maybe this is the reason why when we come up with test ideas they are not so open to listen to us, because this is a stressful thing they need to deal with. One of many. Just saying.
Privacy and security should be at the forefront of your concerns, making it essential to choose SDKs that comply with regulations like GDPR or CCPA. As SDKs can handle sensitive user data, adhering to these regulations not only protects your users but also builds trust with your brand. At the same time, it’s important HOW you use these SDKs and your knowledge and your organization’s knowledge about privacy.
Also, relying on third-party SDKs depends on their stability, support, and longevity. Changes in their terms of service, pricing, or even discontinuation can directly affect your app’s functionality and user experience. Addressing these challenges effectively requires a blend of technical acumen, strategic planning, and ongoing vigilance.
No matter your role in the team, prioritizing performance, security, and a great user experience should be the main goal.
Even if we are not the ones actively having to “deal” with these things, it’s important to be aware of them so it also balances our expectations from devs a bit better, we know we like to blame them for everything.
Firebase SDK
In mobile apps, tracking is implemented directly in the app’s codebase, without a traditional tag manager.
(Yes, I am aware you can do some hacky stuff with Google Tag Manager, but that doesn’t mean you should.)
Developers use SDKs provided by analytics platforms like Firebase.
Yes, there are many other SDK options out there, and of course, it will be a business decision which ones should be used, but in this article, I will be focusing on writing about Firebase SDK. And yes, you can use multiple SDKs.
For starters, developers will add the Firebase SDK to the app project. An app project refers to the entire collection of files, resources, source code, and configuration settings that make up a mobile application.
It includes everything needed to compile the app into an executable program for iOS, Android, or other platforms. This project structure varies between platforms (i.e., Xcode projects for iOS, Android Studio projects for Android) but generally includes source code (in Swift for iOS, Kotlin, or Java for Android), assets (like images and fonts), and configuration files.
Here are 2 examples of how one gets started with Firebase for a web app or a native iOS app.
Caveat: Only sharing these videos so you see how it works under the hood, none of us are expected to know how to do this or do this, but it’s important to have the context to be able to understand how to structure your work and requests.
Out of all the tools Google I’ve ever used, Firebase is my favorite. (For sure not thinking here about all the GCP products). Firebase provides a great suite of tools for mobile app development and analytics.
Before GA4 came around, marketers were using Firebase Analytics (well, I call it that, but the actual name is Google Analytics for Firebase) to track predefined/custom events to gain insights into user behavior and app performance across both iOS and Android platforms.
The Firebase SDK was and still is integral to this process, facilitating the collection of valuable data for analytics. Again, the SDK integration and the tracking implementation for mobile apps are normally done by developers. And they should be done by developers.
This process is platform-specific, requiring separate setups for iOS and Android apps due to differences in development environments, programming languages, and platform guidelines. Developers integrate the analytics SDKs into the app’s codebase, configure the tracking of events, and set up any necessary user properties or custom metrics. This requires familiarity with the programming languages and development tools specific to each platform which regularly is missing from us marketers, product folks, or even analysts, and that is OK.
While developers handle the tracking implementation, our role should be contributing to defining what data should be tracked, how it should be interpreted, and how insights drawn from the data can inform business decisions and marketing strategies. Analysts should work closely with developers to specify the events, user properties, and metrics that are most relevant to the app’s objectives.
The success of the marketer or analyst in this constellation is unrelated to their coding skills. Having general knowledge about how things work is essential to their ability to build a solid relationship with their product and developer colleagues.
The Evolution of Firebase with GA4
Google Analytics 4 is a tool that was built by merging the capabilities of Universal Analytics and Google Analytics for Firebase.
This alignment means:
- For native apps, event tracking via the app’s codebase remains fundamental, with Firebase serving as the bridge to GA4 analytics.
- Both platforms treat user interactions as events, simplifying cross-platform analytics between web and mobile.
- GA4 offers advanced analysis tools like funnel and path analysis, leveraging the event-based data for deeper insights.
The introduction of Google Analytics 4 (GA4) has brought changes (I don’t want to say improvements yet) to how we track app behavior. By adopting an event-based model, similar to Firebase, tracking for mobile apps using Firebase integrates directly with GA4, expanding analytics capabilities. This means that we use the GA4 interface to view our app behavior data and not the Firebase console anymore.
This integration aims to align analytics across web and app platforms, enabling more cohesive and comprehensive data analysis strategies.
Keep in mind, that GA4 doesn’t change the fundamental concerns about using tag management tools like Google Tag Manager (GTM) for native mobile apps.
While GTM can add flexibility and ease of management for web apps and PWAs by allowing marketers to deploy and update tracking codes without needing to alter the codebase directly, the situation with native mobile apps is different due to the complexity of their ecosystems.
Direct implementation in the app’s codebase, particularly through Firebase for mobile apps, remains the most robust tracking method, ensuring stability and performance. GA4’s event-based model complements this by offering advanced analytics capabilities but doesn’t eliminate the need for thoughtful consideration of how best to implement tracking in native apps.
It’s important to consider that you can use solely GA4 as an interface for your app behavior data. Once you link your Firebase project to your property, you will be able to see your app data in the GA4 reports.
By now we all should be accustomed to GA4, and despite the many caveats surrounding tracking app behavior data, GA4 provides a better interface and better analysis opportunities than what was available in the Firebase console.
Even if there might be some apps using older versions of Firebase, nowadays it’s not possible to create an analytics setup, in the context of Firebase without using GA4. *thanks Simo*
Every Change In Your Tracking Might Require A New App Release
In practice, while the core event tracking setup does require coding and potentially an app release for significant changes, tools like Firebase Remote Config (A/B Testing) and Google Tag Manager may offer some flexibility in some specific cases.
These tools can modify how analytics work to a degree or change app behavior based on analytics data without needing to push a new app version immediately. However, for substantial changes in what or how data is collected, a new release would be necessary to implement these updates in the app’s codebase.
When a new app release might be needed:
- If you decide tracking a new user action or interaction is necessary (custom event).
- Changing what data is collected by an event (i.e. adding new parameters to provide more detail on user interactions).
- If the logic behind when an event is triggered needs alteration (for example, changing an event to fire at a different point in the user journey).
When a new app release might not be needed:
- Some changes, like modifying user property definitions or adjusting session timeout lengths, might be done via the Firebase console or GA4 interface. (pls don’t do it.)
- Marking an event as a conversion or modifying events in the interface (not a fan).
- Firebase offers features like Remote Config which can allow for some level of dynamic modification of how events are recorded or what content is shown to users based on analytics data.
- Changes to how data is visualized or reported in GA4 or other analytics platforms.
For each of these scenarios, you need to make sure you properly consult with your digital analysts and developer colleagues to choose the best option. Don’t be a hero haha.
BigQuery Export
Just like with GA4, Firebase’s BigQuery export feature allows you to export your app’s event data directly into BigQuery. This enables advanced analysis and can be used for various purposes like creating custom dashboards, running complex queries, and integrating with other data sources.
Here’s how it generally works:
- You link your Firebase project to BigQuery from the Firebase console. During setup, you can choose which Firebase apps to link and whether to export historical data.
- Once linked, Firebase automatically exports event data to BigQuery. Data is exported daily, and you also get intraday tables for more timely analysis.
- The data exported includes all the event parameters and user properties that you’re logging into your Firebase app. The structure is designed to be easy to query with SQL in BigQuery, with separate tables for different types of data (i.e., events, and user properties).
- In BigQuery, you can run SQL queries on your Firebase data, join it with other datasets, and use it as the basis for reporting and analysis tools.
- Firebase offers a daily free quota for BigQuery exports, but beyond that, BigQuery’s standard pricing applies. It’s important to monitor usage and costs, especially if you have a large volume of data.
If you want to explore this deeper, find the documentation here.
While both GA4 and Firebase share a similar event-based schema in a nested format, they might have particularities that are different because Firebase tracks app interactions, and A/B testing audiences from using the RemoteConfig feature or In-App messaging campaigns while GA4 focuses on web + app.
Also have to mention here that the naming convention you use across devices and platforms matters, for both events and event parameters. I have some horror stories about this, but maybe for another time and place 😂
Team Collaboration
Maybe the most important thing to consider when you are taking on a mobile app project is team collaboration.
As mentioned at the beginning of the article your success as a technical marketer, CRO, product, analyst, or whatever your role might be is 100% dependent on how you work with your teammates, especially the developers in this context.
If we have a better understanding of their load which most of the time doesn’t only consist of writing code or building a new feature, but actually watching over app performance, security risks, improvements, crashes, and errors and communicating these back to the team while fixing them on the fly, we will try to adapt our expectations from them and actively put in effort to meet them where they are at vs. us trying to make them accept our ideas and requests because we think it’s the right way to go.
Together with 14 other experts, I covered the topic of solving team fragmentation in mobile app development in this article.
Conclusions
Investing time in learning the mobile app ecosystem is not a one-time effort but a continuous loop of learning, applying, and iterating. We need to use our positions as marketers or analysts to make active efforts to foster a culture of continuous improvement, driving both app performance and user satisfaction forward.
In my future article from this series, we’ll take a closer look at app stores (Google Play and App Store) and how the insights we can gather from there can complement what we get from GA4. We’ll explore how app ratings are calculated across app stores, and how we can use other data points available in the stores console to understand app performance better.
Keep an eye out for our next piece, and if you have any feedback feel free to drop it below.
Of course, sharing is caring so if this article was helpful to you in any way, don’t forget to share it with your friends or colleagues.
Hi Juliana! Thank you for your work in this field, namely with your blog posts and podcast with Simo! About the article I have one suggestion to make, for what is worth 🙂 and a doubt. Suggestion: Can you name examples of webapps, pwa to enrich the article, maybe? Doubt: I think it is not necessary to link Firebase to BigQuery to have the raw data in it. Or better saying, it depends on the process and how we set up the things. For example, when we create a Firebase project for an app and we want to see data in GA4, we have to connect that Firebase project to GA4, to have a data stream for that app. And if the GA4 is already connected with BigQuery, there is no need to connect the Firebase to BigQuery also. Thank you!
Hey Joao, sure you can skip the firebase bq export if you are not interested in specific data that a firebase export can give you which is raw event data coming from other firebase products like: Cloud Messaging, Crashlytics, Performance Monitoring, and Remote Config. GA4 doesn’t collect that specific Firebase data, so even if you have a product link firebase <> GA4 and the regular BQ export, that data I mentioned above, will not be a part of it, then is when the firebase export makes sense to exist.
Hey Juliana! Thank you very much for the clarification. I am clarified. I told that it was not necessary because in fact the company where I work has a low digital maturity level and therefore they only are interested in metrics from GA4 :(. But maybe I will do the link, 🙂
Hey Juliana! Sorry I forgot something.
The company has only one Firebase project config where there are the website, app 1, app 2, app 3….Company was advised by the partner to do the config like that.
In GA4 BigQuery Linking the company has all data streams setup in it (website, app1, app2, app3…..).
Linking Firebase to get that metrics you mentioned, will duplicate data from the app1, app2….? Thank you and sorry for the double comment!