I was checking the crashlytics on firebase. I was seeing crash free users as 92.66% but it is not matching the actual crashes and the users.
The number of users who experienced crashes are 148
The number of active users in the same time periods are 8500
So the number of crash free user should be 8500-148 = 8352 crash free users
And the crash free percentages should be (8352/8500)*100 = 98.26% crash free users
As we can see, there is huge variation of 5.4%. Can someone help me understand what am I doing wrong.
The crash free user stats is not an average but an aggregate. Check this document, it explains how this is calculated.
A screenshot of the chart would help, it usually doesn't have big variations.
However something that I've noticed is that the total users is based on the downloads and not on the number of users that had a session during the period. (active users)
Related
Today I found an error about Firestore Batchwrite in my stock control application.
My database structure was designed to store the order detail information in one collection (orders) and in other collection (report_monthly for count purposes) for monthly reports, I stored the quantity information such as total no of stocks, price, and debts.
The problem was this morning I make offline orders of stocks of about 20-25 orders. After I switch my phone from offline to online instantly, I can see the numbers are increasing (clearly firebase is updating the data) but I suddenly clear the app from working like clear recent apps in the android system. Then when I re-run(open) my app, these data are incorrect. Although the data in order collection(orders) is correct, the report number of quantity value in the monthly collection(report_monthly) was somehow repeated increment.
I tested this process multiple times with my friend and still facing the problems. I also tested without using BatchWrite. In that case, I can still see the issues but some of Fieldvalue increments are right and some are wrong not like in BatchWrite which is the whole list of Fieldvalue increments is wrong.
Can someone suggest to me how can I handle this kind of problem?
I have a few questions regarding this, as I don't want to submit the application form without knowing how it works. I have a turn based online game with around 150k DAU. So that means there are alot of writes, reads and listeners. My (RTDB) load peaks at about 30% atm.
Default calls per day is 10,000. What happens when those run out, will the calls beyond that return errors?
Would it cost me alot more given the amount of users?
In regards to performance, is there something like a "known average percent increase" in read/write operations? It's described in the tutorial video as "instant" but everything takes a little time.
How do I know what amount to apply for? I'm guessing it's 1M-10M or 10M-100M but it's hard to know..
Thankful for any response :)
I built an app and I would like to differentiate the behaviours of my users regarding their activity levels.
Objectives : make monthly users become daily users by understanding how daily users use the app vs monthly users and trying to narrow the gap between them.
I am well aware of the Daily / Weekly / Monthly active users Firebase offer but it is still a snapshot at a specific time.
Basically, if someone open a session at least one time during 20 days / month => highly active users, if someone opens it at between 7-20 times a month => medium active user, if someone opens it less than 7 times => low active users.
Do you have any clue on how to split these to then understand their behaviour?
because you are tagging your question firebase database that means you want to do it programmatically.
you can make a field in user node name it counter and every time the user login to the app you just increment the counter and make a query to bring the count that's it.
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).
I'm working on a web-based academical evaluation project (VS2010,C#,ASP.NET). Users can enter the web site and evaluate personnel of a company (or the company managers). Then my clients (company owners) should be able to view results of the evaluation (appraisal). As this process involves people and there is always risk of re-voting by some users, I'm searching for ways to minimize number of re-evaluations by similar users, i.e. I'm going to prevent a user from voting for more than once as it can hugely affect results of the appraisal process, I'm asking user about his name, surname and national ID; I'll store these data in my database, and the next time a user trying to login with the same data will get a warning, but anyone can change his data and vote for several times! Also I save user IP and will check it on later logins but it can also be faked easily! what else can I do? using cookies? sessions? how should I technically prevent users can from voting for several times?
thanks
You can't avoid it but can minimize it. Take a look at this similar question/answers:
multiple voting.
Hunting Cheaters.
Prevent Users from Voting Multiple times