We are developing a multiplayer game made with unity, and every-time a match starts, after our API has been successfully executed (on our custom backend servers), I immediately log a custom firebase event called MatchStart.
However when we compare the number of matches that have been started in our server database versus firebase analytics, we find that number in our database is 2.5x - 3x larger then the number of events reported by firebase analytics.
Same happens with other events, ex. similarly, I send a custom Register event every-time when a user registers, and numbers are messed up again, in database they're 2.5x - 3x time larger compared to firebase analytics.
Any idea why is this happening?
NOTE: I know that firebase may take some time to process events, so I made sure to also test number of events that have been sent a few days ago. Also we double checked in our database, everything seems to be ok.
Related
We are using Firebase/Google analytics for our Android and iOS app. Everything seemed to be sending data correctly and we were able to view the data in Big Query etc. However we started to notice that some data seemed to be getting lost.
We detected an odd situation where some users' analytics data stopped showing on Firebase/Google Analytics/Big Query, despite having previously received data from that user in the past. The data seems to just stop at a random point in time, for random users.
in_app_purchase events from those players were still appearing in the data on dates where they didn't have any other events. We checked our backend service (gamesparks) for their account and could see that they were active players who had been using the app very recently. That is, after their last event was appearing in Big Query.
After investigating some more and started finding other users who had the same issue. They would be sending data without issue and then all of a sudden we would receive nothing from them, except from in_app_purchase events/notification events etc which are sent via a seperate service (app store etc) rather than the client.
After scouring our implementation and going over it line by line comparing to the samples/documentation we couldn't really see any issues, and even the automatic events (session_start etc) stop appearing. We made sure we were using the latest versions of the firebase SDKs etc in the hope it would fix it but it made no difference.
One peculiar thing is that when we find a in_app_purchase event from one of these 'broken' players, things like the user properties and default parameters for that player have changed from when they stopped sending data, so it seems like the lost data is somewhere but not being logged anywhere.
I was wondering if it was possible for specific users to stop their app sending any analytics data to Firebase via a device/google account setting?
While looking into the documentation we noticed that if Google Play Services is installed on the device, data is sent via that, rather than via the client/firebase sdk itself. Is there any known issue with players changing their Google Play Services settings that could cause something like this?
Wondered if this was a known issue but please let me know what other information you might need.
EDIT: I also wanted to mention that although we can't be 100% certain, we believe this is only happening to our Android users. We haven't found any iOS users that have the same issue.
Thanks,
Matt
I have created a simple firebase webapp, which is subscribed to listen for changes within a collection in firestore. As there are only 3 items in that collection, I was wondering how it was possible to reach the quota limit of 50k reads a day. I did leave the app running on localhost while I was away from my computer, which I am assuming is the reason that it reached the daily quota limit. But how was it possible to do that?
Basically, I have one page on my webapp that is subscribed to my collection in firestore. I then use that data retrieved to display it on the page.
As I said, there are only 3 items in the collection I am subscribed to. How does the subscription work? Is it constantly reading the database to watch for changes, or does it only do a read request when the collection changes (a doc being added or removed, for example)?
PS I have not even published this app to the web, so I don't think it's even possible for read requests to be coming from another computer.
You got a loop there
useEffect is triggered whenever products changes, and you are calling setProducts in the useEffect itself.
So i'm thinking that this has consumed all your daily quota.
I have a Flutter & Firebase app that provides users with price updates on the dashboard on the main screen. It does this with a Firestore Snapshot Listener, but my read count is flying through the roof (I'm at 203 reads and just 1 device is connected)... This info will only change once a month, and it really doesn't need to keep checking for updates at all times.
Is there a way to setup the listener so that it checks less frequently for updates? Or perhaps, can I setup a Firebase In-App Messaging system with which I send the price out and the app just saves and displays it?
Or is there any efficient solutions?
Since the Listener (which you do not show, so we can't even help you there) ONLY triggers when there is an update to the documents (NOT on a schedule) something is updating the collection you are listening to. 203 is not particularly high over a few days - how long has your app been running? Have you been restarting the app frequently? Most Listeners will give you a result at least once when you initialize them - i.e. when you start the app. There is no "long-term global memory" like that.
A listener will always receive updates as soon as they becomes available. This can't be configured. If you want a different update frequency, you should instead schedule that yourself within the app, and use get() to poll the database as often as you need. You can also use FCM on your backend to push updates to the app, if that works for your case.
I've build a library-style SQLite iOS app using the code in the Recipes sample app, and it works - updates on one device are (eventually) reliably propagated to all other devices running the same app. I've been testing it with multiple events per hour all day long, and all the log transactions do get to every device. However, the time for the updates to propagate is highly variable. If I bring the app up and let it sit, it could be a relatively long time before the cloud sends update transactions to the app, and so what's on-screen remains old data for that same long time. Worse, there's no indication the data is out of date.
If I cause the app to post a change to the cloud, though, updates from the cloud propagate down relatively soon. That suggests that I could put in a hack that periodically posts pointless changes to the database, but even then I won't know if I've received all the changes.
First question: Do methods that will force transactions to propagate exist? a This thread suggests not.
Second question: Is there a way to detect if the local database is out of date? I don't want to tickle the cloud copy incessantly, but doing so now and then until the database is current might not be such a bad idea.
1) if you find such methods, please let me know.
2) same stuff here. I didn't even find any reliable way to detect whether the currently running instance of the iCloud app is not the first instance i.e. other instances have already sent updates to the iCloud until the first push received (which can take some unknown time)
It appears that the Google calendar API effectively locks you out if you create and delete a few (less than 10) calendars within a short space of time.
This has made it basically impossible for me to test my app, because it creates/deletes a calendar for each user that is added/removed from the app. Currently, I'm "working around" this issue by creating a new Google account each time I get locked out of the Calendar API. Clearly, this solution is less than satisfactory.
Is there any way I can avoid this over-zealous DoS prevention?
Thanks,
Don
If your application doesn't require an instantaneous call out to the Google API, your code can queue the actions and throttle the calls to x calls over y seconds. Not an ideal solution but it would reduce the likelihood of hitting the quota limit.
Can't you just "reset" (i.e. delete all entries) the test calendars instead of re-creating them every time?
Try creating a localized version of the calendar that you either have the user save (upload to Google) with a button click or as an event (ie. closing the program, every x minutes). Store all the data locally, and only upload to Google as needed. I don't know how neccessary it is that the data be available immediately, but if your app can handle some delay, then this may work for you.