How Data Flows Through Your Seers' Server-Side Container

Every event that enters the Seers server-side container passes through a structured processing pipeline before any data reaches a third-party platform. Understanding how that pipeline is organised, and what each of its components does, helps you configure your container correctly, troubleshoot data issues, and make deliberate decisions about what information each vendor receives.

Overview of Server-Side GTM Assets

Server-side GTM introduces a specific set of asset types. Each plays a distinct role in how incoming data is received, shaped, and forwarded. The table below summarises these assets alongside a concrete example of each.

Asset type	Description	Example
Client	Receives incoming requests from the browser or app and converts the raw measurement protocol data into a standardised, human-readable event format that the rest of the container can work with. See the default in this GTM documentation page.	Google Analytics
Event data	The structured data object produced by the client, it describes the user interaction and carries all the parameters associated with it.	event_name=page_view page_host=example.com user_id=123.123
Transformation	Modifies the event data object before it reaches tags, either for all tags or selectively. Transformations are the primary mechanism for enforcing data governance, such as removing or anonymising fields.	A PII filter that strips sensitive identifiers from the event data before forwarding
Variable	Reads and reformats values within the event data, either extracting existing fields or deriving new ones from them.	Converting a plain email address into a SHA-256 hashed value for privacy-safe audience matching
Trigger	Evaluates conditions against the event data and controls whether a specific transformation or tag should execute for a given event.	Fire the GA4 tag only when event_name=page_view
Tag	Takes the processed event data and sends it to a specific third-party destination in the format that the vendor expects.	A GA4 tag that packages event data and dispatches it to the Google Analytics database

The Three-Stage Processing Pipeline

When an event arrives at the Seers.ai server container, it moves through three sequential stages before any data leaves your infrastructure:

1. Clients: When a raw HTTP request arrives at the container (originating from a web page, mobile app, or other source), the client is the first component to handle it. Its job is to interpret the request's measurement protocol and translate it into a consistent, structured event data object that the rest of the container can process uniformly, regardless of where the request originated.
2. Transformations: once the event data object exists, transformations give you full control over its contents before anything is sent outward. A transformation can add fields, remove them, reformat values, apply conditional logic, or aggregate data points. This is where privacy enforcement happens in practice: fields containing personally identifiable information can be stripped or hashed before the data reaches any tag, ensuring that only what is genuinely needed reaches each downstream platform.
3. Tags: At the final stage, a tag takes the cleaned, transformed event data and formats it according to the requirements of a specific third-party platform, such as Meta Conversions API, Google Ads, or LinkedIn, then dispatches it. Each tag handles one destination, and multiple tags can fire from a single event.

Two additional asset types operate across all three stages:

• Triggers evaluate conditions defined against the event data and determine whether a particular transformation or tag should run at all for a given event. They give you precise routing control without duplicating logic across multiple tags.

• Variables read values from the event data object, or derive new ones from it, and make them available for use inside transformations and tags. A variable might extract user_id from the event, hash an email address, or combine two fields into a single formatted string.

  

State Management: Stateless by Design

One of the most important architectural differences between server-side GTM and web GTM is how they handle state, that is, whether information from one event is available when the next event is processed.

In web GTM, the browser's data layer acts as a persistent store. Values pushed into it from an earlier event remain accessible to tags fired by subsequent events, right up until the page is reloaded. This means a user's login status recorded during a login event is still visible when a purchase event fires a few minutes later.

Server-side GTM works differently. Each incoming request is treated as entirely independent. The container has no memory of previous requests, there is no shared data layer, no session store, and no carry-over of values between events. The only data available when processing a given event is what arrives within that event's own request payload.

Achieving Statefulness When You Need It

Although server-side GTM is stateless by default, there are scenarios, particularly data enrichment and cross-event user identification, where linking information across requests adds real value. Two established approaches make this possible within the server-side model.

1. Connecting to an External Server-Side Database

The container can query an external data store, such as BigQuery, Firestore, or a custom API, using a key carried in the incoming event (for example, user_id). The database returns the corresponding record, and the container attaches that data to the event before forwarding it to any tags.

For instance, when a purchase event arrives carrying a user_id, the container can look up that user's customer_tier or predicted lifetime value in your CRM database and include those fields in the outgoing event, even though they were never part of the original browser request. This allows advertising platforms to optimise toward richer, more meaningful business signals rather than raw conversion counts.

• Strengths: Access to comprehensive, centralised data; suitable for large datasets; values can be updated server-side without any client changes.
• Considerations: Introduces a network call on every relevant event, which adds latency; requires maintaining and securing the database infrastructure.

2. Reading State from a First-Party Cookie on the User's Device

The Seers container can write a first-party cookie to the visitor's browser, for example, a session_id or visitor_id. Because that cookie is set by your own server (not by a JavaScript tag), it is classified as a true first-party cookie and is automatically included in every subsequent request the browser sends to your server endpoint. The container can then read that cookie value and use it to link requests from the same user across multiple events.

• Strengths: No additional network round-trip required; straightforward to implement; the identifier persists across sessions without relying on third-party storage.

• Considerations: Cookies have a size ceiling of roughly 4 KB, so they are suited to identifiers and lightweight flags rather than rich data payloads. Cookie values should never contain sensitive personal data, and their use must be governed by your consent configuration in the Seers.ai CMP.

  

Seers and first-party cookies

When the Seers container sets a cookie via a same-origin endpoint, that cookie is not subject to Safari's Intelligent Tracking Prevention restrictions. This makes it significantly more durable than a cookie set by a JavaScript tag, and a reliable basis for cross-session user identification within the bounds of your consent framework.

Consent applies to the state, too

Both approaches to statefulness, external database lookups and cookie-based identifiers, involve processing user data. The Seers.ai container's native integration with the Seers.ai CMP ensures that enrichment and identification logic only executes when the visitor's consent permits it.