Skip to content

Data flows within server-side GTM

Server-side Google Tag Manager processes data in three main stages:

  1. Clients: Interpret raw incoming requests (from web, mobile, etc.) and translate them into a standardized event data format for consistent processing.

  2. Transformations: Modify, adjust, or redact event data, ensuring only relevant and authorized information reaches tags. This stage is crucial for privacy (e.g., PII anonymization) and data quality, allowing for redaction, enrichment, reformatting, aggregation, and conditional logic.

  3. Tags: Compile the refined event data and dispatch it to third-party destinations like analytics, advertising, or CRM platforms, adhering to vendor-specific formats.

Two auxiliary assets facilitate this process:

  • Triggers: Define conditions under which transformations or tags execute, enabling precise data routing based on event data.

  • Variables: Parse and manipulate event data, extracting values, combining data points, or applying formatting for use in transformations and tags.

Data flow

Overview of server-side GTM assets

Asset type Description Example
Client Translates the incoming event request and its measurement protocol data into a humanly readable naming convention. See default in this GTM documentation page. Google Analytics
Event data Data provided by incoming request about the interaction event_name=page_view
page_host=example.com
user_id=123.123
Transformation Changes the event data object for some/all tags. Useful for data governance. PII filter that removes certain kinds of data from the event data
Variable Parses the event data to create new data or represent existing data differently Convert a plain email-address into a hashed email-address
Trigger Evaluates if certain conditions are true and then triggers a transformation of a tag If the event_name=page_view then trigger the Google Analytics tag
Tag Compiles (transformed) event data and dispatches the data to the database of a tool Google Analytics tag sending event data to the Google Analytics database

State management: stateless

The fundamental distinction between server-side Google Tag Manager (GTM) and web-based GTM lies in their state management.

In web GTM, the data layer maintains state, allowing each event to access properties from previous events unless they are overwritten or a page reload occurs. Conversely, Server-side GTM is stateless by design. Each event arrives as a new request, meaning information from one request cannot be used in another. All available data is contained within the event data object.

Consider the illustration below where a user triggers a page view, then logs in, and finally makes a purchase before reloading the page. With web GTM, data from previous events persists in the data layer until a page reload. However, in Server-side GTM, there is no data layer or inherent state. The server only has access to the data directly included in the current event request.

Data flow for login, purchase and reload

Server-side Google Tag Manager (GTM), while typically stateless, can maintain state for data enrichment and linking user actions. Two key methods are:

  1. Connecting to an external server-side database:

    • How it works: Server-side GTM queries an external database (e.g., BigQuery, Firebase) using a key from an incoming request (like user_id) to retrieve additional data (e.g., customer_level), enriching the event before forwarding.
    • Advantages: Rich, centralized, scalable, and secure data.
    • Considerations: Potential latency, database management, and cost.

  2. Storing dense information in a user's device cookie:

    • How it works: Server-side GTM sets a cookie on the user's browser (e.g., session_id), which is automatically sent with subsequent requests, allowing server-side GTM to read and use this data for stateful processing.
    • Advantages: Low latency, simpler implementation, client-side persistence.
    • Considerations: Data size limitations (approx. 4KB), privacy regulations, security (avoid sensitive PII), and user behavior (cookies can be blocked/deleted).

Consider the illustration below, which expands on the previous user journey. In it, the server-side GTM uses the user_id parameter in the purchase event to make a request to the external customer database. The customer database returns the customer_level in exchange for the user_id. Now the server-side GTM can also make use of the customer_level in the purchase event even though it was not included in the original event data.

Enhanced data flow for login, purchase and reload