I agree that GA4 swap-over has been a bit of a mess, with lots of things screaming at you to address in the swap over, uncertainty over the process, etc, especially when the actual change over is pretty simple.
But we’ve found that once it is swapped over, it still works pretty much the same, at least in terms of being able to give you the same insights.
In terms of alternatives, I believe the main one to consider is https://matomo.org.
We’ve got this running on a very large site, and it’s worked as expected.
We also built our own add-on to support it in Concrete (but you should be able to just copy in the scripts in the same way as you do with GA).
Matomo’s interface is solid, but a little quirky in my opinion. It’s quite powerful once you get your head around it. GA’s interface on the other hand is much more appropriate if you’re putting this data in front of a client.
The big difference is that Matomo needs to be hosted somewhere, so requires it’s own hosting, setup and configuration. Arguably that’s a lot more complex than what it takes to set up GA4, it more comes down to what your goals are.
Thanks for the comments, I have returned to GA-4 and I am plowing on trying to make some sense of it.
In the concrete documentation there is a section “How To Add Google Analytics To Your Website - The easy way” published on Oct 9, 2020. It gives the code snippet that is pasted into the backend Dashboard → System & Settings → SEO & Statistics ->Tracking Codes
This code refers to the old type of Google analytics tag, where as GA-4 appears to have measurement IDs and stream IDs (I am still not sure which is which.)
It would very nice if this part of the documentation could be updated for new GA-4 setup.
I think with that doco page about tracking codes, the code in the screenshot is really meant to be ignored - it’s just an example, it could be anything.
(we’ve even used that tracking codes area for random stuff like CSS,)
The cookies in that blog post are really just talking about:
cookies that a concrete install will set
cookies from Concrete’s own website
There’s not a huge amount to worry about here in my opinion. Cookies that Concrete installs set are really to allow for logins. You have to have some kind of cookie to have a logged in session. But it’s really only used for that purpose alone. It’s not like Concrete is going to start setting weird tracking cookies on the sites you set up, it’s really the minimal ‘functional’ cookies required.
The ones relating to concretecms.com are just some of the cookies used on the site, pretty standard tracking cookies really.
You don’t need to pay too much attention to the code in the screenshot. That’s just an example. Concrete’s cookie is actually used to facilitate login. A login session requires the use of some kind of cookie.