Here at Firebase, we work hard to keep your apps secure and protect your users. In keeping with that mission, we're proud to announce that we recently implemented Certificate Transparency for the Realtime Database.
Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates. These attack vectors are rare but serious ways of circumventing the protections that SSL/TLS grants to online communication.
Part of Certificate Transparency is the issuance of a Signed Certificate Timestamp (SCT), which Realtime Database responses now include. We have already been sending the SCT when browsers like Chrome requested it, but now it is always bundled in the response.
From today on, every connection from one of your users to your database will be protected by the SCT. Please be aware that the SCT creates a little more SSL overhead, so each response gets slightly larger. The percentage increase for your app is dependent on many factors, such as your average response size, and which clients your customers use. Since outgoing bandwidth (egress) is billed, you may see a slight bill increase as a result.
Certificate Transparency is a great enhancement to SSL/TLS, and we Firebasers are excited about what it means for the security of the internet going forward. We're delighted to bring this protection to you and your users.
If you are a user of Firebase Cloud Messaging (FCM), you know that there are many different ways to send messages. You can target an application on a device, or target millions of them through the topics API. FCM APIs tell you if there was a failure during the acceptance of the request by returning an error code and an explanation for the failure, but this only covers the part of the request between you and the FCM backend. What happens after FCM accepts your message request?
In this post, we will look into the Firebase Cloud Messaging infrastructure and how messages are actually delivered to devices.
When FCM returns a successful response to your API request, it simply means that FCM will start trying to deliver this message to the device or to the service responsible for delivering the message to the device (for example: Apple Push Notification service for delivery to iOS devices or Mozilla Push Service for delivery to Firefox browsers). It will try this until:
Note: If the time to live of the pending messages has expired, the above functions will not be triggered.
There are many factors that affect the actual delivery of the message to the device and the amount of information FCM can provide about the delivery.
Note: If you'd like to analyze message delivery events for your project, you can do so by exporting FCM data into BigQuery.
On iOS, there are two ways in which FCM can send a message to a device:
Note: If you'd like to access iOS notification delivery information for display notifications, you can use the FCM Reporting Dashboard. This dashboard leverages Google Analytics for Firebase data sharing features to collect delivery information through Firebase Android and iOS SDKs for display notifications.
See Lifetime of a Message and Understanding Message Delivery if you'd like to learn more about message acceptance and delivery.
This article originally appeared on the Google Marketing Platform blog.
For businesses to make the best decisions about where to invest their marketing budget, it's critical that they understand user behavior on both their web and app properties. And while a website is often the first customer touchpoint, for many businesses, apps are where customers are spending more of their time. As a result, marketers need to capture audience insights from their app analytics that they can then take action on, both within and outside of their apps.
Google Analytics for Firebase, our app analytics solution, has historically given you the ability to organize your audiences around events, device type, and other dimensions. These criteria were not exhaustive, however, or dynamic as user behavior changed over time.
That's why we've made enhancements to the audience builder experience, with a few major updates to help you identify relevant app audiences more easily and with greater precision:
These new tools make audiences more powerful, flexible and actionable than before, so you can be confident that your insights reflect relevant users and activity on your apps. In 2019, we will continue to enhance the Google Analytics for Firebase audience builder, offering even more ways to precisely create audiences.
Take action once you've identified relevant audiences
Once you've improved your understanding of users, you can also deliver personalized experiences based on varying user needs. For example, through push notifications or Remote Config in Firebase, or customized ads in Google Ads.
Let's say you have an e-commerce app. Using these advanced audience capabilities, you can build an audience of users that visit your app for the first time and add an item to their cart, but don't make a purchase—and only include those who do so in a 30 day window.
Build a dynamic audience for first time users that have abandoned their cart.
You can now reach that audience with tailored messaging relevant to their experience with the app, and encourage them to make the purchase through an in-app promotion, email notification, or personalized ad. Once these users have returned to the app, made a purchase, and/or exceeded the 30 day window however, they will no longer meet the criteria for that audience, and you will not adversely affect their experience with marketing that is no longer relevant to them.
With the ability to create dynamic audiences, you are able to understand your users with better precision. A better view into your audiences means more insight into the customer journey, so you can invest in your marketing activities with confidence and see better results—keeping users happy, and your app growing.
Hey there, Firebase developers! Did you hear the news? Cloud Firestore — our NoSQL database in the cloud for mobile and web apps — is officially out of beta and in General Availability!
Great! So… why's that a big deal?
The move from beta to GA is significant for a number of reasons. For starters, it's Google's way of saying that we're confident in Cloud Firestore's ability to handle your toughest database needs. And you can rely on Cloud Firestore to power all kinds of apps — from experimental prototypes to mission critical enterprise-scale applications.
Moving into GA also has some practical benefits. One of the most important is that Cloud Firestore is now included in GCP's official Service Level Agreements (or SLAs, as they're commonly known). This means you now have guaranteed uptime — 99.999% for multi-region instances of Cloud Firestore, and 99.99% for regional instances.
In addition, now that Cloud Firestore is out of beta, important programs like GCP's deprecation policy officially apply to Cloud Firestore, and Cloud Firestore is now included among our list of services that support HIPAA compliance.
New lower pricing tier — coming soon!
We're also excited to announce a new lower pricing tier (up to 50% off) for most regional instances of Cloud Firestore. And if you're wondering what exactly I mean by "regional" and "multi-region", let's explain:
To over-simplify things a bit, when you have a Cloud Firestore database installed in a multi-region location, exact copies of your database are created in multiple data centers at least a few hundred miles apart from each other. This is great from a reliability standpoint; even if one region were to completely go offline due to a natural disaster or giant radioactive lizard attack, your database would continue to be hosted from the other two.
Even better, this whole setup is completely transparent to you. When you write new values to the database, you're able to read them right away, and not have to worry about whether or not they've fanned out to all of the other regions properly. This is known as being strongly consistent, and honestly, it's a pretty amazing piece of tech that will impress your database aficionado friends.
That said, creating a strongly consistent multi-region database is pretty heavy-duty tech that requires a lot of infrastructure. And while all of that is important for mission critical applications, it might be overkill for some of your other apps, and you might be perfectly happy with the guaranteed 99.99% uptime that comes from having Cloud Firestore hosted in a single region. (Usually just referred to as "regional" locations.)
So to help reflect these differences, we're going to start lowering prices on most of our regional instances of Cloud Firestore in the next month or two. The price will vary by location, but the discount will be as much as 50%. Once this new pricing goes into effect on March 3rd, 2019, it will be applied automatically to those of you who have Cloud Firestore databases hosted in those regional instances.
New locations, too!
As long as we're talking about data center locations, we've added several new locations around the world to host your Cloud Firestore data. There will be a new multi-region location in Europe, and then 9 additional regional locations, including a few in Asia, Australia, North and South America, and Europe. Be sure to check out the Google Cloud blog post for the complete list.
We believe these new locations will give you the tools to help address your local regulations around data storage, and better serve the needs of your customers who might be concentrated in certain areas around the globe. You can select your Cloud Firestore location when you first create your Firebase project, so make sure to pick the location that will provide the best experience for your customers.
Better usage tracking, powered by Stackdriver
One of the biggest concerns we've heard from developers when they're using a tool like Cloud Firestore is that they're not very confident in their app's database usage, and they're worried about the day when a bill arrives in the mail for more than they expected because they had underestimated their app's database usage.
So to help address this, we're going to be adding a new "Usage" tab in the Firebase console to show you exactly how many reads, writes, and deletes your database has received over time. These are the operations that drive the majority of your Cloud Firestore pricing, so making sure you know what your traffic is like in these three areas is critical to keeping a handle on your costs.
These graphs are certainly helpful, but what's really exciting about these usage reports is that they're being powered by Stackdriver, Google Cloud's incredibly flexible monitoring and reporting toolkit. And one really nice feature about Stackdriver is that you can set up your own custom alerts if any of the metrics its measuring go outside certain ranges.
So if you want to receive an email (or PagerDuty notification, or a Slack message) when your database receives more reads than you were expecting in a one-hour period, you can do that. You can also receive alerts if your traffic spikes an unusual amount compared to normal, or if your overall traffic drops below a certain level.
Please note that this usage tab is currently in beta, and while there's a lot more you already can do with Stackdriver (including building your own custom dashboards), we'll be looking to add more Cloud Firestore metrics to Stackdriver in the future. Look for this new Usage tab to appear in the Firebase console in the next few days!
Give it a try today!
Even in beta, Cloud Firestore was driving some fantastic app experiences — with partners like The New York Times, Skip Scooters, QuintoAndar, Nerdery, and more building some really great features powered by Cloud Firestore.
And now that we're in General Availability, this a great time to get started using Cloud Firestore to power your apps. We've got a lot of documentation and samples get started with, and a fun little video series that I am legally obligated to plug. So give it a look, and happy databasing!
What's the deal with audiences?
So if you've never used audiences before, they can be a really powerful way to segment your user base so that you can deliver tailored and relevant experiences to specific groups of users. Maybe that's sending them a customized notification in Firebase Cloud Messaging, maybe that's creating a unique experience for them in Remote Config, or maybe that's targeting them with a remarketing campaign in Google Ads.
