Cloudflare Worker to BigQuery to dbt to Conversions API fan-out

What it does

The Worker receives every event on something like collect.yourdomain.com. It checks the payload, drops malformed or bot traffic, adds server-side context such as the timestamp and country, sets or refreshes a first-party identifier cookie, and writes events to BigQuery in batches.

Why it exists

It is the same job a server-side GTM container does, with two differences. It is code you own and can test like any other code, and it writes to the warehouse first instead of forwarding straight to vendors. Safari caps cookies set by JavaScript at 7 days, or 24 hours after a click from a decorated link. A cookie set by your own server can last longer, but Safari also caps server-set cookies at 7 days when the subdomain is a CNAME to a third-party host or resolves to a third-party IP address, so how the subdomain is hosted matters.

What it costs to run

Cloudflare Workers are billed per request and B2B traffic volumes are small, so running cost is low. The real cost is ownership: this is custom code, so someone has to deploy it, version it and read the logs when something changes. That is a bigger commitment than a hosted sGTM container.

What it does

A small set of SQL models, versioned in git, turns raw events into something you can act on:

• Identity stitching. Anonymous first-party IDs are linked to HubSpot contact IDs when a visitor submits a form or is otherwise identified, so earlier visits and click IDs attach to the right contact.
• Sessionization. Events are grouped into sessions with your own rules, so the source of a visit is defined once, in code you can read.
• Lifecycle joins. Contacts are joined to lifecycle stages and deals from HubSpot, so a conversion can be “became an SQL” or “opportunity created”, not just “filled in a form”.

Why it exists

This is the layer a tag manager cannot provide. A server-side container sees one request at a time. It cannot look back at a contact's first visit or forward to the deal that closed later. The models can, and they define conversions the same way for every platform.

What it costs to run

dbt Core is open source and runs on a schedule wherever you already run jobs. The ongoing cost is attention: models need an owner who updates them when HubSpot properties, lifecycle stages or pipeline definitions change. This is the layer that most often decides whether the architecture is worth it.

A server-side GTM container, often hosted on Stape, is simpler and is enough for most B2B companies. It has ready-made tags for GA4, Google Ads, Meta and LinkedIn, it can be managed in a familiar interface, and it fixes most of the data loss from ad blockers and short-lived browser cookies. When I build server-side tracking for a client, this is usually what I build.

The warehouse architecture is worth it when you need things sGTM is not designed for:

• Warehouse-grade identity. Linking anonymous visits to HubSpot contacts across devices and weeks, not just within one request.
• Replayable data. Rebuilding conversions from raw history when a definition changes, without losing months of signal.
• One conversion definition. Lifecycle-based conversions defined once and sent to every platform, instead of configured separately in each tag.
• An audit trail. A queryable record of what was collected, under which consent state, and what was sent where.

The price is ownership. sGTM can be maintained by a technical marketer. This needs someone comfortable with code, SQL and a cloud project. The two are also not exclusive: a common path is sGTM first, with a warehouse added once the questions outgrow it.

Consent is not a filter added at the end. It is a field on every event, from the browser to the final send.

• The browser script reads the consent state from your consent banner and attaches it to each event, using the same signals as Google Consent Mode: analytics_storage, ad_storage, ad_user_data and ad_personalization.
• The Worker stores the consent state with the event. Identifier cookies are only set when the consent state allows it.
• The dbt models carry consent through every join, so a conversion knows the consent state of the visit it came from.
• The fan-out job checks consent before every send. Where consent is required, nothing goes to an ad platform without ad_user_data granted. Google Ads uploads also carry the consent fields Google asks for.
• Personal data such as emails is hashed before it is sent to any platform, and the raw data lives in your own cloud project, under retention rules you set. Deletion requests are handled in one place.

None of this replaces a consent banner configured correctly in the first place. If your banner and Consent Mode are not set up properly, start with Consent Mode setup.