It has been more than two years since we first explained server-side tagging. In this article, we would like to follow up by looking at some alternatives and comparing the pros and cons.

Client-Side Tagging

First off, let’s recap how standard tagging is done.

First, the browser makes a request to a web server eg. www.mywebsite.com. The web server then returns the content in form of HTML:

After the browser has loaded the content, it then makes several connections (in the background) to third-party endpoints such as analytics and marketing:

The thing to note here is that the browser (aka client) is requesting a page from mywebsite.com (first party) but in the background it’s also connecting directly to third-party endpoints. This is known as cross-site. Today’s browsers have built-in tracking prevention or adblocker extensions installed, which means these cross-site connections can be blocked, resulting in loss of analytics or marketing conversion tracking.

First-Party Mode (FPM)

Next, we want to look at a new offering from Google called First-Party Mode (currently in beta).

First we must understand that web servers often sit behind a network infrastructure such as a Content Delivery Network (CDN) or a Load Balancer to improve content delivery to users around the world. To visualize:

FPM allows the IT administrator to configure the infrastructure so that it routes the same-site same-origin (exact same domain eg. www.mywebsite) connections to Google servers:

Notice that, for Google services, the browser is now making connections to the first-party domain of www.mywebsite.com via a subfolder of /metrics. This method is less likely to be affected by browser tracking prevention or adblockers.

Notes:

• FPM uses the network infrastructure where its job is just routing the connections. Typically that is all it can do.
• As illustrated above, this setup requires IT administrators to be involved. Considerations include the load management, maintenance, and the added IT cost which can be tricky to estimate the first time.
• This is a Google offering so it only works for Google endpoints. We have a feeling that other analytics and marketing vendors may follow in the same direction soon.

Server-Side Tagging (SST)

In contrast, SST uses a full-fledged server where it can do not only routing, but also more advanced operations such as data redaction/modification/consolidation and more.

In addition, more vendors are supporting SST endpoints now such as Facebook Conversion API (CAPI), which mean it can support non-Google tags:

Notes:

• Unlike FPM, SST uses same-site cross-origin (subdomain eg. sgtm.mywebsite.com) connections. This method has a higher chance of being impacted by browser tracking prevention compared to FPM because the subdomain could be a different IP address than then requested domain eg. www.mywebsite.com.
• Just like FPM, SST requires IT administrators involvement for the server setup. However, they do not need to be involved so much in the application programming side as this can be done by installing Server-Side Google Tag Manager.

One of the most useful and attractive features of SST is the ability to consolidate data connections. Looking at the diagram above, you can see that the browser is making FOUR connections.

With careful planning and tags setup, SST can consolidate supported tags into just ONE connection:

This has several benefits including:

• Reducing the CPU usage and data bandwidth of the browser which in turns improving user experience, especially for users with low-powered slow-connection mobile devices.
• Allowing you to precisely control the data sent to external endpoints (eg. preventing PII).

Take note that this approach requires quite some effort — planning, setup, and training — especially when marketing tags are typically handled by a different team, often times an external agency.

Server-to-Server (S2S)

Looking at all the diagrams above, you’ll notice that the browser is the one making all the connections.

We have no control over users’ browsers and the settings that they have on. This means loss of data is expected. For analytics and marketing conversion tracking, we have to live with the data discrepancy.

However, there is one method where we can adopt to improve this drastically. Instead of the browser making the connections:

We can use the web server, which we have full control of, to make the connections:

S2S can give close to 0% discrepancy. However, take note that:

• This requires the website developers to write the codes in the web server.
• This only works for page-load events (eg. form submission thank you page, purchase confirmation page, or any page loads). In other words, it only works when the browser is requesting for content from the web server. It doesn’t work for actions that happen solely on the browser side such as clicks, scrolls, element visibility, and other JavaScript events.

Talk to us if you are interested in exploring this method for your websites.

Comparing The Options

There is no one best option that works for everyone. We need to do the assessments based on several factors including:

• How comfortable you are with the unavoidable data discrepancy
• How important it is for you to recover some of the loss of data to improve data quality ● IT resource availability and additional cost

You can use this comparisons to weight the pros and cons and find the best balance:

Final Thoughts

While the same-site same-origin approach of FPM is very attractive, the ability for SST to control and consolidate the data cannot be ignored. I hope to see these two technologies merge into one so that we don’t have to make the hard decision of choosing one.

Also, I hope to see more vendors start to adopt the FPM approach so that we can bring more external connections to first party.

Ayudante aims to provide data accuracy, comprehension and consolidation, and most importantly, tangible insights for businesses. Get in touch if you’d like to find out more.

‍

‍