Could Functions for Firebase invocations displayed in Stackdriver - firebase

I'm using Firebase with Cloud Functions on the Blaze plan, and I would like to get an overview of how many of the 2 million free monthly invocations I'm using. After that (that's another story though) I would like to make the same overview for the other price points that Firebase is billing for, such as GB-seconds, CPU-seconds, and Network Outbound usage. I can't see these metrics in the firebase console, so my approach is to use the Google Cloud Console and Stackdriver.
Function Invocations in Firebase
Function Executions in Stackdriver
As it's seen on the two graphs, they clearly have the same shape, but the scales are different. The Firebase graph appears to have 3-4-times larger magnitudes that the Stackdriver graph.
Questions:
How come the two graph doesn't match each other?
Which one am I being billed for?
Here is how I've configured the Stackdriver chart:

So I asked the Firebase Support Team as Doug proposed.
Here's what they replied:
I just got an update from our engineers.
They're hinting that the difference might come from the aligner being
count and not sum, which is what the Firebase Console uses. With this,
could you try changing it and see if the values change?
Additionally, the console is pulling the data from Stackdriver, so the
source of the data should be the same. You should also be billed based
on the Stackdriver values. If there's still a discrepancy, please let
me know and provide the updated screenshots so I can investigate
further.
Afterwards I changed the aligner to be sum instead of count, which resultet in a chart with roughly the same scale as the Firebase graph.
So to answer my own questions:
How come the two graph doesn't match each other?
The should! The aligner in the Stackdriver chart must the set to sum to reflect the Firebase graph.
Which one am I being billed for?
Both! The data in Firebase originates from Stackdriver, so the graphs should match. If they don't It's likely an issue with the Stackdriver chart settings, and Firebase must be the true value.

Related

Pricing for specific Googleway commands in RStudio

I am currently using the Google Places API on a free trial. I am interested in paying for the API but can't find the exact cost of the two commands that I use: google_places(), and google_place_details(). I have contacted the Google sales team and looked at the places and billing url, but I have not managed to find the answer of how much it would cost exactly to execute these two commands.
For google_places(), this is an example of a command I would execute:
google_places(search_string = "Cafeteria in Madrid, Spain", key=key)
From the places and billing url, it seems like this counts as a text search, so each time the code is executed it would cost 0,032$. Is this the case?
For google_place_details(), here is an example of the command I would execute:
google_place_details(place_id = "ChIJf_XA-F0U04kR1IPYSdTJ4so", key=key)
This command, as well giving basic place details (which cost 0,017$ according to the billing url),
gives information which counts as contact data (an extra 0,003$) and atmosphere data (an extra 0,005$). It also provides photo data (0,007$ according to the billing url), which I am not interested in but is automatically included in the results anyway. Does this mean that the cost of executing this command once is these four prices summed up?
I am interested in knowing exactly how much it would cost to execute the two commands I have listed.
probably this helps:
First of all you are billed monthly after you exceeded the 200 Euro/Dollars, which are given by google for free (as you probably described as "free plan"). So after every month you get a bill on how many requests of each function you send to google. There everything is written quite clearly including the amount and price of each "unit". then you can easily divide it.
Second option would be your Google Api Cockpit.
It tracks your requests quite precisely on different time bases. So sending your wanted commands only once on a day can give you an exact total-price.
The Cockpit is super handy for different things. If you want you can even set limits, which is probably helpful in your case too.
Here is the link to the billing monitor as well: Billing Google API Cockpit
Furthermore the description of how google charges you. Look here
best regards

Getting programmatic access to Firebase Analytics trending events

I have a mobile app which plays audio tracks. It uses Firebase Analytics to record events such as 'track names' played. Within the Firebase 'StreamView' one can access trending events and see which are the most popular tracks being played at any given moment. I would like to gain access to this list to and use it within my app to display a list of "tracks being played now".
I've looked into gaining access to Analytic trending event data and think Firebase Cloud Functions may provide a method of extracting the information I need. However, I'm not certain this is the correct, or easiest, method.
Could someone let me know whether extracting trending events is possible and, if so, point me in the correct direction?
Thanks
EDIT - Actually, there is a much better and easier way to get access to real-time events that have occurred in your app over the last 30 minutes. You can do so using the Google Analytics Data API.
Using the API you can filter through the event data for the past 30 mins, and inspect relevant custom dimensions on the play_track event for the track that was played (or provide a custom dimension filter to further specify the event data you get back).
This would be the ideal way to achieve what you're looking for. You might still want to use Cloud Firestore if you'd like to keep a longer record of trending tracks being played (e.g. in the last hour, last 24 hours, etc... though). Also note that the API is still in alpha.
-- END OF EDIT
Other Solutions
Option 1 - Use Cloud Firestore
This is probably the easiest solution - you can create a record of which tracks are being played whenever the event occurs by creating a simple collection in Cloud Firestore, and updating records for tracks being played there. It would require additional effort in logging and retrieving which tracks are played beyond just using Google Analytics, but should be straightforward to implement.
Note you'll probably want to check out the Firestore pricing guide first before selecting this option.
Option 2 - Using Firebase Cloud Functions
You can trigger a Cloud Function each time a play_track event is logged. The event will need to be marked as a conversion event in order for it to trigger a Cloud Function, and within the Cloud Function you can access the event parameters to identify which track is being played, and over time maintain a record somewhere for which tracks are being played to determine the most trending tracks. To maintain state you could use something like Firestore to keep track of which "tracks" are being played at the moment.
A couple of caveats about this approach:
You'll want to check out the Cloud Functions for Firebase pricing guide to make sure it falls within an acceptable range for your needs.
Cloud Functions triggers for analytics events currently only works for Android and iOS apps (no support for web apps).
Google Analytics triggers for Cloud Functions is currently in beta.
Option 3 - Using BigQuery for your analytics data
This option requires a bit more effort to setup, but you can export your Google Analytics data to BigQuery, and query the generated intraday tables to see which tracks are trending as well as a lot more additional insights.
The caveat with this approach are that you'll also need to check the pricing guide for using BigQuery to make sure it falls within your needs, and you'll need to make a call to execute the query and retrieve the list of tracks (or get a cached result).

Stackdriver : create alert policy based on simple arithmetic involving two user-defined metrics

I have two user-defined metrics: totalCount and failedCount.
I've combined them into a single stacked-bar graph on a Stackdriver dashboard. All looking good so far.
I'd like to alert if failedCount exceeds 20% of the totalCount, but I can't find a way to achieve this. The dialogue to create an alert policy only allows me to work with one metric, but I need both in order to perform the simple arithmetic.
What am I missing?
What you want to do is not supported at the moment in google not such Datadog, there are other option such like When creating Alert Policy you have the option to add more than one metric in one Alert see below an example and use just the policy Triggers, see below:
You can see check this stack for more details on the arithmetic operation.
I think that the ability to create the kinds of alerting you'll be talking about will be included in Service Monitoring (see the Service Level Objectives section):
https://cloud.google.com/service-monitoring/
You can create exactly the alerting policy you're describing using a ratio alert. Unfortunately, you can't create those through the UI, you have to use the API (https://cloud.google.com/monitoring/api/ref_v3/rest/v3/projects.alertPolicies#metricthreshold - check out "denominatorFilter").
The gcloud CLI tool does support everything the API does, so you don't actually have to write code if you don't want to - see https://cloud.google.com/monitoring/alerts/using-alerting-api#api-create-policy.
Aaron Sher, Stackdriver engineer

Firebase + BigQuery - Uniquely Identifying Devices

Recently started exploring the Firebase data via the Data Studio Firebase connector. I'm doing some custom reports based on the user_engagement event to compare with data we previously reported on in Flurry.
When looking at some DAU figures they are pretty close but on MAU they tend to get inflated. (Saw this behavior first on the Firebase Events Report Template). Digging into it a little more we do have a pattern where users frequently reinstall the app which generates a new app_instance_id. So as I fallback I'm using the resettable_device_id but then there's the situation advertising tracking is disabled on device resulting in a zeroed value. (Or for a brief period in January nulled out values, not sure if this was client or part of the Firebase link)
Currently thinking something roughly following the logic below, falling back to app_instance_id if the advertising identifier was not set. What approaches would be worth looking into to have a reliable user identifier for metrics reporting? (In future will be calling the setUserID to utilize our own identifier but looking to match up historical data)
IF(user_dim.device_info.resettable_device_id is not null,
IF(user_dim.device_info.resettable_device_id = '00000000-0000-0000-0000-000000000000', user_dim.app_info.app_instance_id, user_dim.device_info.resettable_device_id),
user_dim.app_info.app_instance_id
) as unique_user_identifier,
Thanks in advance.
Simpler way to deal with the cases where a resettable_device_id is not available:
IF(user_dim.device_info.limited_ad_tracking, user_dim.app_info.app_instance_id, user_dim.device_info.resettable_device_id) as unique_user_identifier

How to query the same crash count from BigQuery as Firebase crash reporting dashboard shows

I have tried to write a query to get number of crashes from BigQuery for certain day. But the number that I got from query doesn't match the number that I can see on Firebase crash reporting dashboard.
So what I am doing wrong?
Here is the query:
SELECT
event_dim.date AS CrashDate,
-- doesn't matter what event_dim field we choose
COUNT(event_dim.name) AS CrashCount,
FROM
TABLE_DATE_RANGE(com_sample_ANDROID.app_events_, TIMESTAMP('2017-01-27'), TIMESTAMP('2017-01-27'))
WHERE
event_dim.name = 'app_exception'
AND event_dim.params.key = 'fatal'
AND event_dim.params.value.int_value = 1
GROUP BY
CrashDate
There are a couple of things to know about what you're trying to do.
First, there is throttling in the Crash SDK that will prevent grossly repeated requests from being sent to the server. This defends us against sloppy programming in the app that could spam us. Analytics may have a different reckoning about what happened, because it's different code.
Second, for apps that legitimately send a lot of data, we may perform a sampling of the data, which means we lose some accuracy but gain a lot of speed. At that scale, you shouldn't expect your numbers to be exact (and it shouldn't matter, because the numbers will be big).

Resources