It’s been a year since we all came together in Madrid, Spain for Firebase Summit 2019, shared announcements and updates, and listened to your product feedback. Since then the world as we know it has changed, but here at Firebase our mission to help developers succeed by making it easy to build and operate mobile and web apps remains the same.
We’ve been working hard to build tools to help you accelerate app development, gain actionable insights and scale with ease. We’re looking forward to sharing these updates with you at this year’s virtual Firebase Summit, happening 27-28 October at 9:30AM PST each day. All you have to do is prop up your mobile device or laptop, head over to firebase.google.com/summit, and tune in from wherever you’d like.
While we will miss connecting with you in person, we are excited that even more developers can join us this year.
Here’s what to expect during the two days:
Join us 27 October at 9:30 am PST for the opening keynote to learn how Firebase can help you build and operate your apps. After the keynote, you can ask questions in the chat and have them answered live by the Firebase team during #AskFirebase.
Stay tuned for 11 technical sessions on topics like monitoring your latest release, increasing user engagement, optimizing your app revenue, and more. These sessions will be live streamed over the two days so you can watch and chat with other developers and the Firebase team, or you can watch them on-demand at your convenience.
For a more hands-on learning experience, watch us live code an app from scratch using Flutter and Firebase. You can also try one of our new demos, codelabs with walkthrough videos and multi-step tracks to learn about popular topics such as how to build a web app using Firebase.
We will be releasing more details about Firebase Summit in the coming weeks. In the meantime, sign up for updates on our event page, subscribe to the Firebase YouTube channel, and follow us on Twitter to join the conversation.
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.
Nothing spoils a great game for a user like a crash, and most of us have been there too: you’re just about to solve the puzzle, defeat the final boss, or cross the finish line, and then...crash.
For Tapps Games, a Brazilian game developer, it was particularly important that players had a stable and high performing gaming experience during one of the feature rollouts to their popular game, Vlogger Go Viral. With more than 11M monthly active users, the Tapps team didn’t have time to investigate every negative review manually — it would take days, leaving a considerable number of users waiting for resolution.
To solve this, Tapps Games enabled Firebase Crashlytics velocity alerts, which let them know right away when there was an increase in the severity of crashes occurring in the Vlogger Go Viral game. Crashlytics also helped them prioritize, identify and track the state and sequences of events that led to the crash using custom keys and custom logs. The Vlogger Go Viral team then used Remote Config to shut down the problem area in stages and used staged rollouts on the Google Play console to slowly release the new version to a subset of it’s players before moving ahead to a full rollout
Check out the full case study to find out how Tapps Games used Crashlytics and Remote Config to increase crash free user rate and improve ratings, and learn more ways Firebase can help you build and grow your game.
We’re excited to announce several new features that make developing with Firebase Hosting even better!
Our new integration with Cloud Logging gives you access to web request logs for your Hosting sites. Cloud Logging, previously known as Stackdriver Logging, makes it easy to view, search, and filter logs. You can learn from where and when you have visits to your site, your site's response statuses, the latency of end user requests, and more.
To get started, link your Firebase project to Cloud Logging in the Cloud Logging integration card in the Firebase console or visit the Hosting docs to learn more.
Hosting will now compress your assets with Brotli encoding. We’ll automatically serve the smallest, best-compressed version of your content, based on what your user's client is able to handle.
Brotli compression gives you a boost in performance because assets are smaller, use less bandwidth, and are delivered more quickly to your end users. This means you’ll have lower bandwidth costs, while your end users will enjoy faster sites.
The best part? You’ll get this automatically the next time you deploy.
We know it’s important to you to provide a great experience for your users everywhere. Firebase Hosting now supports serving country and language specific content, backed by the power of our global CDN. Previously, the best strategy was to use Cloud Functions to look at the country and/or language code and reply with a redirect as necessary.
Firebase Hosting’s i18n rewrites allow developers to serve different content, depending on a user's language preferences or country location. In your public directory, create an i18n directory containing separate folders for each language/country combination, then add the i18n field to your project's firebase.json config. I18n rewrites also work for localized 404 pages. Learn more about using i18n rewrites in our documentation.
i18n
firebase.json
We hope you all are excited for these new features, but stay put because we have even more coming in the future!
The latest Google Analytics for Firebase SDK release now makes it possible for you to log the screen_view event manually for both Android and iOS!
screen_view
When you add the Google Analytics for Firebase SDK to your app, there are a number of different events that start getting collected automatically - including the screen_view event for your Android and iOS apps.
This event is incredibly important to understand your users' behavior since it can tell you the number of users who have visited each screen in your app, and which screens are the most popular. In addition, this event powers the Behavior reports offered in Google Analytics’s App + Web properties, which can tell you how much time users spend in each screen. It also powers the Path Analysis tool where you can discover the most popular navigational paths within your app.
Behavior overview reporting page
Path analysis technique
Most of the automatically collected events, including screen_view, use protected event names that prevent you from being able to manually log events with the same name. There are good reasons for doing this because a lot of these events power other Firebase products, like A/B Testing and Firebase Predictions, and first class reporting features in Google Analytics.
But we’ve heard a lot of your feedback - and screen_view is one event for which you wanted more control over how and when the event gets logged - in addition to having the option to continue logging events automatically.
So our latest release now makes this possible. This release also marks the deprecation of the setCurrentScreen (on Android) and setScreenName (on iOS) methods which will be replaced by the new calls to manually log the screen_view event.
There are many benefits to having more control for when the screen_view event gets logged:
For example, you might only want to log a screen_view event when a user has spent at least some minimum amount of time on the screen.
In fact, you might recall that Google Analytics previously logged session_start events ten seconds after an app first loaded into the foreground. While this has changed and session_start events are logged immediately, there can be instances in your app when it makes sense to wait a few seconds before logging a meaningful screen_view.
session_start
In a video streaming app, users may often load up a title selection screen and quickly scroll through and select a series they’ve already been watching to pick up where they left off. They might not really be searching for new titles, even though they’re visiting the title screen, and you'll want to only log screen views here when you really know that they’re looking for new titles, not just quickly scrolling through it.
Your app might have subsections in some screens (think “Container View Controllers” with inner Child VCs or Fragments), or in the case of a game or a Flutter app, be driven by one screen that powers other views that present meaningful actions a user can take, or represent places in your app where users will spend a significant amount of time. In such cases, you might want to log a screen_view event manually, and add additional event parameters that represent the subsections of your app that your users spend more time exploring.
A good example here is an app that provides a customer support chat interface that overlays onto an existing screen the user is viewing. In such cases, you might want to log a manual screen_view event that represents that chat interface and that can collect more information in added event parameters - like which topic or which screen the user was on before they opened the support chat window.
In addition to the reasons above, there was an issue on iOS devices with automatically collected screen_view events using the soon-to-be-deprecated setScreenName method in which the events were dual-logged. This change also corrects this issue so it is no longer a factor.
setScreenName
You can log a manual screen_view just like you would any other event in Google Analytics. You can also include the two optional parameters (i) screen_name and (ii) screen_class, as well as any custom event parameters you want to include. The two optional parameters take the place of the firebase_screen and firebase_screen_class event parameters that get passed into automatically collected screen_view events.
screen_name
screen_class
firebase_screen
firebase_screen_class
Specifically for iOS, this would look like:
override func viewDidAppear(_ animated: Bool) { super.viewDidAppear(animated) // After enough time has passed to make this screen view significant. Analytics.logEvent(AnalyticsEventScreenView, parameters: [ AnalyticsParameterScreenName: screenName!, AnalyticsParameterScreenClass: screenClass!, MyAppAnalyticsParameterFitnessCategory: category! ]) }
And for Android:
@Override public void onResume() { super.onResume(); // After enough time has passed to make this screen view significant. Bundle bundle = new Bundle(); bundle.putString(FirebaseAnalytics.Param.SCREEN_NAME, screenName); bundle.putString(FirebaseAnalytics.Param.SCREEN_CLASS, screenClass); bundle.putString(MyAppAnalyticsConstants.Param.TOPIC, topic); mFirebaseAnalytics.logEvent(FirebaseAnalytics.Event.SCREEN_VIEW, bundle); }
As mentioned before, the new API will allow you to log manual screen_view events along with the option to continue collecting screen_view events automatically. Since both are possible at the same time, let’s get into some questions to learn more about how the new feature works with the existing automatic event collection.
Yes. While you can use both together at the same time, you can disable automatic event collection for screen_view events if you’d like. On iOS, set FirebaseAutomaticScreenReportingEnabled to “NO” in your info.plist. On Android, set google_analytics_automatic_screen_reporting_enabled to “false” in your manifest.
FirebaseAutomaticScreenReportingEnabled
google_analytics_automatic_screen_reporting_enabled
The setScreenName and setCurrentScreen method calls were used to set a custom-defined screen name as the firebase_screen_name parameter value included with all automatically logged screen_view events. If you want to continue collecting custom screen names on your screen_view events, you will need to log the screen_view event manually and pass in the screen_name event parameter (likely using the same value you were using in the soon-to-be deprecated methods).
setCurrentScreen
firebase_screen_name
Note that for automatically reported screen_view events, the screen name value will be left blank, and the screen class value will be set to that of the most recently shown screen.
If you disable automatic screen reporting, some values are still accessible and can be automatically added to your manually logged screen_view events, such as the firebase_screen_class parameter.
This is because parameters like the screen class are first-class metrics that feed into Google Analytics’ Behavior Reports, and so we’ve gone the extra mile to automatically populate this field using information we know on the client. On Android, the current activity will be used to populate the screen class parameter. On iOS, if you make a call to the logEvent() method, the root UIViewController will be used to populate the screen class value. You can always overwrite this value by passing in a different screen_class parameter, though. On both platforms the screen name will be left blank (unless you specify it), and the value “not set” will be displayed in the Google Analytics console.
logEvent()
Yes, all event parameters that are reported along with automatically collected screen_view events will also be automatically reported with manually logged screen_view events - with one temporary exception for the engagement_time_msec on iOS devices. We are working on implementing support to have the engagement time parameter included with manually reported screen_view events on iOS, but for the time being this parameter isn’t included and instead, is reported on a designated user_engagement event.
engagement_time_msec
We hope you enjoy the new ability to manually log your screen view events, and would love to hear more feedback from you about this feature, or about the Google Analytics for Firebase SDK for your apps in general. Please reach out to us at our Firebase Google Group, on StackOverflow or on our Firebase Support channel to submit your feature requests.
