Server-Side Tracking

Measure what matters.
Server-side.

Reduce measurement gaps. Respect consent. We plan measurement from the browser to the destination system and document which events arrive and which do not. Browser rules, declined consent and missing events remain limitations, however good the architecture is.

Review tracking View our work

The endpoint belongs to your website

The browser first sends permitted events to an endpoint on your own domain. There they are processed and forwarded to the agreed destination systems. Server-set cookies are used only within the agreed scope and in line with consent.

This is a clear interface between website and data providers, with documented rules. It does not make measurement complete: browsers still impose limits, consent may be missing and some interactions never reach the endpoint.

From consent to the destination system

Consent is recorded in the browser and evaluated before sending. The first-party endpoint forwards permitted events to the server container. There, the signals are checked again and prepared for GA4, Google Ads, Meta CAPI or LinkedIn CAPI.

Azure Front Door or Cloudflare Workers can serve or forward the endpoint. We identify the server container's actual runtime separately in the architecture.

What we check in tracking

We trace a selected event from the first request to the destination system. We distinguish between technical transmission, consent and business meaning.

Consent Mode v2We check ad_storage, analytics_storage, ad_user_data and ad_personalization. This includes initialisation order, asynchronous updates, wait_for_update, the region configuration, and Basic and Advanced Consent Mode. We check destinations outside Google separately.

Conversion APIsWe check transmission to Google Ads, Meta CAPI and LinkedIn CAPI. If standard tags are insufficient, we develop and test sandbox-compatible templates for the server container.

Attribution in SPAsWe trace the first campaign contact and subsequent route changes. Permitted click IDs are stored depending on consent. Tag order and deduplication prevent incorrect attribution.

Events with meaningAn event that has technically been sent is not yet a reliable metric. We compare names, triggers, parameters and destination systems with the business definition.

Server logs and browsers measure different things

A Matomo import from server logs evaluates requests that reached the server or the edge. It can work without a browser script or tracking cookie. However, clicks or form steps that do not generate a logged request remain invisible.

Browser-based tracking can capture these interactions. It remains dependent on consent, browser rules and correct tag execution. Neither architecture alone demonstrates data protection compliance. Data minimisation, legal basis, retention and access must be defined to suit the project.

Tracking is treated like code

We export container states and store them under version control. Changes are visible as differences and reviewed before publication. The approved version can then be assigned to a release.

Checks include preview, test events and comparison in the destination system. Tokens, internal identifiers and payload data remain outside exports and public documentation.

Implemented for iF Design

For iF Design, we implemented server-side tracking via a first-party endpoint and a server container. The architecture combines Consent Mode, SPA attribution and conversion APIs. A sandbox-compatible template handles requirements beyond standard tags. Container states are versioned and reviewed before publication.

Delivery at the edge

The tracking endpoint is part of the platform architecture. The respective service pages describe how Azure Front Door and Cloudflare Workers handle routing, protection and delivery.

Azure Front DoorRouting, WAF, caching and TLS for applications on Microsoft Azure.

Cloudflare WorkersCode and forwarding at the edge with Cloudflare.

The result of the tracking check

We clarify the task in conversation. A subsequent proposal defines the sample, required access, deliverables and costs.

Documented flowYou receive the event and consent flow with measurement conditions, system boundaries and unavailable evidence.

Prioritised measurement gapsWe classify gaps by their impact on attribution, consent and business analysis.

Verifiable stepsFor the agreed events, we document test data, expected signals and checks in every system involved.

Next actionsYou receive recommendations, effort estimates and verification criteria. Where implementation makes sense, we define its scope in a proposal.