This article was originally published on the Google Play Medium channel.
Mobile games have evolved rapidly in recent years. Player expectations have increased along with this evolution. Players now demand games with rich and compelling stories that run smoothly regardless of their device. At the same time, as game studios realized the opportunities in going mobile, there is an ever-increasing number of mobile game titles competing for players' attention. In this increasingly competitive market, the ability to iterate and improve player experiences faster than rival titles is vital. Therefore, having the right tools and knowing how to apply them is a key skill for any game developer.
For many years, Firebase has provided game developers with the tools they need to build, release, and operate successful games. More than 2.5 million apps and games actively use Firebase every month, including global game studios such as Gameloft, Pomelo Games, and Halfbrick Studios.
This article explores four scenarios that game developers deal with on a daily basis and shows how Firebase provides the tools and insights to help you stay ahead of rivals.
It’s easier to provide better experiences to players when you understand how they interact with your game. Knowing how much time players spend in the game, what activities they prefer, and how often they come back enables you to personalize the game experience to suit their behavior and preferences. For example, different groups of players have different monetization preferences. Some may choose to spend money to improve their experience, while others may prefer to see ads and trade their time and attention instead. Understanding these differences – even details such as what people prefer to buy and what they do before making their first in-app purchase – is crucial to optimizing player experiences.
Firebase offers robust integration with Google Analytics. This integration helps shed light on who your players are and how they’re engaging with your game by providing insight into in-app events and user properties. This short video will show you how to log custom events and interpret the data to understand your players better.
Through the audiences feature, Firebase’s Google Analytics integration enables you to segment your user base in ways that are important to your business. You can use these custom audiences to filter reports to understand how different players engage with your game and identify patterns of behavior within the audience. Then, you can use this information to send targeted notifications and personalize the game behavior for player profiles. Take a look at this video to see how to set up audiences for your game.
Push notifications can be used for everything from reminders about opening a chest to letting everybody know the biggest update of the year is available. As push notifications allow real-time communication between a game company and its players, they’re often a critical part of a retention and re-engagement strategy. Most successful games have players worldwide, which means choosing just one language and time of day to communicate with them all is not ideal. After all, you don’t want to annoy players by sending them a push notification at 2 a.m.
Firebase Cloud Messaging lets game developers send targeted messages and notifications, which can be customized to suit your brand and align with player preferences. This video shows how you can send push notifications to players with devices set to a particular language and schedule delivery at an appropriate local time. Firebase Cloud Messaging also lets you target by game versions, geographies, your custom audiences, and many more variables. After sending the push notifications, you can see how many were delivered, how many were opened, and, if you choose to set it up, how many conversions happened.
While many players will gladly invest money in the games they enjoy, other players prefer ads in exchange for the gameplay. Many games employ a hybrid monetization strategy, meaning they include both ads and in-app purchases. As a general rule, the more ad impressions, the greater the revenue generated with ads. However, many other factors need to be considered to optimize and balance user experience and revenue. Differences between ad formats, their sizes, and how often they’re shown without disrupting the game experience are important factors.
Once you decide on these factors, how can you determine if the selected formats are the best ones? Is the frequency right or too much, and is the frequency negatively impacting retention? These questions can be answered quantitatively with Firebase A/B testing. A/B testing can be used with Firebase Remote Config to experiment with different combinations of ad types and frequencies to find the best option. To set up an experiment, all you need to do is define a goal, like increase total revenue, and identify secondary metrics such as D1 and D7 retention.
This video walks you through the process of setting up an experiment to test different ad formats so you can identify the best choice for a game. These parameters will vary from game to game, so it is always good to test the options available.
Pomelo Games, one of the top game studios in Uruguay, used Firebase Remote Config and Firebase A/B Testing to test the effect of showing interstitial ads to their entire player base versus a specific segment. Then, they used Google Analytics to measure the impact on revenue and retention. They also used Firebase Crashlytics to keep an eye on their game vitals. After two weeks of testing, the Pomelo team discovered that interstitial ads led to an average 25% increase in AdMob revenue and, surprisingly, a 35% increase in in-app purchases too. In both tests, there was almost no effect on retention. (Check out the full case study.)
Releasing new game features can be nerve-wracking because you may worry about how players will receive the new features. Will players enjoy the new feature you worked hard on? Will the new feature increase engagement and session time? One way to gain confidence that new features will positively impact your key metrics is by slowly rolling them out and seeing how they perform with a subset of your players before wider release.
In addition to gradually rolling out new features, it's also important to continually experiment with new content or in-game mechanics to optimize the player experience. However, constantly iterating your game can be a time-consuming and tedious process if you don't have the right tools.
Firebase Remote Config lets you dynamically configure your game and confidently roll out new features so you can deliver highly personalized experiences to your players without publishing an app update. This video shows you how to set up and tweak Remote Config parameters and instrument feature flagging.
Conclusion
Firebase is a powerful platform. It’s a great fit for game companies that want to enhance how they optimize experiences to delight their players and improve engagement and monetization. To get started with Firebase, you create your project in the Firebase console. To see more examples of how to use Firebase to supercharge your games business, check our Games with Firebase video series, where we walk through each step of the implementation process and share common use cases.
If you've been working with Firebase on Android, you may have noticed that you don't normally have to write any lines of code to initialize a feature. You just grab the singleton object for that feature, and start using it right away. And, in the case of Firebase Crash Reporting, you don't even have to write any code at all for it to start capturing crashes! This question pops up from time to time, and I talked about it a bit at Google I/O 2016, but I'd also like to break it down in detail here.
The problem
Many SDKs need an Android Context to be able to do their work. This Context is the hook into the Android runtime that lets the SDK access app resources and assets, use system services, and register BroadcastReceivers. Many SDKs ask you to pass a Context into a static init method once, so they can hold and use that reference as long as the app process is alive. In order to get that Context at the time the app starts up, it's common for the developers of the SDK to ask you to pass that in a custom Application subclass like this:
public class MyApplication extends Application { @Override public void onCreate() { super.onCreate(); SomeSdk.init(this); // init some SDK, MyApplication is the Context } }
And if you hadn't already registered a custom subclass in your app, you'd also have to add that to your manifest in the application tag's android:name attribute:
<application android:icon="@mipmap/ic_launcher" android:label="@string/app_name" android:name="package.of.MyApplication" ... >
All this is fine, but Firebase SDKs make this a lot easier for its users!
The solution
There is a little trick that the Firebase SDKs for Android use to install a hook early in the process of an application launch cycle. It introduces a ContentProvider to implement both the timing and Context needed to initialize an SDK, but without requiring the app developer to write any code. A ContentProvider is a convenient choice for two reasons:
Let's investigate those two properties.
ContentProvider initializes early
When an Android app process is first started, there is well-defined order of operations:
When a ContentProvider is created, Android will call its onCreate method. This is where the Firebase SDK can get a hold of a Context, which it does by calling the getContext method. This Context is safe to hold on to indefinitely.
This is also a place that can be used to set up things that need to be active throughout the app's lifetime, such as ActivityLifecycleCallbacks (which are used by Firebase Analytics), or a UncaughtExceptionHandler (which is used by Firebase Crash Reporting). You might also initialize a dependency injection framework here.
ContentProviders participate in manifest merger
Manifest merge is a process that happens at build time when the Android build tools need to figure out the contents of the final manifest that defines your app. In your app's AndroidManifest.xml file, you declare all your application components, permissions, hardware requirements, and so on. But the final manifest that gets built into the APK contains all of those elements from all of the Android library projects that your app depends on.
It turns out that ContentProviders are merged into the final manifest as well. As a result, any Android library project can simply declare a ContentProvider in its own manifest, and that entry will end up in the app's final manifest. So, when you declare a dependency on Firebase Crash Reporting, the ContentProvider from its manifest is merged in your own app's manifest. This ensures that its onCreate is executed, without you having to write any code.
FirebaseInitProvider (surprise!) initializes your app
All apps using Firebase in some way will have a dependency on the firebase-common library. This library exposes FirebaseInitProvider, whose responsibility is to call FirebaseApp.initializeApp in order to initialize the default FirebaseApp instance using the configurations from the project's google-services.json file. (Those configurations are injected into the build as Android resources by the Google Services plugin.) However, If you're referencing multiple Firebase projects in one app, you'll have to write code to initialize other FirebaseApp instances, as discussed in an earlier blog post.
Some drawbacks with ContentProvider init
If you choose to use a ContentProvider to initialize your app or library, there's a couple things you need to keep in mind.
First, there can be only one ContentProvider on an Android device with a given "authority" string. So, if your library is used in more than one app on a device, you have to make sure that they get added with two different authority strings, or the second app will be rejected for installation. That string is defined for the ContentProvider in the manifest XML, which means it's effectively hard-coded. But there is a trick you can use with the Android build tools to make sure that each app build declares a different authority.
There is a feature of Android Gradle builds call manifest placeholders that lets you declare and insert a placeholder value that get inserted into manifest strings. The app's unique application ID is automatically available as a placeholder, so you can declare your ContentProvider like this:
<provider android:authorities="${applicationId}.yourcontentprovider" android:name=".YourContentProvider" android:exported="false" />
The other thing to know about about ContentProviders is that they are only run in the main process of an app. For a vast majority of apps, this isn't a problem, as there is only one process by default. But the moment you declare that one of the Android components in your app must run in another process, that process won't create any ContentProviders, which means your ContentProvider onCreate will never get invoked. In this case, the app will have to either avoid calling anything that requires the initialization, or safely initialize another way. Note that this behavior is different than a custom Application subclass, which does get invoked in every process for that app.
But why misuse ContentProvider like this?
Yes, it's true, this particular application of ContentProvider seems really weird, since it's not actually providing any content. And you have to provide implementations of all the other ContentProvider required methods by returning null. But, it turns out that this is the most reliable way to automatically initialize without requiring extra code. I think the convenience for developers using Firebase more than makes up for this strangeness of this use of a ContentProvider. Firebase is all about being easy to use, and there's nothing easier than no code at all!
Generating insights from data and acting upon it appropriately can often make or break a company. In the past few years, the field has grown leaps and bounds with a lot more app developers tracking a lot more events. Yet, truth be told, it’s easy to get overloaded with data and, hence, make it tougher for yourself to find what you were looking for.
So, what metrics should you be tracking to help improve your product?
Analytics is a vast field, with several popular practices and frameworks being employed across the world in every industry. One of the most popular frameworks, particularly in the tech products sector, is Pirate Metrics. The term was coined by Dave McClure, founder of 500 Startups, and is very popular amongst product managers and growth hackers across the world for how it simplifies and breaks down a product’s user lifecycle.
In this post, we’ll cover the five metrics that are collectively called Pirate Metrics and understand their importance. In following posts in the series, we will see how we can use Firebase products to boost these metrics and, hence, build more engaging products.
: The first element in user lifecycle of any product is the acquisition, meaning user install your app. Users are acquired in many different ways, either organically, such as through social media communications, App Store optimization, search, news, content marketing etc., or inorganically which is usually ads.
Congratulations, you have acquired a user! However, your job is less than half done and there is still a need to convince the user that the app is worth keeping around. To give yourself the best chance, you want to activate the user by getting them to experience what makes your app special. For example, a game might want the user to go through a training level or a photo filter application might want the user to experiment with any one image.
The biggest challenge most products face is to retain the users that they acquired. A typical person only uses about 26% of their installed apps daily. People tend to either uninstall or simply forget about the applications they downloaded after the first few days. The goal for any new healthy product is to find a strategy to retain them, and have them keep coming back.
You also want your users to be your biggest advocates. No acquisition strategy is as powerful as an organic, referral campaign. If users love your product, they genuinely want their friends to try it out as well, and you want to really encourage your users to do so, and reduce any friction that might stop a user.
Ultimately, you want to monetize your app in order to grow your company and reach more users.
These five stages - Acquisition, Activation, Retention, Referral, and Revenue are collectively called Pirate Metrics. These are fairly general and can be applied to most digital products. Product managers use a wide variety of tools to track these different metrics. However, with the new Firebase, not only can you track these in one single place, you can also use the suite of different tools to boost them.
We’ll see how in the coming posts. Stay tuned!
