Server-to-Server Integration with Server-Side Google Tag Manager

Last August, Google released Server-Side Tagging in Google Tag Manager 360. Though this platform is considered a “Tag Manager” and is conceptually similar to the web container, the implementation is entirely different. Server side tags are simply API endpoints for each marketing vendor that can be configured using the familiar Tag Manager 360 interface. Server-Side Tagging can be thought of as a publisher/subscriber tool. The server container listens for network requests (the publisher), packages those requests into events and then sends events to the appropriate subscribers, or “tags” based on the right criteria, or “triggers.” The tags in the server container can then send data to any of your measurement partners server-to-server.

At Square, we have chosen to integrate Server-Side Tagging with our Customer Data Platform. With this platform, we are able to track and aggregate user behavior across all Square apps and websites and appropriately enrich our events. Our Customer Data Platform (CDP) is the source of truth. To stay consistent with all our other data destinations (data warehouse, CRM, analytics tools), we needed to route data from our CDP’s tracking libraries to our marketing partners. This makes it easy for marketers to view data in one platform and expect identical data in another.

Early results from implementing Server-Side Tagging with our CDP have improved our ability to track conversions by 46.3%. We expect to see more improvements as we continue to add more server-side tags.

Key Benefits

Adding Server-Side Tagging in Tag Manager 360 to our marketing stack allows us to collect data from the website in a secure manner while improving data collection and enabling even enrichment. The key benefits of the server-side platform break down into five categories.

1. Security

As a payments company, Square takes security of our website seriously. This means that we significantly limit what tags we allow on squareup.com. Server-Side Tagging allows us to gradually move tags to the server-side where they are not a security risk. Whereas JavaScript tags placed directly on a website pose the risk of injecting malicious code or collecting sensitive information, tags placed in a server container in Tag Manager 360 cannot collect unintended data or manipulate the content or behavior of a webpage. They exist in an isolated environment. The only data they can capture is explicitly controlled by what we pass to the server-container.

2. Data Observability

Server-Side Tagging increases observability as it improves cookie durability and helps us retain data observability in a privacy compliant manner. Switching from client-side to server-side for a given conversion at Square enhanced our ability to track conversions on a partner platform by 46.3%. We expect larger lifts in the future as we implement vendor specific tracking suggestions.

In the near future, Server-Side Tagging will enable cross platform tracking for Square marketing teams. We expect a significant increase in our ability to track conversions as we leverage tracking for mobile events in addition to the pre-existing web events.

3. Privacy Controls

Similar to the security risks of having third party tags on the page, Server-Side Tagging allows us to better control privacy settings. Each layer of the Tag Manager 360 architecture gives users the ability to explicitly pass or restrict data. This can be controlled on the server-side client level or tag level. We also apply these settings in our CDP. Even without a CDP, Server-Side Tagging has some of this functionality with their template data storage API. Some server-side tags allow users to block personally identifiable information such as IP addresses.

4. Back-End Events

At Square, we provide a variety of services across individual applications combining online and offline data sources. Some of our critical events can’t be measured on the website directly. One important back-end conversion event we want to track is “first payment.” First payment marks when a Square Seller starts doing business on our platforms and provides a strong signal. Having a server-side container with a REST API endpoint makes it very easy to send this event to our server container and all the downstream tag vendors, which allows for better conversion optimization with the marketing partners.

5. A Familiar UI and Shared Ecosystem

Before we discovered Server-Side Tagging, we were considering building our own platform to send server-side event data to our marketing partners. This would have required a large engineering effort and added to our team’s on-call and maintenance duties in perpetuity.

With Server-Side Tagging comes a familiar UI for our marketing users maintained by Google. We have access to a shared ecosystem of tags created by marketing vendors. And for the smaller marketing vendors, it is simple to create tags ourselves. It only took two engineers two months to set up Server-Side Tagging for our CDP use case. Set up for most organizations who don’t have a separate CDP or other eventing system can be done in one day. It is as simple as adding a tag to client-side GTM and setting up a server container via a form on Google Cloud Platform. The overall cost to build and maintain Server-Side Tagging is very low compared to any homegrown solution.

Limitations

One challenge we have faced using our CDP data in Server-Side Tagging in Tag Manager 360 is that this doesn’t work perfectly with the Google Marketing Platform ecosystem. The ecosystem is closed and it has so far been difficult to understand exactly what APIs Server-Side Tagging expects. E.g., some event properties need to be nested under a user_data object in an event.

Furthermore, not every tag in the server container exposes an API to pass in custom fields like timestamp, or the ability to rename events. For a custom server-to-server set up, this is critical. Not every marketing vendor expects the same format of data. Google Analytics 4 requires all event names to be formatted in snake case whereas the Facebook Conversions API uses camel case. It is challenging to meet the requirements of both marketing vendors; this problem will compound as more server-side tags become available.

Since the server-side tagging ecosystem is younger, it is less developed than the client-side tagging ecosystem. For client-side tagging, most marketing partners have small JavaScript snippets that you can copy and paste into Tag Manager 360. There currently isn’t an equivalent solution for most marketing partners in the Server-Side Tagging world. This is due to the following limitations:

1. Limited tag templates: Server-Side Tagging has a Community Template Gallery, but it currently has only tags for 11 marketing partners. If you want to send events to a partner who isn’t supported, you need to build a tag template yourself that structures events and sends them to the partner’s marketing API.
2. Lack of a unified event structure: There isn’t a single, unified event structure that all tags can rely on. For example, the Google-defined Common Event Data does not include an event_time parameter, but the Facebook Conversions API tag expects this field. We suspect that server-side tags from Google generate an event_time within the tag without offering the option to pass this data. Differences like these make it difficult to plug-and-play with tags because they expect the events to be formatted differently.
3. Difficulties with identifiers: Most marketing partners rely on third-party cookies to identify users for retargeting and attribution. Unfortunately, you cannot make use of third-party cookies if you are sending server-side events to Server-Side Tagging. For these types of events, you will have to send hashed PII to marketing partners to accurately identify users.

Fortunately, there is a clear path to improvement for each of these limitations. The community template gallery has already grown from 0 to 11 tags in the past 7 months, and will continue to grow as more people adopt Server-Side Tagging in Tag Manager 360. We also expect this first wave of exploration to iron out some of the details around tag templates and event schemas. Finally, we expect most vendors to switch to first-party cookies rather than third-party cookies for retargeting and attribution.

How to set up server-to-server integration

We chose to deploy Server-Side Tagging in Tag Manager 360 with Docker containers on Cloud Run. Read more about our decision process. To integrate with our CDP, we wrote a custom Server-Side Tagging client which receives events from our CDP. Clients are a server container concept that takes incoming data, in this case from our CDP, and parses it into events for the server-side tags to read. We open sourced this client and it is adaptable to any engineering team’s use case. The template gallery does not currently accept clients, but you can manually import this from our GitHub repository. Download the template.tpl file. Create a new client template in your server container in Tag Manager 360. In the template settings, import the template.tpl file.

Once you have Server-Side Tagging deployed, add the Server-To-Server client template to your list of clients. If you also have a standard Google client, we recommend you set the Server-To-Server client as a higher priority and require an authorization header. That way, any requests in the measurement protocol format without an authorization header will be ignored and routed to one of the standard Google clients. This also ensures your server-to-server integration is secure.

Then, from your Customer Data Platform, create a new destination that sends post requests to your newly created server-side tagging container. Depending on what CDP provider you choose, the level of effort to create a new destination will vary. However, sending events to the Server-To-Server client is simple. Just send a POST request with the event as a JSON body. See the documentation as an example. To fit the schema that most tags will use, use the event fields in server-side GTM’s predefined common event data. Depending on how much control you have over your CDP, consider setting up retry logic based on the response codes and tag failure information returned by the client. With those considerations, you are ready to start sending events.