While running on Google Cloud with Firestore, I used the latter one. After having moved my setup to stape and modified it to work with Stape Store, I see that it creates a lot of Stape Store requests per usual SGTM request which drives overall costs.
Is there any official or at least half official solution for this? In my opinion stape should offer a solution for this on their own, as this is needed for all more sophisticated GA4 ecom clients.
To be honest I don’t think it makes sense to adapt it for Stape Store as it will indeed generate requests, but it won’t make the customisation any easier. But maybe I’m missing something.
Is there any reason for you not to use the web solution when you store all the same data in cookie/localStorage instead of FS? It looks a lot simpler to me, less dependencies and no need to spend money on a database to do it.
Thanks Alex!
I guess the advantage of server-side is to not pollute the limited cookie space and to not suffer the downsides of local storage (e.g. sharing across subdomains if I am not mistaken).
I also believe that some Stape store requests are absolutely fine - as long as they are only executed when really needed.
It makes sense, but considering that you need this data apparently within the session - ITP browsers will not affect the work of this (the cookie will live for at least 7 days even if it is set just via JS) so I don’t find the point in such a complicated solution to this problem and additional payment for storage.
Also in general the whole solution is based on _ga or FPID cookies it seems, so I think it’s easier to solve this through saving to browser storage.
Although I’m sure there are use cases and necessity for a server-side solution too, but I assume that’s enough in limited cases.