
Success in digital marketing largely depends on the quality of available data. Server-Side Tracking and the associated data enrichment offer the opportunity to gain deeper insights, make more precise decisions, and ultimately use advertising budgets more efficiently.
Optimization based on POAS instead of ROAS
A decisive advantage for companies is the optimization of POAS (Profit on Advertising Spend), which allows for a more precise evaluation of the profitability of marketing measures than the conventional ROAS (Return on Advertising Spend) model. This can be a decisive competitive advantage, especially when there are strong margin fluctuations in the product range.
Event Value Attribution
Business models with longer decision-making processes can particularly benefit from Event Value Attribution between various e-commerce signals such as (add_to_cart purchase). This provides a more accurate capture of the customer journey and helps maximize early purchase signals.
Business data
Furthermore, the integration of external business data, such as customer groups or scoring values from other systems, allows for improving the data situation and, for example, moving customers into specific target groups in real-time.
Technical Overview
What is a Server-Side Tag Manager?
A Server-Side Tag Manager (SSTM) is a solution for managing and controlling tags that are executed on a server instead of on the client (browser). Unlike traditional client-side tag managers, SSTM offers numerous advantages, including improved performance, increased security, and better data control.
Advantages of Server-Side Tag Management
- Improved performance: As tags are processed on the server, the loading time of the website is reduced.
- Security: Sensitive data is handled more securely as it is not processed directly in the browser.
- Data control: Better control over collected data and its forwarding to various tools and platforms.
- Data enrichment: from other sources
Server-side tag managers are advantageous for a variety of reasons. However, this article focuses on data enrichment.
Data enrichment in the Server Side Tag Manager
To enrich data in the Server Side Tag Manager, we need a data basis that is available in real-time. Firestore in Google Cloud provides this. The data is transferred from a data source like BigQuery to Firestore and later retrieved through a Firestore variable in the Server Side Tag Manager.

Use Case I: POAS instead of ROAS
While ROAS (Revenue on Ad Spend) is a common metric in online marketing that measures revenue in relation to advertising expenses, POAS (Profit on Ad Spend) takes a crucial step further. POAS focuses on actual profit and considers not only revenue but also the direct costs and margins of a product or service. This results in normalizing income in relation to expenses.
Target group: Google Ads ecommerce customers with very different margins in their product range.
Example:
- ROAS: If a company spends 100 euros on advertising and generates 500 euros in revenue, the ROAS is 5 (500 / 100).
- POAS: Here, the profit from the 500 euros revenue is considered after deducting costs (e.g., production, storage, or shipping costs). If the profit after costs is 200 euros, the POAS is 2 (200 / 100).
Calculation of POAS:
- Profit = (Sales price – VAT – Purchase price of the goods * (1 – Return rate))
Data sources:
- Selling price: From the customer’s shopping cart
- VAT: From the customer’s shopping cart
- Purchase price: From the shop system
- Return rate: Calculated from the shop system
Data sources for POAS calculation
In this specific case, the customer transfers the purchase prices of the products into their shop system. Since we have an internal data transfer from the shop system to BigQuery, it was easy to use the product data field from Shopware to perform the calculation.

Calculation in the Server-side Tag Manager
Now that the profit data is available in Firestore, it needs to be retrieved using a variable. There are already ready-made solutions for this, such as Sorteria from the sgtm-pantheon .
According to the Git repo, the naming is derived as follows:
Sorteria – Goddess of safety, and deliverance and preservation from harm. Like the goddess, this project provides security from end users to your sensitive value data (eg profit).
Among other things, Sorteria addresses the problem that profit values must be calculated per shopping cart item and then output as a total amount. Details can be found here.
Example:
- Article 1: Revenue 100€, Profit 50€, Quantity 1
- Article 2: Revenue 20€, Profit 13€, Quantity 2
- Total: Revenue 140€, Profit 76€
Once the value is fully calculated, it can be passed on to any conversion tag so that the modified value is then recorded. For analysis purposes, however, it is always recommended to track the normal revenue value in a parallel event, so that direct comparisons are always possible.
Result
For the customer, this creates the convenient situation that their POAS data, unlike sales, is normalized. This means that the result always represents the same amount of business value and this result doesn’t fluctuate between different products. This also makes life easier for the SEA manager because the customer’s specifications can be formulated more clearly in the future.
Use Case II: Event Value Attribution
Event Value Attribution is a process in which a value is assigned to certain events before a purchase. The goal is to distribute the sales value fairly across important pre-purchase events.
The aim of the procedure is to reward the bidding system appropriately for early events towards purchase, with approximately similar ROAS.
Target group: Google Ads customers with particularly long or complex purchase processes
Example calculation :
An online shop sells a product for €100. Over a 90-day period, Google Analytics measured 10 purchase and 100 add_to_cart events for the product. In the conversion measurement, the sales value should now be divided between add_to_cart and purchase events, so that the sales value is approximately €100.
10 (purchase) / 100 (add_to_cart) = 0.1 add_to_cart_rate
(add_to_cart_rate * value) / 2 (number of event names) = 5 € add_to_cart_value
value / 2 (number of event names) = 50 purchase_value

The figure shows how GA4 data from BigQuery can be used to make it available to Firestore. Data transfer to Firestore generally works with this Cloud Function .
Data preparation in BigQuery
To determine the add_to_cart_rate, it should be calculated for several levels. This is easiest in BigQuery with a SUM() OVER() window function. This way, we get not only the add_to_cart_ratio at the product level for each row, but also for the levels item_group_id, product_type, brand, and total.
SELECT *, -- item_group_id scope, SUM(add_to_cart) OVER(PARTITION BY item_group_id) AS add_to_cart_item_group_id, SUM(purchase) OVER(PARTITION BY item_group_id) AS purchase_item_group_id, -- product_type scope, SUM(add_to_cart) OVER(PARTITION BY product_type) AS add_to_cart_product_type, SUM(purchase) OVER(PARTITION BY product_type) AS purchase_product_type, -- brand scope, SUM(add_to_cart) OVER(PARTITION BY brand) AS add_to_cart_brand, SUM(purchase) OVER(PARTITION BY brand) AS purchase_brand, -- total scope, SUM(add_to_cart) OVER() AS add_to_cart_total, SUM(purchase) OVER() AS purchase_total FROM all_items GROUP BY ALL;
In order to get the most relevant number possible as the final add_to_cart_ratio, we search for it using a CASE WHEN statement.
SELECT *, -- purchase_add_to_cart_selected CASE -- product scope WHEN add_to_cart 10 AND purchase 10 THEN purchase_add_to_cart_product -- item_group_id scope WHEN item_group_id IS NOT NULL AND item_group_id != '' AND add_to_cart_item_group_id 10 AND purchase_item_group_id 10 THEN purchase_add_to_cart_item_group_id -- product_type scope WHEN product_type IS NOT NULL AND product_type != '' AND add_to_cart_product_type 10 AND purchase_product_type 10 THEN purchase_add_to_cart_product_type -- brand scope WHEN brand IS NOT NULL AND brand != '' AND add_to_cart_brand 10 AND purchase_brand 10 THEN purchase_add_to_cart_brand ELSE purchase_add_to_cart_total END AS purchase_add_to_cart_selected FROM calculations;
The CASE statement ensures that a level is only used if more than 10 add_to_cart actions are present. If the action isn’t sufficiently available for the product, item_group_id, product_type, and brand levels, the total is used, which then represents the shop level.
Result
The method is useful for customers when there is a longer customer journey before the purchase or when a device change without login is likely.
This gives e-commerce companies the opportunity to incorporate early purchase signals into the bidding system as relevant rewards, without having to live with the fear of creating large-scale false incentives, as the value distribution takes place dynamically based on the old transaction data.
Conclusion
Data enrichment in the Server-Side Tag Manager offers significant advantages for digital marketing companies. By focusing on POAS instead of ROAS, companies can more accurately measure the true profitability of their marketing efforts, which is particularly crucial for product ranges with widely varying margins. Event Value Attribution allows the value of pre-purchase events such as add_to_cart to be appropriately considered, allowing longer and more complex customer journeys to be better mapped.
Technically speaking, the use of a Server-Side Tag Manager offers improved performance, increased security, and better control over collected data. The integration of real-time data sources such as Firestore and BigQuery allows complex calculations to be performed directly in the Tag Manager and efficiently incorporates external business data. Tools like Sorteria facilitate the calculation and aggregation of profit values at the product level.
For SEA managers and marketing teams, this means a more precise data foundation on which to base informed decisions. Advertising budgets can be used more efficiently, as campaign performance evaluation is based on actual profits rather than just revenues. The dynamic value distribution minimizes the risk of misaligned incentives and maximizes the benefit from early purchase signals.