BigCommerce Catalyst and Makeswift vs. a Backend-Agnostic FrontendBigCommerce has spent the last two…
Server-Side Tracking Done Right: Measurement Belongs in the Component Schema
Server-Side Tracking Done Right: Measurement Belongs in the Component Schema
Open the network tab on most storefronts and you find the same story: 25 to 40 third-party tags loaded in the <head>, each one a script that runs before the shopper sees a product. Analytics, two ad pixels, a heatmap tool, a consent layer, a session recorder, three "growth" snippets nobody remembers adding. Every tag is a request, a parse, and a main-thread block. The measurement stack has quietly become one of the heaviest performance liabilities on the page, and the data it produces keeps getting thinner as browsers tighten cookie and script rules.
There is a cleaner model, and it has two moves. First, measurement runs on the server, not in 30 browser scripts. Second, tracking is declared in the component schema, next to the component that emits the event, instead of being wired up as a separate tag project. Both moves matter. Server-side is the transport; the component schema is where the events actually get their meaning.
The real cost of client-tag sprawl
Client-side tag management felt like a win a decade ago: marketing could add a tag without a deploy. The trade came due later. Each client tag has three recurring costs.
- Performance. Third-party scripts compete with your own JavaScript for the main thread. A single tag manager container pulling in a dozen vendors regularly adds 300 to 700 ms to Time to Interactive on mid-range mobile.
- Data quality. Ad blockers, ITP, and consent gating drop a meaningful share of client-side events before they ever leave the browser. You are not measuring reality, you are measuring the subset of users who did not block you.
- Governance drift. Tags accumulate. Nobody owns the full list. The container becomes a place where old pixels never die and PII leaks are one misconfigured variable away.
None of this is a vendor problem. It is structural to putting measurement in the browser as loose scripts.
What server-side actually moves
Server-side tagging moves the collection and fan-out of events from the browser to a server endpoint you control. The browser sends one first-party request to your own domain; the server enriches it and forwards clean events to the destinations that need them, Google Analytics, an ad platform, a warehouse.
The landscape here is real and worth naming honestly. Google offers server-side Google Tag Manager (server-side tagging, "SST"). Cloudflare Zaraz runs third-party tools off the browser main thread at the edge. Both are legitimate ways to reduce client load. What neither solves on its own is the second half of the problem: where do the events come from, and who keeps them consistent as the storefront changes? That is a component question, not a transport question.
Why measurement belongs in the component schema
In a composable headless frontend, the storefront is built from components with typed schemas. A product card, a add-to-cart button, a filter, a checkout step: each is a component with a defined contract. That contract is exactly the right place to declare what the component measures.
Instead of a separate tagging project that guesses at DOM selectors, the event lives next to the component that emits it:
defineBlock('ProductCard', {
props: { productId: string, position: number },
tracking: {
view: { event: 'product_view', server: true },
click: { event: 'product_select', server: true,
payload: { productId: 'props.productId',
listPosition: 'props.position' } },
},
})When the component renders or is interacted with, the platform emits a structured event to the server endpoint, not to a browser tag. Because the payload is typed and bound to props, it cannot silently drift when a designer moves the card into a new section. The event schema is part of the component contract, versioned with it, reviewed with it. This is what component-schema analytics means in practice: the schema is the single source of truth for both rendering and measurement.
The server-side event shape
On the server, every component emits the same normalized shape, regardless of which backend or destination sits behind it:
{
"event": "product_select",
"occurred_at": "2026-07-29T09:14:22Z",
"session_id": "s_9f2c...",
"source": { "component": "ProductCard", "schema_version": "2.3.0" },
"context": { "locale": "de-DE", "channel": "web", "consent": ["analytics"] },
"payload": { "productId": "SKU-4471", "listPosition": 3 }
}Because collection is first-party and server-side, this event survives ad blockers and script-level consent gating (you still honor consent, it is carried in context). It arrives once, clean, and can be fanned out to any destination without a new browser tag.
Where Zaraz, Google SST, and first-party data fit
The two models are not either/or. The component schema decides *what* and *when*; the server layer decides *where*.
| Layer | Job | Owner | Failure mode if skipped |
|---|---|---|---|
| Component schema | Define events, bind typed payloads | Engineering, in the component contract | DOM-selector guessing, events drift on redesign |
| Server endpoint (first-party) | Collect one clean request per event | Platform | Ad blockers and ITP eat your data |
| Server tagging (Google SST / Zaraz) | Enrich and fan out to destinations | Platform / edge | Client main-thread stays heavy |
| First-party data store | Retain events you own, model later | Data team | Vendor lock on your own behavior data |
The payoff is first-party data you actually own, collected from your own domain, defined by your own components, and portable to whatever destination or model you choose next.
Agent traffic finally becomes measurable
There is a 2026-specific reason this matters. A growing share of storefront traffic is not a human with a browser running your tags. It is an agent, a shopping assistant, a Claude or ChatGPT session hitting your endpoints on a user's behalf. Client-side tags do not fire for these visitors at all, so in a browser-tag world agent traffic is simply invisible. When measurement lives in the component schema and emits server-side, the event fires whether a browser executed a script or not. You can see agent-driven product views and selections as a first-class channel instead of a gap in the funnel.
A short migration checklist
- Inventory the
<head>: list every client tag and its actual owner. - Stand up a first-party server endpoint on your own domain.
- Move analytics and ad destinations behind server tagging (Google SST or Zaraz as edge transport).
- Declare events in component schemas, typed and bound to props, not via DOM selectors.
- Carry consent in the event
context, enforce it server-side. - Delete the client tags you just replaced. Do not leave them running "just in case".
Takeaway
Server-side tracking is not just about moving a tag manager to a server. Done right, it is two decisions: measurement runs on the server, and events are declared in the component schema where they are versioned, reviewed, and impossible to silently break. The result is a lighter <head>, first-party data you own, consent you can actually enforce, and agent traffic you can finally see. If you want the shortest path to that setup on an existing backend, that is what the Laioutr Frontend Management Platform is built for, and the tracking and analytics product page shows how it fits a composable storefront. For the wider context on where composable is heading this year, see Composable commerce trends 2026.