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.
Firebase is committed to building an easy to use and robust backend service for Unity developers. Recent changes in the build system accompanying Unity 2020.1 have caused some of the integrations that the Firebase games team built for Unity to stop functioning correctly. Our team is aware of this, and is working hard to rectify the situation. Until then, we recommend that you continue to use Unity 2019 for the best developer experience. For those of you that are on Unity 2020.1, the rest of this post details the workarounds needed to get things up and running.
The Firebase SDK for Unity includes native C++ code and Android specific logic. It also requires some build time operations for all of its products to function properly. Because of this, we have written a number of tools and custom routines that make strong assumptions about Unity’s build process. These continue to work to simplify integration back to Unity version 5, but in Unity 2020.1 the engine overhauled its build system invalidating our previous assumptions. This means that the mechanism by which AndroidX and Jetifier are integrated no longer functions as well as the mechanism by which the information in google-services.json is transmitted to your final Android game. This is required to initialize the Android side of Firebase and to properly hook it up to the Firebase backend.
google-services.json
Further, components that the Crashlytics SDK requires to function are no longer generated. In the worst case scenario, this manifests in a crash on launch.
Although we recommend sticking with the 2019 branch of Unity for the best experience, Unity’s new build system is very similar to a typical Android Java project. This simplifies the workaround we will highlight below, and will mirror some steps in the getting started with Android guide.
Note that because you are performing operations that the Firebase SDK would typically handle automatically, you may have to undo any changes when a full fix is rolled out by our team.
The first fix is to help Firebase find your google-services.json file. Normally the Firebase Unity Plugin would do this automatically, replicating the work of the Google Services plugin Android developers may be familiar with. When you add or update your google-services.json file, the plugin creates a version that Android reads as a “resource” at Assets/Plugins/Android/Firebase/res/values/google-services.xml. Typically this would get copied into your final project automatically, but we can do a little manual work to ensure it gets included!
Assets/Plugins/Android/Firebase/res/values/google-services.xml
First generate a custom mainTemplate.gradle and gradleTemplate.properties (which we’ll need in a moment) via Project Settings/Player/Publishing Settings if you haven’t already:
mainTemplate.gradle
gradleTemplate.properties
Project Settings/Player/Publishing Settings
If you’ve disabled EDM4U’s integration or you just want to be extra careful, now is a great time to also force resolve your Android dependencies from Assets/External Dependency Manager/Android Resolver/Force Resolve. This will update mainTemplate.gradle in a manner that still cuts back on most of the work we’ll have to do:
Assets/External Dependency Manager/Android Resolver/Force Resolve
Now you need to tell gradle where to find the google-services.xml file by adding this to the very bottom of your mainTemplate.gradle:
google-services.xml
android { sourceSets { main { def unityProjectPath = $/file:///**DIR_UNITYPROJECT**/$.replace("\\", "/") res.srcDirs += (unityProjectPath + '/Assets/Plugins/Android/Firebase/res/values/google-services.xml') } } }
There’s one more fix to get base functionality working in Unity, you’ll see that towards the top of mainTemplate.gradle there are some lines like:
// Android Resolver Repos Start ([rootProject] + (rootProject.subprojects as List)).each { ext { it.setProperty("android.useAndroidX", true) it.setProperty("android.enableJetifier", true) } }
This code used to go through every project in the build and enable AndroidX and Jetifier. Although we could perform a similar modification via gradle, Android developers are generally encouraged to use gradleTemplate.properties - which is supported via Unity’s new build pipeline.
So if you remembered to generate it earlier in the tutorial, add the following lines to the end of gradleTemplate.properties:
android.useAndroidX=true android.enableJetifier=true
At this point, most of Firebase should function. This includes your ability to measure your game’s performance with Google Analytics, use that to customize your player’s experience with Remote Config, and to Authenticate you user to begin your game’s connection social experience.
Crashlytics needs a little more work to get operational since it has to embed itself a little deeper into the build process. To continue, you will need the baseProjectTemplate.gradle (the “project level gradle file”). You’ll also need launcherTemplate.gradle since we need an “Application” for Crashlytics (mainTemplate.gradle is technically a “Library”):
baseProjectTemplate.gradle
launcherTemplate.gradle
There’s no need to Force Resolve dependencies again since EDM4U doesn’t know about these files yet! But you can always do it to be safe (the way I modified mainTemplate.gradle purposely avoids bits of the file that would get updated).
Now open baseProjectTemplate.gradle and look for something that looks roughly like:
allprojects { buildscript { repositories {**ARTIFACTORYREPOSITORY** google() jcenter() } dependencies {
Inside allprojects.buildscript.dependencies (the dependencies { bit in this example), add this code to tell gradle about Crashlytics:
allprojects.buildscript.dependencies
dependencies {
// Add the Crashlytics Gradle plugin. classpath 'com.google.firebase:firebase-crashlytics-gradle:2.2.0'
and this line of code to the very end of launcherTemplate.gradle to add the Crashlytics plugin to your Application:
// Apply the Crashlytics Gradle plugin apply plugin: 'com.google.firebase.crashlytics'
We are working hard to resolve these issues as soon as possible so you can go back to building games quickly, easily, and confidently, with Firebase and Unity. To those developers who did upgrade to Unity 2020.1 and encountered issues, we apologize for any confusion or difficulty that this has caused. We would like to reassure you all that there is also active work on some exciting updates that will aid in avoiding similar issues in the future and bring more transparency to this process.
If these steps don’t work for you, or a specific Firebase library isn’t working after you’ve completed these steps, feel free to join in the conversation at the Unity GitHub repository or reach out to support and we will be happy to provide further help.
For your reference, I’ve included all of my modified files here. Do not copy these files directly, but use them to verify that you’ve made the proper changes in the proper locations:
// GENERATED BY UNITY. REMOVE THIS COMMENT TO PREVENT OVERWRITING WHEN EXPORTING AGAIN // Android Resolver Repos Start ([rootProject] + (rootProject.subprojects as List)).each { ext { it.setProperty("android.useAndroidX", true) it.setProperty("android.enableJetifier", true) } } ([rootProject] + (rootProject.subprojects as List)).each { project -> project.repositories { def unityProjectPath = $/file:///**DIR_UNITYPROJECT**/$.replace("\\", "/") maven { url "https://maven.google.com" } maven { url (unityProjectPath + "/Assets/GeneratedLocalRepo/Firebase/m2repository") // Assets/Firebase/Editor/AnalyticsDependencies.xml:18, Assets/Firebase/Editor/AppDependencies.xml:20, Assets/Firebase/Editor/CrashlyticsDependencies.xml:20, Assets/Firebase/Editor/RemoteConfigDependencies.xml:20 } mavenLocal() jcenter() mavenCentral() } } // Android Resolver Repos End apply plugin: 'com.android.library' **APPLY_PLUGINS** dependencies { implementation fileTree(dir: 'libs', include: ['*.jar']) // Android Resolver Dependencies Start implementation 'com.google.firebase:firebase-analytics:17.4.1' // Assets/Firebase/Editor/RemoteConfigDependencies.xml:15 implementation 'com.google.firebase:firebase-analytics-unity:6.15.2' // Assets/Firebase/Editor/AnalyticsDependencies.xml:18 implementation 'com.google.firebase:firebase-app-unity:6.15.2' // Assets/Firebase/Editor/AppDependencies.xml:20 implementation 'com.google.firebase:firebase-common:19.3.0' // Assets/Firebase/Editor/AppDependencies.xml:13 implementation 'com.google.firebase:firebase-config:19.1.4' // Assets/Firebase/Editor/RemoteConfigDependencies.xml:13 implementation 'com.google.firebase:firebase-config-unity:6.15.2' // Assets/Firebase/Editor/RemoteConfigDependencies.xml:20 implementation 'com.google.firebase:firebase-crashlytics:17.0.0' // Assets/Firebase/Editor/CrashlyticsDependencies.xml:13 implementation 'com.google.firebase:firebase-crashlytics-unity:6.15.2' // Assets/Firebase/Editor/CrashlyticsDependencies.xml:20 // Android Resolver Dependencies End **DEPS**} // Android Resolver Exclusions Start android { packagingOptions { exclude ('/lib/arm64-v8a/*' + '*') exclude ('/lib/armeabi/*' + '*') exclude ('/lib/mips/*' + '*') exclude ('/lib/mips64/*' + '*') exclude ('/lib/x86/*' + '*') exclude ('/lib/x86_64/*' + '*') } } // Android Resolver Exclusions End android { compileSdkVersion **APIVERSION** buildToolsVersion '**BUILDTOOLS**' compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } defaultConfig { minSdkVersion **MINSDKVERSION** targetSdkVersion **TARGETSDKVERSION** ndk { abiFilters **ABIFILTERS** } versionCode **VERSIONCODE** versionName '**VERSIONNAME**' consumerProguardFiles 'proguard-unity.txt'**USER_PROGUARD** } lintOptions { abortOnError false } aaptOptions { ignoreAssetsPattern = "!.svn:!.git:!.ds_store:!*.scc:.*:!CVS:!thumbs.db:!picasa.ini:!*~" }**PACKAGING_OPTIONS** }**REPOSITORIES** **IL_CPP_BUILD_SETUP** **SOURCE_BUILD_SETUP** **EXTERNAL_SOURCES** android { sourceSets { main { def unityProjectPath = $/file:///**DIR_UNITYPROJECT**/$.replace("\\", "/") res.srcDirs += (unityProjectPath + '/Assets/Plugins/Android/Firebase/res/values/google-services.xml') } } }
org.gradle.jvmargs=-Xmx**JVM_HEAP_SIZE**M org.gradle.parallel=true android.enableR8=**MINIFY_WITH_R_EIGHT** **ADDITIONAL_PROPERTIES** android.useAndroidX=true android.enableJetifier=true
// GENERATED BY UNITY. REMOVE THIS COMMENT TO PREVENT OVERWRITING WHEN EXPORTING AGAIN allprojects { buildscript { repositories {**ARTIFACTORYREPOSITORY** google() jcenter() } dependencies { // If you are changing the Android Gradle Plugin version, make sure it is compatible with the Gradle version preinstalled with Unity // See which Gradle version is preinstalled with Unity here https://docs.unity3d.com/Manual/android-gradle-overview.html // See official Gradle and Android Gradle Plugin compatibility table here https://developer.android.com/studio/releases/gradle-plugin#updating-gradle // To specify a custom Gradle version in Unity, go do "Preferences > External Tools", uncheck "Gradle Installed with Unity (recommended)" and specify a path to a custom Gradle version classpath 'com.android.tools.build:gradle:3.6.0' **BUILD_SCRIPT_DEPS** // Add the Crashlytics Gradle plugin. classpath 'com.google.firebase:firebase-crashlytics-gradle:2.2.0' } } repositories {**ARTIFACTORYREPOSITORY** google() jcenter() flatDir { dirs "${project(':unityLibrary').projectDir}/libs" } } } task clean(type: Delete) { delete rootProject.buildDir }
// GENERATED BY UNITY. REMOVE THIS COMMENT TO PREVENT OVERWRITING WHEN EXPORTING AGAIN apply plugin: 'com.android.application' dependencies { implementation project(':unityLibrary') } android { compileSdkVersion **APIVERSION** buildToolsVersion '**BUILDTOOLS**' compileOptions { sourceCompatibility JavaVersion.VERSION_1_8 targetCompatibility JavaVersion.VERSION_1_8 } defaultConfig { minSdkVersion **MINSDKVERSION** targetSdkVersion **TARGETSDKVERSION** applicationId '**APPLICATIONID**' ndk { abiFilters **ABIFILTERS** } versionCode **VERSIONCODE** versionName '**VERSIONNAME**' } aaptOptions { noCompress = ['.unity3d', '.ress', '.resource', '.obb'**STREAMING_ASSETS**] ignoreAssetsPattern = "!.svn:!.git:!.ds_store:!*.scc:.*:!CVS:!thumbs.db:!picasa.ini:!*~" }**SIGN** lintOptions { abortOnError false } buildTypes { debug { minifyEnabled **MINIFY_DEBUG** proguardFiles getDefaultProguardFile('proguard-android.txt')**SIGNCONFIG** jniDebuggable true } release { minifyEnabled **MINIFY_RELEASE** proguardFiles getDefaultProguardFile('proguard-android.txt')**SIGNCONFIG** } }**PACKAGING_OPTIONS****SPLITS** **BUILT_APK_LOCATION** bundle { language { enableSplit = false } density { enableSplit = false } abi { enableSplit = true } } }**SPLITS_VERSION_CODE****LAUNCHER_SOURCE_BUILD_SETUP** // Apply the Crashlytics Gradle plugin apply plugin: 'com.google.firebase.crashlytics'
