Hi, Firestore developers. We are pleased to announce that with the latest version of the client SDKs, you are able to use Firestore data bundles in your mobile and web applications! Data bundles can make certain types of Firestore applications much faster or less expensive.

That's great! Just one tiny little follow-up question: What are data bundles?

So essentially, data bundles are serialized groups of documents -- either individual documents, or a number of documents that you've retrieved using a specific query.

You can save these data bundles onto a CDN or your favorite object storage service, and then load them from your client applications. Once they've been loaded on to your client, your clients can read them in from your local cache like any other locally-cached Firestore data.

Well that just sounds like a database query with extra steps. Why would I want to do this?

The biggest reason is that by having your clients read common queries from a bundle on a CDN and then querying specifically against that cached data, you can avoid making extra calls against the Firestore database. If your application has a substantial number of users, this can lead to some cost savings, and could potentially be faster, too.

But to be clear, data bundles are an advanced feature and probably not something you should be considering until your application has a pretty sizable user base.

So what kinds of documents make sense to put into bundles?

The best kinds of bundles are ones where a majority of your users will be reading in all of the documents in that bundle, the number of documents is on the smaller side, and the contents of that data doesn't change too frequently.

Some good examples for this might be:

• You're storing configuration data across several documents that every client needs to read in upon startup. Since you might have millions of clients reading in the same handful of documents, this would be a great opportunity to put that data into a bundle and save a few million document reads every day.
• You have a news app, blog, or similar application, and you know that every client will be reading in the same top 10 stories every day.
• You want to load in some "starter" data for users who aren't signed in, and you suspect the majority of your users will be ones who aren't signed in -- this is particularly useful in web applications, where you're more likely to encounter users who aren't signed in.

Data bundles are not good for:

• Database queries where you expect each of your users will be making different queries or want different pieces of information.
• Any data that contains private information -- because data bundles are created by the server SDK, they can bypass security rules. So you need to be careful that any data bundles you load onto a client application is something that's intended to be read by the general public.

I just had an idea: What if I were to stuff my entire database into a bundle, load that bundle onto my client, and then just query my entire database using only my cache?

That's a terrible idea.

Remember, the Firestore cache is not particularly fast when it comes to searching through large amounts of data. Overloading your cache by asking it to store a lot of documents that your users won't ever use is a good way of slowing your application to an unusable state. You should really only be leveraging data bundles to load up documents that most, if not all, of your users will be reading in.

Also, keep in mind that with bundles, you have to load in the entire bundle of documents when you load up a bundle, whereas with a normal document query, you're only downloading the documents that have changed from your local cache. So from a data usage perspective, stuffing too many documents into a bundle can be quite heavy.

Gotcha. So how would I implement these?

You can read the documentation for all the details, but in general, the process will work something like this:

• Using the server SDKs, you would generate a bundle that consists of either individual documents, or documents generated using a query.
  • You can also associate these queries with names.
• You can then store these bundles onto your favorite CDN, web hosting service, or binary storage service like Cloud Storage.
• When your client starts up, you will tell it to load in your bundle using your favorite networking library.
• Once your bundle has been properly loaded, the Firestore SDK can merge it with any cached data you might already have. This process is asynchronous, so you should wait until everything has been merged in before trying to use your bundled data.

So, once they're loaded, I can query them like normal data?

Yes. They'll be merged in with your locally cached data and you can make use of them like you would any other cached data. The data bundle also remembers the names of the queries you used to generate the bundle, so you can refer to these queries by name instead of re-creating them in code.

And how do I make sure I'm querying bundled data without incurring any additional Firestore costs?

The best way is to force your client to use the cached data. When you make a document request or database query, you're able to add an option like {source: 'cache'} that directs your client to only use the cached data, even if the network is available.

Tell me more about these "named queries" -- are these different from regular queries?

Not really -- the trick to using bundles effectively is that you want to make sure the query you're requesting on the client is exactly the same as the query that generated the bundle you've loaded. You could certainly do this in code, but by using a named query, you're ensuring that the client will always make the same query that generated the bundle in the first place. There's less room for error that way.

This also means that you can modify the server query that generates the bundle and, assuming you're still using the same name, the client will also use this new query without your needing to update any of the client code.

Notice that the version number has changed, but the client can continue to run the "seed-data" named query

What if I wanted to include data bundles alongside the rest of my local application data when I publish it to app stores? That way, if a user opens my app for the first time and is offline, I can read in the bundle and use that as starter data for my application.

Yes; that can be another great use of bundles. The process is the same, except you'll be reading in the bundle using a local call. Just be aware of the warnings above -- Firestore wasn't designed to be an "offline-first" database, so try to only load in as much data as you'll need to make sure your application is functional. If you overload your cache with too much information, you'll slow it down too much.

Okay, I think I'm ready to start using data bundles in my application.

Great! As always, feel free to ask questions on Stack Overflow if you need help, or reach out to us on the Cloud Firestore Discussion list if you have any other suggestions. Happy coding!

""/>

""/>

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.

1. Optimizing gaming experiences and monetization with data

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.

2. Communicate with your players in their local language and time zone using push notifications

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.

3. Find out the best ad formats to use and how frequently to show them

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.)

4. Gradually roll out game features, run LiveOps, and dynamically update your game parameters

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.