Last year we announced that app developers could upgrade their Firebase projects to the next generation of app analytics. Upgrading enables them to view their app analytics data in Analytics and unlocks additional analysis capabilities.
Since then, we’ve expanded more Google Analytics features like automated and custom insights to also include app data so that you can more quickly identify key trends and anomalies from your app reporting. Earlier this year we introduced a gaming-specific Analytics experience to help mobile game developers more easily see how players move through the lifecycle. And to bring predictive insights to your site and app, we rolled out new predictive capabilities in Analytics – not only helping you reach customers most likely to purchase, but also giving you new ways to retain those less likely to return to your app via App campaigns in Google Ads.
We are continuing our investment in the app ecosystem and today, we are introducing new updates to Google Analytics that will help you get the insights you need to be ready for what’s next. Let’s take a look at some new features you can use when you upgrade.
The ability to measure all your revenue sources helps you monetize and grow your apps business. Soon, you’ll be able to view impression-level revenue data in Analytics from AdMob mediated revenue and from other third-party app advertising platforms – giving you a holistic view of your customers' lifetime value.
You can now view revenue from MoPub and ironsource in the new Analytics.
To get started, use the Google Analytics for Firebase SDK to log the ad_impression event whenever users see an ad impression. Be sure to include details such as the ad platform, source, currency and value.
With this revenue data now in Analytics, you can build audiences of high-value users and reach them for re-engagement campaigns. Third-party ad revenue will also soon be available as an experiment objective in A/B testing with Firebase. This way, you can test changes in user experience and see which drive more revenue through third-party platforms like MoPub or ironSource.
In the past, custom parameter reporting in Analytics for Firebase required you to register parameters for each event individually, which is time intensive and quickly uses up your quota. With event-scoped custom dimensions and metrics in the new Analytics, you only need to register each event once at the property level. You can also create and edit custom dimensions and metrics in the “All Events” section for your entire property. Plus, custom parameters you’ve previously created will automatically be upgraded to custom dimensions and metrics.
Create a custom dimension for your entire property.
Let’s say you’re a game app developer and you want your Analytics reports to show the levels at which users are starting, quitting, retrying, and ending your game. Previously, you’d need to register a custom event parameter for every single event. So with four events (starting, quitting, retrying, and ending) you’d have to register a parameter, “level,” four times. With the new Analytics, one single metric, “level,” is applied at the property level across all events — reducing the number of custom metrics your property uses.
When users are signed in on your Android or iOS app, Analytics can help you connect the customer journey across platforms and devices with a special view in your reporting. Now, you can use those signed-in user insights to create relevant audiences and reach them with personalized messages in remarketing campaigns. And with the new Analytics, we’ve provided you with more granular controls for ads personalization so that you can choose when to use your data to optimize ads and when to limit your data use for measurement.
Let’s say you’re a lifestyle retail brand with a conversion rate on your mobile app that surpasses the rate on your website. Taking a closer look, you might notice a cohort of returning customers who visit your website for lifestyle content but never make a purchase. You can group the signed-in visitors into an audience and reach out to them with a marketing promotion, driving them to your app, where they have a higher likelihood to convert. For those who convert within the app, you can understand their complete customer journey across platforms and more effectively analyze the success of your promotion and adjust from there.
The enhanced intelligence of Analytics provides additional revenue data to help improve your advertising strategy, simplified and efficient event measurement, and tailored experiences for increased conversion opportunities. If you aren't already using the new Google Analytics, upgrade to the new Google Analytics from the Firebase console today.
We’re excited to introduce two improvements to Remote Config’s app version targeting functionality - New semantic version number targeting and improved iOS version number targeting.
App version targeting is a powerful tool that helps you customize your app for users on specific versions. Whether it’s releasing a new feature behind a feature flag or running an A/B Test on your latest app version, Remote Config’s app version targeting makes this easy; all without needing to publish app updates. These new updates will help you target exactly the right versions of your Android and iOS apps.
Previously in Remote Config, our iOS version targeting was applied to your app’s
CFBundleVersion, which is commonly known as your app’s “build” number. This understandably generated some confusion! We’ve cleared up this confusion by renaming the previous iOS “version number” conditions to “build number” and introducing a new version condition for iOS, available in Firebase iOS SDK version 6.24.0 or above, that matches against your app’s CFBundleShortVersionString.
As developers, we’re constantly pushing out new versions of our apps. Often, we need to segment users who are on, above, or below a specific version number to enable some feature or fix. Writing regular expressions to target versions greater than or less than a specific version number is challenging and difficult to validate. That’s why we’ve made numeric operators like “greater than” and “less than” available for version number targeting!
Now it’s quick and easy to target versions of your app that came before, after, or exactly equal to a specific version number - no confusing regular expressions required! So for example if you want to target a fix for users between specific versions of your app, like version numbers after 1.2.3 but before 1.3.4, it's as easy as setting these two conditions in the console: Version >= 1.2.3, and Version < 1.3.4.
You can review our full set of targeting conditions here.
We hope you enjoy using the new version number targeting features, and let us know what you think! As always, you can reach out to us on StackOverflow or the official Firebase support site.
Hi, Firebase developers!
In what might be my shortest (but most exciting) blog post this year, we wanted to let you know that Cloud Firestore now has support for not-equal queries. This means you can now query, for example, all documents in a "Projects" collection where the project's status field is not equal to the value "completed"
status
"completed"
On a similar note, Cloud Firestore also supports not-in queries, where you can query for documents where fields are not in a list of values. So you can, for example, find all documents in a "Projects" collection where the status isn't equal to "completed" or "dropped" with a single query.
not-in
"dropped"
Note that neither of these calls will allow you to fetch documents where this field doesn't exist. If a field is completely missing from a document, it will not be returned in your query results.
Notice that project 4593 does not get included in the results, because it has no owner field
When it comes to combining these not-equal operators with others in the same query, they have many of the same restrictions as other inequality operators (<, >=, etc.). You can't use a != operator against two different fields, for instance. Similarly, you can't use a != query on one field and then sort by a second field. And combining a != query in one field with a == query in another field requires your creating a composite index. Make sure to check out the official documentation for all the details.
<
>=
!=
==
This functionality is currently supported by the iOS, Android and Web client libraries, as well as the Node.js and Java server-side SDKs. Support for C++ and other server libraries is coming soon.
We hope this new addition makes it a little easier to develop Cloud Firestore-powered applications, and as always, if you have questions, please feel free to reach out on StackOverflow.
Happy coding!
Getting your internal team to run the most recent pre-release build of your app is critical to receiving feedback on the latest features you’re getting ready to ship. However, testers receive a lot of emails on a daily basis and sometimes miss out on an email notification about a new build. This means your testers might be running old builds and sending you bug reports for an issue that’s already been fixed.
With the App Distribution iOS SDK, open sourced and available today, testers receive in-app alerts when a new build is available. Right from your test app, testers can install the update and quickly start running the latest build.
In-app alert of new release within test app
Like App Distribution, the iOS SDK was built with flexibility top-of-mind, giving you the option to customize the full user experience to make it feel like a natural extension of your app.
We’ve been working with a number of companies over the past few months, incorporating their feedback and understanding how they’re using the App Distribution iOS SDK. Twitter, who had previously used a similar feature with Fabric’s Crashlytics Beta, has integrated the SDK into their nightly builds to make sure testers can easily access the latest update. We sat down with Twitter iOS engineer, Mateusz Dzwonek, to learn more about their experience:
Why did the Twitter Release Team decide to use the Firebase App Distribution iOS SDK?
One of the main goals for our Twitter employee app is to catch bugs before they go to the public Twitter app. We always try to make it as easy as possible for people to install and update this app to the latest version, but it can get out of date pretty quickly with how often we ship new versions. In the past, we relied on sending emails to have our users update the app, which put the burden on the user to always keep up with it. But thanks to the Firebase App Distribution SDK, we were able to simplify the process by showing users if they are on the latest version and allowing them to update from the app instead of having to click on a link in an email.
How did the team use the Firebase App Distribution iOS SDK to improve your testing release process?
Before Firebase, we would check if the user was on the latest version and if not, we’d display a prompt that started an immediate update. We know that most of our users launch the app to complete a specific task, and forcing them to close the app to update it can be frustrating. So one of the most important features we were able to add to our app was a new and improved update mechanism which was possible with the Firebase App Distribution SDK. Now we’ve added an option to install the update when they close the app, and it has reduced the amount of time it takes for the latest version to reach the majority of users by nearly 20%.
Wrap Up
We hope Twitter’s success story highlights the importance of improving your tester’s experience by giving them the flexibility to install your latest pre-release versions right from your test app. We’re excited to hear about how other companies use the App Distribution iOS SDK as part of their internal testing workflow. To get started, check out our docs to set up in-app build alerts. Happy testing!
