Cloudflare Zaraz Managed Component

[mackenly]

Hello! Awesome project!

I mentioned on Twitter a few weeks back when you announced the project that a Cloudflare Zaraz Managed Component would pair well with this project. I've been working on building one by reverse engineering the tracking script and collect endpoint. Everything seems to be working well!

My question is, what if any level of collaboration would you be open to? And have you considered exposing a dedicated HTTP endpoint with some form of basic auth to ingest data for serverside analytics? The way I am currently doing it feels a bit hacky and prone to break if there are breaking changes to the tracker or collect endpoint.

Repo: mackenly/counterscale-managed-component

I still have a few more things to wrap up, such as using service bindings to avoid the same zone worker limitation, better integration tests, better docs, and some final manual testing to work out any issues.

The benefit of using a Zaraz MC is that it can be fully serverside (no tracking script gets loaded), and integration with consent management is built in. You can, of course, load the tracking script using Zaraz like you would with GTM or similar, but a managed component makes it so that it is serverside and fast.

[benvinegar]

I've been working on building one by reverse engineering the tracking script and collect endpoint. Everything seems to be working well!

Amazing.

My question is, what if any level of collaboration would you be open to?

A ton! This is really just my part-time project I work on occasionally on evenings. In order to deliver on the promise of what it's trying to be, I think I need outside help.

And have you considered exposing a dedicated HTTP endpoint with some form of basic auth to ingest data for serverside analytics?

I think a major goal – for me – is for this project to be as plug-and-play as possible (ideally even easier than today). A single worker is part of that, but I totally understand the desire to separate things. If we can keep the simplicity but make this happen, I'm game.

(For example, ideally a user doesn't even know what a Zaraz MC is. They just hit npm run deploy and things just work out-of-the-box.)

Any contributions that keep those guidelines/project goals in mind, I'm game for. For example, if some changes can be introduced but are enabled via configuration (keeping the default installation easy) that's also okay.

[mackenly]

Got a lot of bugs cleaned up and the deployment process down to cloning and running npm run deploy in the worker's directory. There's no good way to avoid some of the manual Zaraz GUI configurations, though (just as there wouldn't in GTM or whatnot).

A single worker is part of that, but I totally understand the desire to separate things.

Rather than a separate worker, I would rather modify the collect endpoint to handle both GET requests (from the tracker script) as it does now and POST requests, which would accept the data as JSON in the request body rather than in headers/params. That would make sending data serverside much easier and would open the possibility of sending custom events other than page views like purchases, email signup, user interaction, etc., via fetch requests down the road.

If that's something you'd be open to, I'd be happy to work on a PR to split posts out from gets, or otherwise, the current way can still be used, just with a little reverse engineering.

Thank your for your work on this!

[mackenly]

Quick update on this: v0.2 integrates improvements in the packaging tool to allow custom wranglers. This means that the component is much cleaner and abstracted rather than relying on a custom worker template.