This article is part of the weekly learning pathways we’re releasing leading up to Firebase Summit. See the full pathway and register for the summit here.
Apps and games have evolved rapidly in recent years, and user expectations for high performing apps have increased right alongside them. Today’s users don’t just demand speed and performance — they reward it. A 2019 study found that retail sites saw 8% more conversions when they reduced their mobile site load times by one-tenth of a second. And travel sites boosted conversions by just over 10%.
Pinpointing an app’s performance issues can be challenging, especially when the culprit is slow network requests from your dependencies or even your own server.
This is where network analysis from Firebase Performance Monitoring can help. Firebase Performance Monitoring helps you understand your app’s performance from the user’s perspective in near real time. You can analyze the performance of each module of your app by monitoring response times, success rates, and payload sizes of your most critical network requests.
Let’s look at how we were able to spot performance pitfalls in BingoBlast - Firebase's very own demo app.
Out-of-the-box, Firebase Performance Monitoring measures each network request that is sent from your app. To surface the most important trends from the vast number of URLs, Firebase automatically aggregates data for similar network requests to representative URL patterns. Furthermore, this aggregation removes all PII (Personal Identifiable Information) such as home address, username, and password so that developers don't need to worry about leaking user information.
Firebase displays all URL patterns (including custom URL patterns) and their aggregated data in the Network requests subtab of the traces table, which is the lower half of the Performance dashboard.
BingoBlast Auto Aggregate Data.
By just integrating Firebase Performance Monitoring into your app, you can quickly see the slowest network requests your app is making and how that performance has changed over time.
For BingoBlast, our traces table shows that some network requests have substantial slowdowns in their response time over the past several days, signaling that there might already be issues needing our attention.
Although Firebase does a great job at automatically generating URL patterns, at times the specific pattern you're interested in might be hidden under an automated pattern. In those situations, you can create custom URL patterns to monitor specific URL patterns that Firebase isn't capturing with its derived automatic URL pattern matching.
Custom URL patterns let you specify the patterns that will take precedence over the automatic URL patterns. With custom URL patterns, you can:
A custom URL pattern consists of the hostname followed by path segments. Subdomains and path segments can be replaced with a * to represent matching with any string.
*
If a request's URL matches more than one custom URL pattern, Firebase Performance Monitoring maps the request to the most specific custom URL pattern based on left-to-right specificity. See the documentation for the full details and syntax available.
For example, suppose you configure two custom URL patterns:
example.com/books/* example.com/*/dog
A request to example.com/books/dog will match against example.com/books/* because book is more specific than *.
example.com/books/dog
example.com/books/*
book
To show how custom URL patterns can be helpful, let's look closer at the data from BingoBlast. Let's say that we're worried that an important configuration API request (api.redhotlabs.com/1.2/config.get) might be causing issues in BingoBlast. But, we're unable to find it in our list of automatic network URL patterns. In this case, Firebase Performance Monitoring has aggregated the configuration API request along with a few other API requests into the api.redhotlabs.com/1.2/* URL pattern.
api.redhotlabs.com/1.2/config.get
api.redhotlabs.com/1.2/*
To get better insight into any performance issues this API call might be causing, let's use a custom URL pattern for this specific request.
To do this, we just click the Create custom URL pattern button in the traces table, then enter api.redhotlabs.com/1.2/config.get into the dialog. After the new pattern is created, the traces table will start displaying the new custom URL pattern based on new data.
Creating a new custom URL pattern.
Since this is an important API request and we want to track our improvements to it over time, we can add metrics (like response time) for this new custom URL pattern to our metrics board at the top of the Performance dashboard page. These metrics cards are a great way to provide a quick overview of your most important metrics.
Pin your most important metrics to the top of your dashboard.
With api.redhotlabs.com/1.2/config.get extracted as its own URL pattern, it's easier to monitor for any unwanted changes in the performance of these requests. We can then take action, like removing the request from the app's critical path or recommending improvements for the backend implementation.
Newly added api.redhotlabs.com/1.2/config.get custom URL pattern.
On the other hand, we sometimes want to group related URLs into a single URL pattern. In BingoBlast, we have included a library that plays a short video. However, we noticed that our traces table is showing many separate URL patterns to different googlevideo.com subdomains.
googlevideo.com
Overly precise automated URL patterns for googlevideo.com subdomains.
Since we're more concerned about the overall performance of the video requests, as opposed to which specific subdomain they're from, we can create a custom URL pattern *.googlevideo.com/** to aggregate all these URLs into one pattern. This makes it easy to understand the performance for the video and, as a bonus, makes our traces table more tidy!
*.googlevideo.com/**
Newly aggregated data for the custom URL pattern for googlevideo.com subdomains.
Firebase Performance Monitoring provides a wealth of data on how your users experience your app. By leveraging Firebase’s out-of-the-box automatic URL patterns and tailoring your dashboard with custom URL patterns you’re most interested in, you can easily pinpoint slow performance areas in your apps and quickly boost your app’s responsiveness.
View the full learning pathway for additional codelabs, videos and articles on creating fast and stable apps. And don’t forget to register for Firebase Summit, happening November 10th to learn how Firebase can help you accelerate your app development, release with confidence, and scale with ease!
This is part of a series of articles about app quality. Here is an overview of all the other articles:
Apps and games have evolved rapidly in recent years, and user expectations for high performance have increased right alongside them. Today’s users don’t just demand speed and performance — they reward it. A 2019 study found that retail sites saw 8% more conversions when they reduced their mobile site load times by one-tenth of a second. And travel sites boosted conversions by just over 10%.
As you reach more users across different devices, locations, OS versions, and networks, optimizing performance becomes even more of a moving target. To understand the unique context behind performance issues, you need actionable insights about your app performance from a user's perspective. With performance data that allows you to spend less time putting out fires, you can devote more time to creating delightful experiences knowing that no bug or glitch will slip through the cracks.
With performance data that allows you to spend less time putting out fires, you can devote more time to creating delightful experiences knowing that no bug or glitch will slip through the cracks.
In this article, we’ll explore some Firebase Performance Monitoring features that can help you keep an eye on your app’s performance and understand the experience from a user's point of view.
Real-time app performance metrics
Releasing a new feature that performs well for every user — no matter their location, device, or network speed — can be challenging if you don’t have the timely information you need to gauge performance across a range of variables. When poor performance and low app ratings occur, you need clear insights to deliver an experience worthy of a 5-star review.
Firebase Performance Monitoring processes your app performance data in real time so you can monitor new releases during development and post-launch. For instance, you can gather performance data from Firebase Emulators or virtual devices on Firebase Test Lab to test your app locally before launch. And after launch, you can get insights about metrics related to screen rendering and network requests to learn how your app is performing among different user segments.
By learning how your app responds for different groups of users, you can quickly take action to fix any errors and ensure users won’t delete your app to find one that works better on their device.
Performance Monitoring dashboard highlighting real-time metrics
Customizable Metrics Board
In the first blog post of this series, we highlighted some standard app performance metrics to keep top-of-mind, such as app start-up time, screen rendering performance, and network performance. However, sometimes the influx of real-time data after a big release can feel overwhelming, and identifying where you should focus and take action can be a daunting task.
With the revamped Performance Monitoring dashboard, you can customize your app performance metrics board to highlight the most important metrics for your app. For example, if you’re releasing updates on a shopping app, you can select and track slow-rendering frames on the checkout screens. This helps ensure your customers are enjoying a seamless experience from start to finish. You can also break down your key metrics by country, device, app versions, and OS level for a deeper dive into your performance data.
By learning how quickly your app responds for different groups of users, you can take action to fix latency issues and ensure users won’t delete your app to find one that works better on their device.
Additionally, Performance Monitoring allows you to implement custom code traces, which help monitor the performance of your app between two points in time. You can also create your own traces to capture performance data associated with specific code in your app. For example, you could use custom code traces to measure how long it takes your app to load a set of images and make sure the graphics aren’t causing too much lag.
Compare performance between app versions
Retaining a diverse user base isn’t easy without understanding how specific user segments are engaging with your app — especially when their experience isn’t up to par. To make sure every new release performs at its best once it reaches a large number of users, you can use the new Performance Monitoring dashboard to identify app performance changes that need immediate attention.
The metrics board enables metric performance tracking across versions. If your latest release calls a new API at start-up, you can track latencies in app start time between the latest version of your app and previous versions. The traces table is especially helpful to understand how your traces are trending across selected time ranges. That means you no longer have to wait for app store reviews or support tickets to know when your app performance is lagging.
Performance Monitoring traces table
Track trends, regressions, and severe issues
One of the most important ways to grow and engage your audience is by constantly releasing new features and updates to your app. But any code or configuration changes to your app or any of its many dependencies carry a risk of degrading your app’s performance or causing issues with user experience. For example, if your e-commerce app makes dozens of API calls to fetch your catalog and product details, users might experience frustrating lags during their shopping experience.
By tracking trends and regressions with Performance Monitoring, you can quickly act on the most critical issues and get ahead of low ratings on the app store.
Improve user retention with Performance Monitoring
GameNexa Studios, an India-based app developer, seized an opportunity to invest in improving its app quality when their ad sales were disrupted by COVID-19. By combining Firebase Performance Monitoring and Firebase Crashlytics, the team gained actionable insights about its user base and improved their most popular app’s experience across the board. And by reducing the number of performance issues affecting its users, GameNexa ended up boosting both user retention and session duration, and increased in-app purchases by 2.5X.
Stay ahead of app stability and performance issues
To deliver the fast, consistent experience app that users expect, you need a strategy backed by tools that help you act quickly and fix significant issues on the fly. With detailed, actionable data and insights from Firebase, app developers and product managers can make smarter decisions before launch, tackle urgent issues swiftly after releasing an update, and quickly and confidently roll out new features that keep users coming back.
To get started with Firebase Performance Monitoring, integrate the Performance Monitoring SDK into your app and identify the metrics that matter most to your app’s success.
First impressions matter to app users. Even the most well-designed apps can fall flat if they don’t consistently deliver a crash-free experience.
Picture one of your app users getting ready to unwind after work. They grab a snack, get comfortable on the couch, and open their favorite gaming app … and it crashes. Or perhaps it freezes every time they’re on the brink of reaching the next level. These unstable experiences can frustrate users and may result in them uninstalling or leaving a scathing review on the app store.
In fact, quality issues are the most common reason for early app deletion. One in five users (19%) will uninstall an app due to technical errors or crashes.1
There are a handful of reasons for app crashes. A user’s device may have low memory or a weak chipset, or it may be running an earlier OS version. Alternatively, the app’s code may be filled with bugs. More importantly, as you add new features and acquire more users on different devices, you’re likely to encounter a wider variety of crashes behind the scenes.
Manually tracking, organizing, and fixing crashes can be a complex and time-consuming challenge. And even if you collect every bit of crash data, it can still be unclear what’s causing your app to crash or which errors are impacting the most users. That’s where having the right crash reporting tools makes all the difference.
Continually improving your app and launching new features is one of the best ways to increase retention and engage new and existing users. However, as your user base grows, splitting your time between releasing new features and monitoring the stability of new releases becomes a bit of a conundrum.
Real-time crash reporting in Firebase Crashlytics allows you to quickly triage and troubleshoot any bugs in your app by gathering and grouping crashes based on where they occurred in your app’s code. Groups of crashes are listed in order of frequency and degree of impact on users, making it easier to identify which issues to tackle and providing you with more time to build features that keep users engaged.
Crash report data displayed in the Firebase Crashlytics dashboard
To go even deeper into your crash data, you can enable BigQuery streaming export to identify prevalent issues and understand trends over time — such as which OS versions or specific devices are causing the most crashes. This helps you visualize your crash data and monitor issues that trigger alerts and custom workflows. Enabling BigQuery streaming also gives you the ability to analyze your data with BigQuery SQL, export it to another cloud provider, and use Google Data Studio to create custom dashboards and visualizations of crash trends.
Crashlytics integrated with BigQuery
For an app like Spotify — with more than 65 teams maintaining millions of lines of code per platform and launching new updates every week — moving fast and at scale is essential. To reduce stress on its development team before each launch, Spotify switched from manually tracking crashes every day to automating their release process using Crashlytics, primarily with BigQuery. Rather than having the team’s release manager on call to monitor each crash, Spotify now uses Crashlytics to track crashes for alpha and beta builds, set rules for incoming tickets, and assign tickets to the right teams.
Deliveroo, a food delivery company based in the U.K., similarly adopted Crashlytics and BigQuery to get ahead of crashes before they reach a certain threshold while tracking and analyzing performance data of each new release in real time. With the ability to create customized reports and separate errors, the development team drastically cut down on the time spent troubleshooting and reproducing app issues — and crash-free sessions increased from 99.35% to more than 99.7%.
Crashes don’t just turn away your existing app users — negative app reviews caused by an unstable session can also impact your ability to acquire new users. That’s why it’s crucial to know when and where crashes are happening.
Crashlytics velocity alerts notify you when a particular crash starts spiking so you can respond before the bug impacts more users. Velocity alerts are also configurable, giving you the power to set thresholds that determine when alerts should fire based on the percentage of user sessions being affected.
For instance, velocity alerts can detect major bugs during the rollout of a new release of your app or quickly alert you if there’s an issue impacting a large percentage of users. Velocity alerts will send an email or message on Slack, Jira, or PagerDuty, depending on which third-party integration you have enabled with your project.
Velocity alert settings in the Firebase Console
That’s exactly how Swiggy — one of India’s largest food delivery services — simultaneously monitors every app issue while focusing on the most significant ones first. Swiggy’s development team connected Crashlytics velocity alerts to PagerDuty and Jira to notify its on-call engineer whenever critical crashes reach a certain threshold. This allowed Swiggy to keep shipping fast with the confidence that they will be notified about high-priority crashes and low-priority crashes in the right manner.
Quickly identifying prevalent crashes is just one piece of the puzzle. By getting to the root cause, you can mitigate risk and avoid frustrating your app users by ensuring those crashes don’t happen again.
Crashlytics custom logs and keys record the events a user experienced during their session by tracking the state and sequence of their app. This gives you an actionable snapshot of what the user was doing leading up to the moment your app crashed. You can also define custom keys such as “installation_source”, “network,” and “language” to pinpoint exactly what happened before each crash — like whether a user installed your app on the Play Store or if they were connected to Wi-Fi — and reduce the time it takes to reproduce it.
And by using Crashlytics with Google Analytics, you can automatically capture predefined Google Analytics events — known as breadcrumbs — which enhances the data captured with custom logs and provides more detailed information on what caused a crash.
Breadcrumbs in Google Analytics
For mobile game publishers like Tapps Games, delivering a stable and immersive experience is crucial for keeping gamers engaged. Previously, Tapps would manually search through user reviews for negative feedback and then try to reproduce the crashes that users described. With Crashlytics' velocity alerts, the team was immediately notified when severe crashes were on the rise. After digging into the data, they realized an update to their Vlogger Go Viral game's video creation process and a simultaneous community player event was leading to consistent crashes.
Tapps Games’ development team jumped on a fix that helped boost their Google Play store rating from 3.9 to 4.7 and increased their crash-free users from 94.6% to 99.8%.
To grow your audience, keep users engaged, and spark positive reviews and recommendations, app stability needs to be a key focus area. Installing the Firebase Crashlytics SDK in your app gives you the tools and information you need to stay on top of critical issues.
In the third and final series of our guide, we’ll spotlight a set of tools you can use alongside Firebase Crashlytics to understand how your app is performing from a user's point of view.
Sources
Posted by the Firebase team
This is an introduction to a three part blog post series on app quality exploring how to unlock app stability and app performance for the optimal app experience. Find links to the other articles at the end of this blog post.
Stability and performance are the core of every successful app. Fast, crash-free experiences encourage users to stay engaged and drive positive reviews. That’s why keeping a close eye on your app’s stability is crucial for competing in today’s thriving app marketplace.
Users expect the best experience every time they interact with an app. And if bugs or latency issues get in the way, they’ll be quick to find a better option. Research has shown 88% of app users will abandon apps based on bugs and glitches. And within that group, 51% of users said they’d abandon an app completely if they experienced one or more bugs per day.
Not only is quality important to retaining users, but it’s important for attracting new users as well. If a large percentage of users are frustrated and your app store listing is filled with negative feedback about performance issues, you might have trouble acquiring new users.
In fact, 54% of users who left a 1-star review in the Play Store mentioned app stability and bugs.1
It’s no wonder that stability and performance are top areas of focus for developers. Our own Firebase research shows that a top need for developers is to obtain the tools and services that help them debug technical issues, trace issues back to changes in their code, and detect technical performance issues.
A large portion of the pre-launch development for a new app is spent squashing bugs and testing for potential issues. But getting your app ready for launch is just the first step — once it’s out in the world, maintaining your app’s health becomes an ongoing process as you create new features and iterate on previous versions.
It's important to remember that app quality isn’t one-size-fits-all. Depending on the type of app and how you define success, you’ll want to prioritize the factors that are crucial for your business. With Firebase’s customized reporting tools and real-time insights, you can hone in on the metrics that matter most.
For instance, in a productivity app — where users want a clean, simple interface and the ability to use it on the go — slow response time and high error rates will cause many users to drop off. Conversely, users might tolerate a bit of lag between menu screens in a food delivery app. But if it crashes every time they reach the checkout screen, your in-app revenue is sure to suffer.
No matter what type of app you have, here are a few of the most notable quality metrics that successful apps get right:
Monitoring metrics like these can mean the difference between driving downloads and retaining satisfied users versus seeing churn and negative reviews from dissatisfied users.
To stay ahead in such a dynamic app ecosystem, you need to know precisely where stability and performance issues occur in your app. In the next two blog posts of this series, we’ll spotlight two Firebase products that can help you detect crashes in your app and gather actionable insight about your app’s performance from a user’s perspective.
It's amazing to see you using Crashlytics on so many different Apple products – and even wanting to expand that usage! We have always focused on making Crashlytics the best crash reporter on iOS, from our user-friendly onboarding process, to our lightweight SDK. So we’ve made some updates to ensure you can run the Crashlytics SDK seamlessly on all Apple consumer hardware.
In December 2020, we released full support for Apple Silicon Macs running iOS or macOS apps. This means any of the following configurations running on Apple Silicon will work with Crashlytics:
To make it easier to see crashes on these platforms, we added support for filtering in the Firebase console, using the Device filter. We're already working on improving this experience, so stay tuned!
With the introduction of iOS 14, the number of system libraries and libraries used by apps has increased. These libraries can increase startup time as Crashlytics lists the libraries loaded into the app for symbolicating crash reports. In version 7.5.0 of the Crashlytics SDK, we shipped a change to remove this bottleneck, significantly improving the customer experience. For apps with this version of the SDK, we’ve observed a median startup time of about 14 milliseconds, a 75% reduction!
In addition, we’ve improved the speed of our client-side build tools, especially for apps with large binary and dSYM files. This tool processes dSYMs on your build machine before upload to ensure it matches your build environment and Xcode version as closely as possible. We observed the symbol conversion time for a 600 MB dSYM improved from about 12 minutes to 45 seconds. This will help speed up CI builds for your apps and make it possible to rapidly test crashes locally.
We’ve also invested in making sure we fully support App Clips. Crashlytics continues to be a lightweight crash reporter in terms of binary size, so you shouldn’t have to commit much of your App Clip’s 10 MB limit to the Crashlytics installation.
Recently, the community pitched in to get the Crashlytics SDK running on watchOS, adding support for common crashes and non-fatals. Since watchOS is continuing to build out better support for responding to crashes, we’re always happy to accept contributions to improve this!
Open sourcing the Crashlytics SDK as part of the move to Firebase has brought huge benefits. The community has been integral in determining the popularity of various features, and we want to thank folks who have reached out on GitHub, Firebase Support, and other channels to outline their use cases for Crashlytics. We want to especially thank members of the community who have made code changes to improve the SDK directly.
We are continually investing in support for Apple apps, and there’s more coming to help developers diagnose stability issues with their apps. We’re proud of the investments we’ve made here and are excited to continue supporting the Apple app ecosystem.
Last year we announced our investment in making Firebase libraries more Kotlin-friendly with Firebase Kotlin extension (KTX) libraries. Since then we have seen increasing interest for Kotlin within the Firebase community. In this blog post, we’ll go over how developing with Kotlin can lead to fewer crashes; and how you can monitor your app’s stability with Firebase Crashlytics once your app has been released.
Users expect to have a seamless experience every time they use your app. Crashes can cause churn and poor reviews, and quality issues are one of the main causes of early app deletion. Android apps built with Kotlin have 20% fewer crashes, which is one of the reasons that over 70% of the Top 1000 apps on the Play store have adopted Kotlin. Using Kotlin allows you to reduce the chances of getting null pointer exceptions, which are the #1 type of crashes on Google Play.
Furthermore Kotlin extension libraries let you write cleaner code by reducing boilerplate and making it easier to take advantage of advanced Kotlin language features even when using libraries originally written in Java.
In addition to our Firebase KTX libraries, you can also use the coroutines Kotlin extension libraries by Jetbrains to write safer async code with Kotlin and Firebase:
dependencies { // Coroutines implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.9' // Coroutines extensions for the Tasks API implementation 'org.jetbrains.kotlinx:kotlinx-coroutines-play-services:1.3.9' // Firestore Kotlin extensions implementation 'com.google.firebase:firebase-firestore-ktx:22.0.2' }
Consider this code to fetch a document from Firestore. This code uses the Firebase Android SDK and the Play services Tasks library, both of which are Java libraries:
fun getUser() { val query = FirebaseFirestore.getInstance() .collection("users").document("user123") // query.get() returns a Task, we attach a callback to get the result query.get().addOnSuccessListener { snap -> val user = snap.toObject(User::class.java) } }
By using the Kotlin extension libraries above we can make this code simpler, safer, and easier to read:
suspend fun getUser() { // Firebase.firestore is a convenient syntax from the firestore-ktx library val query = Firebase.firestore .collection("users").document("user123") // The kotlinx-coroutines-play-services library allows us to "await" the // result of a Task and avoid callbacks, which simplifies our control flow val snap = query.get().await() // The .toObject<T> function from the firestore-ktx library uses Kotlin's support // for advanced generics to avoid the need to pass a Class object val user = snap.toObject<User>() }
Example provided by Firebase GDE Rosario Pereira Fernandes
Once you’ve developed and released your app, Firebase Crashlytics helps you improve and monitor your app stability. With Crashlytics you can track, prioritize and fix stability issues that erode app quality, in real-time. For instance, custom logs and keys in Crashlytics provides you with information on the specific state of your app leading up to a crash and gives context on why a crash occurred. With this level of in-depth insight, you can uncover the root causes of crashes more quickly before they affect a large number of your users.
For further analysis of your Crashlytics data and to segment your user data, you can also export all your crash data to BigQuery in real-time. For example, you can determine emerging crashes in new code, or see the top crash issues for the day to help you prioritize and fix them faster. You can also use our Data Studio template to easily visualize this data with custom dashboards. Data Studio dashboards are easy to collaborate on and share so your team can work more efficiently; even your team members who aren't comfortable with SQL can easily work around BigQuery data sets.
These are just a few examples of the ways you can improve your app stability with Firebase, Kotlin Extensions and Crashlytics. It’s easy to get started with Crashlytics and Firebase Kotlin Extension libraries, and as always if you need help please feel free to reach out to us through our Community Slack.
Happy developing!
The COVID-19 pandemic of 2020 brought changes and challenges for many businesses. During this time, we saw developers use resilience and ingenuity to adapt their apps and business models to these new circumstances. For GameNexa Studios, an app developer and consultancy based in India, one of the biggest challenges they faced this year was to figure out how to evolve their monetization strategy in the face of declining ad revenue. The GameNexa team needed a data-driven approach to diversify their revenue stream across their portfolio so they turned to Firebase.
With 40 apps and games under their belt serving 5 million monthly users, GameNexa Studios had a well-established monetization strategy, but like many of their peers, it was disrupted by the COVID-19 pandemic. Previously, the company earned most of its income from ads in their free-to-download titles. However, when many of their advertisers slashed their budgets, GameNexa’s ad revenue dropped too.
To offset their losses, GameNexa needed to pivot from a one-size-fits-all strategy to a diversified revenue model. But diversifying revenue doesn’t mean bombarding users with more offers and in-app promotions - that could drive people away. The most effective monetization strategies are tailored to user preferences and behavior. So, GameNexa first used Google Analytics and Firebase Predictions to better understand their users and then grouped them into segments based on common characteristics like language, and predicted future behavior, like their propensity to make an in-app purchase.
After gaining insight into their users, GameNexa used Firebase Remote Config and Firebase A/B Testing to test new ad placement, formats, and different in-app promotions on each segment to find which offer resonated with each group. They also worked on improving their user experience with Firebase Crashlytics and Firebase Performance Monitoring.
As a result of these efforts, GameNexa saw a 2.5x increase in revenue from in-app purchases and they were able to bring their ad revenue back up to pre-COVID levels by doubling ad impressions. In addition, by creating customized in-app purchase packs for different audiences, GameNexa increased conversions by 6x. Inspired by their own success, GameNexa now plans on sharing what they’ve learned about the power of data-driven monetization and personalization with other developers through their app consultancy. Read their full story and get more details on how they used Firebase to grow and diversify their revenue in our new case study.
One of the biggest challenges game developers face is figuring out how to improve monetization without compromising their game experience. Many game developers embed ads into their titles, which enables them to offer their games for free and remove the cost barrier of adoption for players - while still generating revenue. In-app advertising can be lucrative, when done effectively and in moderation.
But how do you know what types of ads are best-suited for your game? How do you ensure ads won’t drive away players? These are the exact questions Pomelo Games had. For answers, they turned to Firebase.
Pomelo Games is one of the top game studios in Uruguay. They pride themselves on developing unique and polished games that capture players’ imaginations. Their recent release, Once Upon a Tower, “is an easy-to-pick-up, hard-to-put-down, free-to-play game,” says co-founder Jonás Mora. A Play Store Editors’ Choice, the game is beloved for its high-fidelity graphics, as well as the “fairness of its free-to-play mechanics,” says Jonás.
So when the team needed to improve the game’s monetization, they were unsure how to proceed. They were looking for a way to increase revenue without sacrificing the affordability and game quality their players loved.
Pomelo Games used Firebase Remote Config and Firebase A/B Testing to test a new ad format: interstitials. They also used Google Analytics to monitor revenue and Firebase Crashlytics to keep an eye on stability.
Although initially opposed to the idea, Jonás and his team discovered that showing interstitial ads to their entire player base led to an average 25% increase in AdMob revenue, and surprisingly, a 35% increase in in-app purchases as well. In both cases, there was almost no negative impact on retention or game stability. Firebase gave Pomelo Games the confidence to try new approaches to grow revenue without driving players away. Read Pomelo Games’ full story and get details on their success with Firebase in our new case study. And learn more about how Firebase can help you build and grow your game, and see what other game studios are using Firebase.
Over the last decade, mobile gaming has evolved from stacking colored blocks on a phone to encompass multidimensional and multiplayer experiences that engulf people in imaginative, high-fidelity worlds. As games have gotten more engaging, they’ve also become more complex to develop and maintain. Here at Firebase, we’re committed to providing game developers with the tools and resources you need to build, release and operate successful games that delight players.
We participated in the Google for Games Developer Summit in March, launched Unity and C++ SDKs for Cloud Firestore into open alpha, shipped improved workflows for Unity developers, debuted some new video tutorials, and wrote some new blogs too - so you can easily add Firebase to your game and get the most out of our platform.
We have more exciting updates to come, driven by your feedback and stories. Recently, we spoke to Gameloft to understand how they’ve been using Firebase.
Gameloft is one of the world’s largest gaming studios, employing 4,600 people across 19 global offices. Their vast portfolio consists of over 190 critically-acclaimed, award-winning games that are played by 80 million people each month. Gameloft develops original franchises, like Dungeon Hunter, and also partners with major entertainment studios like Disney.
With such a broad portfolio and audience, having the ability to monitor the stability of their games in a holistic way, and the agility to respond to issues quickly, is key to their success. However, they were lacking proper information about crashes, having a hard time reproducing crashes, and unforeseen technical issues were taking too long to track and fix, upsetting both their team and their players.
Gameloft realized they needed a robust crash reporting tool that could help them improve game quality in a more streamlined and efficient way, so they turned to Firebase Crashlytics.
Crashlytics aggregates crashes by root cause, highlights the impact on players, and provides contextual information on each issue, which helps Gameloft prioritize the crashes to fix first and speeds up their troubleshooting process. By using Crashlytics, Gameloft achieved a 10% reduction in users experiencing crashes overnight for one of their games (Overdrive City). According to Gameloft, this also led to a bump in the game’s Play Store rating and increased session duration by 16%! Find out what Gameloft did to drive these results with Crashlytics by reading the full case study. And learn more about how Firebase can help you build and grow your game, and see what other game studios are using Firebase.
With our announcement of the Firebase Crashlytics SDK Beta in February, we provided a path to help you remove all Fabric dependencies in your code, and complete your migration to Firebase. Since then, tens of thousands of apps have adopted the Beta SDK, and several hundreds of millions of end-users are using apps that include the SDK. Thank you to the adopters of our Beta SDKs; with your help, we have been able to polish and debug our SDK so we could ship it in its best possible launch state.
We are excited to announce that the Firebase Crashlytics SDK is now publicly available! Whether your app was migrated from Fabric or created in Firebase, we encourage you to upgrade to the official version of the Firebase Crashlytics SDK.
Now that the Firebase Crashlytics SDK is publicly available, we are deprecating the legacy Fabric SDK. The Fabric SDK will continue reporting your app's crashes until November 15, 2020. On this date, the Fabric SDK, and beta versions of the Firebase Crashlytics SDK, will no longer send crashes to your Firebase dashboard. To continue getting crash reports in the Firebase console, make sure your app has the following versions of the Firebase Crashlytics SDK, or newer: 17.0.0+ for Android, 4.0.0+ for iOS, and 6.15.0+ for Unity. Developers new to Crashlytics should begin with our getting started docs.
As always, we’d love to hear your feedback! Let us know what you think through our official support page!
Happy coding!
Stability is critical to your app’s success, so we’ve continued to enhance Firebase with tools to help you maintain high quality apps. This includes bringing the best of Fabric’s crash reporting tools to Firebase. Many of you have made the move from Fabric to Firebase yet still have questions like “Why do I still have ‘Fabric’ everywhere in my code?” or “Why does it feel like I am in Firebase, yet still in Fabric?”
We can now lay your questions to rest. We're excited to announce Firebase Crashlytics SDK is in Beta!
With the Firebase Crashlytics SDK, you can remove all Fabric dependencies, such as references to Fabric’s APIs in your code, giving you a much cleaner codebase.
The Firebase Crashlytics SDK is also designed to be intuitive and consistent with all other Firebase SDKs. For example, the Crashlytics SDK has consistent package names, API design, and initialization as other Firebase SDKs.
The Crashlytics SDK also supports Mac Catalyst apps, in addition to iOS, macOS, and tvOS apps. This new feature makes it easier for you to continue building apps for Apple devices.
We’ve also open-sourced the Crashlytics SDK to further increase the extensibility and transparency of our platform.
Combining analytics data and crashes helps you unlock additional insights into your app’s stability. The Firebase Crashlytics SDK works seamlessly with the Google Analytics SDK to provide features such as crash-free statistics, the Latest Release report, and Breadcrumbs. With Breadcrumbs you can see the steps a user took that led to a crash. This insight helps you reproduce and fix issues quickly. Google Analytics replaces Fabric's legacy analytics engine, Answers, so we encourage you to add Google Analytics to your apps.
Try it out!
Ready to begin developing with Firebase Crashlytics SDK? If you are upgrading from the legacy Fabric Crashlytics SDK, read our upgrade guide. Developers new to Crashlytics should begin with our getting started docs. Interested in the Crashlytics source code? View our Android and iOS repositories on GitHub.
We'd love to hear your feedback. As always, you can reach out to us through our official support page. Happy developing!
Keeping an eye out for issues that affect your app’s stability is crucial, but we also know that you can’t spend your entire day staring at the Firebase Crashlytics console.
From the beginning, Crashlytics has given developers the ability to turn on stability alerts so they can be notified when issues increase in impact and severity. Developers have the power to customize these notifications so they're delivered at the right time and channel for maximum visibility - channels where developers already spend their time.
In this blog post, we'll review the types of alerts Crashlytics provides and our recommendations on how to configure them based on observations from customers.
Let’s start by reviewing the different types of alerts Crashlytics sends. Currently, Crashlytics sends five alerts: new fatal issue, new non-fatal issue, trending issues, regression, and velocity alerts.
New issue alerts let you know the first time a new crash has occurred. We filter out the noise of repeated crashes, but give you the full stream of unique crashes by stack trace grouping. These alerts are turned off by default to avoid over inundating you, because as your app grows, you could get tons of alerts for every new version. We recommend turning these on for teams interested in knowing about every new type of crash, and for QA teams chasing down crashes found in testing versions of their apps.
Regression detection alerts you when a previously closed issue re-occurs in a new app version, which is a signal that something else may be awry and you should pay close attention to it.
Trending issues digest is sent out to developers in two instances 1) When Crashlytics detects a new crash is beginning to gain momentum (called emerging issues) 2) When Crashlytics detects new top crashes that have climbed to close to the top of your issue list recently (called trending issues). This daily email is on by default, and is a great way to keep track of emerging issues in your app.
One of the most important alerts within Crashlytics is the velocity alert, which notifies you when an issue suddenly increases in severity and impacts a significant percentage of your users. However, we recognize that every app is unique and the one-size-fits-all alerting threshold might not be what’s best for you and your business. That’s why you can now customize velocity alerts and determine how often and when you want to be alerted about changes to your app’s stability.
You can learn more about customizing velocity alerts here.
Now that you know the different notification types in Crashlytics, you can begin to build your alerting plan.
Firebase Crashlytics offers several channels to receive the above alerts. The first two channels are email and in-console alerts.
To setup these alerts:
Next, you can set up notifications through Slack, Jira or PagerDuty. To set up these alerts, you need to do two things: integrate Slack / Jira / PagerDuty with your Firebase project, and then choose your triggers.
For Slack:
There are two ways to create Jira issues from Crashlytics issues:
Here’s how you enable the Jira integration:
Our PagerDuty integration is setup similarly.
We find that a lot of our users get different utility out of each channel. In Slack, teams frequently set up a channel to show a real-time feed of all new issues, as a way to loosely monitor new issues coming up. Developers with an interest in specific pieces of code can then click through to get more detail on the issues they’re interested in. This is a pattern that seems to work well for most teams.
In Jira, we see developers using the manual integration option to create issues when they know their team is ready to take on that work. In addition, teams also setup automatic triggers for velocity alerts and regressions as those are known higher priority issues to look into.
And for PagerDuty, most teams focus on velocity alerts, which provide insight into the most critical situations your users are experiencing. For teams with even more custom use cases, we recommend developers integrate Crashlytics with Cloud Functions.
By setting up alerting in Crashlytics, you can rest assured that you’ll be alerted when critical issues occur in your app and be ready to take action when needed. For more about Crashlytics check out our docs here.
