Two ways to run Cookiebees: stream everything, or enrich the server-side setup you already paid for

Teams arriving at Cookiebees usually fall into two camps. Some have nothing server-side yet and want one system to own it. Others already run a server-side GTM container - often on Stape - that took real effort to build and that they have no appetite to replace. Both are supported, and the second is not a lesser option.

Path one: stream through Cookiebees

The tag goes on your own domain, on a path you choose. Every page view, product view, cart action and checkout flows to Cookiebees first. Identity is resolved as it arrives, the order is joined to it, and conversions go out to Meta, Google Ads, GA4 and the rest from our side.

• One place to see what was captured and what was sent.
• The payload for every conversion is inspectable - you never have to trust a black box.
• Shadow mode lets you see exactly what would be sent before you switch anything on.

This is the simplest setup and the one we recommend for a store with nothing heavy already in place.

Path two: enrich what you already run

If you have a working server-side container, the expensive part is already done. What it is missing is not plumbing - it is identity. A container sees the event in front of it. It does not know that this visitor is the same person who arrived from an Instagram ad eleven days ago on a different device.

So Cookiebees exposes an enrichment endpoint your container calls mid-flight. Your tags stay exactly where they are, your vendor stays your vendor, and the event that leaves is the same event plus everything we know about the person behind it.

• The resolved customer id, so events across devices collapse onto one person.
• Click ids captured on first touch and kept - including ones the browser stripped before your container ever saw the request.
• First-touch source and campaign, not just the last click that happened to be in the URL.
• Order and lifetime context where it exists.

Which one to pick

If your server-side setup is working and someone maintains it, enrich it. You get the identity benefit without a migration and without arguing with whoever built it. If your server-side setup exists mostly because somebody said you needed one, and nobody is quite sure what it does now, stream through Cookiebees and delete a moving part.

You can also start with enrichment and move later. The identity graph is the same either way - only the delivery changes.

What to do next

Find out whether anything in your current server-side container actually joins events to a person, or whether it just forwards. Most forward. That is the gap this closes.