Are there any costs involved for subscriptions on the event topics for the nest device access project? Can't seem to find any documentation about it. Off course lots of on Google Pub/Sub costs (like the first 10GB being free and such). But still would like to know a bit about this.
Greetings,
Gijs
The free quota's are quite large, so no costs for small projects:
https://cloud.google.com/pubsub/pricing
7 different quota's listed:
https://console.cloud.google.com/iam-admin/quotas?service=pubsub.googleapis.com&authuser=1
Related
After some experimenting, I noticed it is possible to send events directly to a server container via HTTP request instead of pushing to the data layer (which is connected to a web container). A big advantage of this setup is that the front-end doesn't need to load any GTM script. Yet, I have some doubts because I don't find much documentation about this setup. This setup also brings some challenges like implementing automatically collected events (e.g. page_view). Does anyone have experience with this setup or is able to tell me why I shouldn't be following this path?
Regards, Thomas
This is definitely not a best practice, although this is actually a technically more beneficial path since... A few things, actually:
Can make your tracking completely immune to adblockers.
Has the potential to protect from malicious analytics spam, also makes it way harder for third parties to spoil your data.
Doesn't surface your analytics stack and libraries to the public.
Is typically way lighter than the GTM lib.
You have a much better degree of control about what happens and have much more power over the tracking.
But this is only if you have the competency to develop it, which is a rarity, actually. Normally web-developers don't know analytics well enough to make it work well while analytics developers lack the technical knowledge. You now suddenly can't just hire a junior or mid implementation expert to help with the tracking. A lot of those who call themselves seniors wouldn't be able to maintain raw JS tracking libraries either.
As you've mentioned, you won't be able to rely on automatic tracking from GTM or gtag libraries. And not having automatic events is actually not the issue. The more important thing is manually collecting all dimensions, including the proper maintenance of client ids and session ids.
Once your front-end is ready, it's important to note that you don't want to expose your server-side GTM's endpoint. I mean, you can, but this would defeat the purpose significantly. You want to make a mirror on your backend that would reroute the events to the sGTM.
Finally, you may want to make up some kind of data encryption/protection/validation/authentication logic on your mirror for the data. You may consider it just because without surfacing the endpoints, you're now able to further conceal what you're doing thus avoiding much of potential data tampering. This won't make it impossible to look into what you're doing, of course, but it will make nearly impossible any casual interference.
In the end, people don't do it because this would effectively double the monetary cost of tracking since sufficient experts would charge approximately double from what regular analytics folks charge. However, the clarity of data will only grow about 10-20%. Such an exchange generally doesn't make business sense unless you're a huge corporation for which even enterprise analytics solutions like Adobe Analytics is not good enough. Amazon would probably be a good example.
Also, If you're already redefining users and sessions, you're not that far from using something like Segment for tracking and then ETLing all that into a data warehouse and use a proper BI tool for further analysis. And now is there still sense in having the sGTM at all if you can just stream your events to Segment realtime from your mirror, and then it can seamlessly re-integrate this data into GA, Firebase, AA, Snowflake, Facebook and tens if not hundreds more destinations, and this all server-side.
You want to know where to stop, and the best way to do it is by assessing the depth of the analysis/data science your company is conducting on the user behavioral data. And in 99% of cases, it's not deep enough to even consider sGTM.
In response to #BNazaruk
So it's been a while now… I've been looking into the setup, because it’s just way too cool. I also took a deeper dive into CGTM to better understand the benefits of SGTM. And honestly, everything that has the probability to replace CGTM should be considered. My main reasons are;
Cybersecurity - Through injection it is possible to insert malicious software like keyloggers. The only thing that withholds this, are the login details to CGTM. These are, relatively speaking easy to get with targeted phishing.
Speed - A CGTM setup, with about 10 - 15 tags, means an avg performance loss of 40 points in Lighthouse.
Quality - Like you said; because browser restrictions like cookie policies and ad blockers that intercept/manipulate/block CGTM signals: On avg. 10-20% of the events are not registered in proper fashion.
Mistakes - Developing code outside a proper dev process, limits the insight into the impact of the code with possible errors or performance loss as a result.
So far I have created a standardized setup (container templates, measurement plans, libraries) for online marketers and developers to use. Within the setup, we maintain our own client and session ID’s. Developers are able to make optimal use of SGTM and increase productivity drastically. The only downside to the setup is that we still use CGTM to implement page_view and exceptions. Which is a shame, because I’m not far away from a full server-to-server setup. Companies are still too skeptical to fully commit to SGTM I guess. Though, my feeling says that in 5 years time, high-end apps won't use CGTM anymore.
Once again, thanks for your answer, it’s been an important part of my journey.
Unfortunately Firebase's Flame plan disappeared and I now have to deal with Blaze plan, which I'm not fan of because of it's "unlimited" budget (but my wallet isn't). Yesterday I was coding and by mistake made a loop that called 3 Cloud Functions, I spotted the loop fast enough to stop the carnage.
In only 15 seconds of execution, I've been able to trigger more than 10K requests, and without errors, that a pretty good performance of Firebase, but it's scary as well! How can I cap this to throttle requests coming from users? I'm pretty confident in my code, but as we all know if someone gets my Firebase config file, I'm done.
I'm a solo developer and it's my first app done on my spare time, I don't want to to become a mess because of triggering reads / writes / Cloud Functions. No one is perfect, everyone makes mistakes, maybe I didn't spot a small bug in my code that'll reveal it's true potential only once in production. I'm not asking Firebase to handle my mistakes, but I'd like to be able to stop the CF and Firebase if I want to.
My only desire is to sleep confident, I don't want to wake up one morning with a 10.000$ bill. I've read that's it's possible to totally disable billing account on a project with CloudFunctions, but what will happen to my Firebase Storage bucket for example (for the storage superior to the Spark plan)? And it doesn't seem easy to do.
Firebase is a great product and I love how easy / fun it is to use, but now that budget locked plans as Flame are gone I feel really trapped now that my application is almost ready to go into production, and I don't think I'm the only one out there.
Ah you've stumbled onto the 'rate-limiting' conundrum. Not to worry, I've spent many nights worrying about this myself.
In order to get a bit more control over your application, you're going to have to link your project to google cloud platform. Then navigate to IAM & Admin>Quotas (once you've selected your firebase project).
Now you might be overwhelmed initially, and confused as to why there are so many Cloud functions API limiters. These quotas should allow you to rate limit your cloud functions API (similar to what twitter does) in a number of ways, including but not limited to:
Read Requests per day
Read requests per 100 seconds
Function invocations per 100 seconds
Function invocations per day
etc
The API that will be listed are the ones you've enabled, so you can set limits for cloud storage as well.
By default, the max number of invocations per second is set to the maximum of 5000 invocations per day on the spark plan. but according to the docs, the absolute maximum is 100,000,000/100 seconds!
Also worth having a look at is the pricing docs, which have a nice example of a typical monthly use case for a successful app. To grossly oversimplify, a single invocation costs $0.0000004, hence 10,000,000 invocations will cost you a whopping $3.20. However don't let that very low cost fool you, if you write some terrible code and it has exponential complexity (like reading every document in a firestore collection every invocation), you could get slapped with an exponential cost. So make sure you set those quotas :)
Remember, server admin is as much a part of the application as the code itself. If your app goes to production, be prepared to spend some time each day going through the Google cloud dashboard and checking limits, analyzing trends, etc. This way you can kind of step up the amount of invocations you can allow per day and sleep well knowing that if you shoot yourself in the foot, you won't bleed too much.
Best of luck with it
Despicable B.
Quick question please. I am working on an on-demand app that uses live tracking which would require the constant update of people’s lat and lng, and I plan to you Firebase Firestore for it. Having read a few scary articles (lol scary in terms of costing) about how Cost shoot up overnight while using firestore. I’d like to know if it’s advisable to use firestore for this, as I think the entire BaaS it offers covers everything I need. If you can recommend the best approach possible to this, thanks
It depends on how large is your userbase and how frequently you want to update their current location.
Under the Flame Plan ($25/month) 100k document writes per day for firestore is supported. If you want more than that you'll need Blaze Plan (pay as you go).
See the pricing for details:
https://firebase.google.com/pricing
I've been reading about Firebase and playing with it for a short while. The idea (BAAS) and implementation are impressive, and having programmed with Javascript it seems a viable choice. Not having to deal with scaling and other server side concerns makes it even more attractive.
My question is: generally speaking, is Firebase a first class back-end candidate for any average data-based application? e.g. billing, CRM, e-commerce, social, location based, etc. I do not include super light or heavy extremes such as a basic chat, or a nuclear plant monitor...
The answer may not be a clear yes/no, but was it built to support the general application space, or just stand out as a real-time read/write data service?
Would appreciate answers based on experience and existing production applications.
Thanks
Yes, Firebase is intended to be a first class back-end for any data based Web, iOS or Android application. The service offers real-time data reads and writes, but also comes with a powerful and flexible security system that allows you to write secure client-only apps, without needing any server code to enforce data boundaries.
There are several apps in production listed on the front page as customer and on the app showcase page on https://firebase.google.com/customers/
Firebase is now more capable and is considered as a full stand-alone back-end, especially after the introduction of cloud function. https://firebase.google.com/docs/functions/
Firebase may not have support for transaction spanning multiple business objects.
e.g. When a sales order is booked then it needs to update inventory for multiple items, update billing in receivables, give sales credit to multiple sales persons etc.
Firebase team is supposed to come up with a database trigger option which will make all these happen.
I've looked all over and found nothing about this topic - For people making mobile app games and want to sell levels or potions or whatnot from within the app, is this supported on Flex mobile apps? Are there plans to introduce it? I've found info about advertisement implementation... is this a possible next step? Do you have to use something like PayPal instead of Android Market?
Sorry if this has been asked, but I haven't found anything yet.
Thanks!
I know Adobe said at GDC Conference they are in the process of analyzing requirements to make in-app purchases available via Flash Player API. It's almost a year so far since that announcement but there has not been any further news. The work around/the way most client-server implement these business rule is on the server-side where they implement an entitlements model.
Yes, there are several native extensions that implement this functionality.
I have been using the ones from Milkman Games with good results, and the support is fantastic. No financial association, just a very satisfied user.
There is also a free iOS Storekit ANE as well, although in my experience with it there are still some bugs, notably with blank receipt values for restored transactions: http://code.google.com/p/in-app-purchase-air-ios/
Note: implementing your own entitlements is ill-advised for various reasons:
Apple doesn't allow using anything other than their own in-app
purchase API on iOS.
The various store implementations (well, Apple's
and Amazon's at least, Google Play is another story) handle all of
the details of international purchases and localized pricing for
you.
The store implementations handle payments, subscriptions, durable purchases, and a host
of other details that you will spend a lot of time getting right on your own.