This is an excerpt of a masterclass presented by Simo Ahava, Partner at 8-bit Sheep and Co-Founder at Simmer. Connect with Simo on LinkedIn and Twitter.
The rules of the game are changing for digital marketing
“The only social responsibility of business is to use its resources and engage in activities designed to increase its profits … so long as it stays within the rules of the game, engages in open and free competition, without deception or fraud.”
The world has changed a little since Milton Friedman made this comment, although the concept seems to be alive and well if we look at the profitability of companies such as Facebook and Google.
By staying within the “rules of the game”, both Facebook and Google have been able to build hugely profitable operations. However, as the technical landscape has continued to transform and the rules of the game have increasingly failed to protect consumers, new data privacy regulations have been brought in, such as GDPR in Europe and CCPA in California. With the rules of the game changing, Facebook, Google, and other online advertisers are faced with a new challenge in order to maintain their pursuit of maximum profitability for their company.
Apple, meanwhile, has introduced its own regulations to protect customer data. Overall, it is now more difficult to share data amongst unrelated parties to find profitable users.
How to adapt to the new rules of the game
Most consumers – who until now may have been unaware of the amount of their data that was being shared and with who – would agree with the new regulations that have been put in place to protect their data. However, digital marketers who have been relying on this user data might feel like their business is about to fall into the abyss.
But before you start to panic, let’s put this into context …
- Firstly, it wasn’t third-party data sharing that was getting you good results – it was good marketing practices; identifying the right target, creating good products, having the best content, etc.
- If you think it’s bad for you, imagine being an ad platform! Ad platforms have a social responsibility to adjust to the new “rules of the game.”Even they have already started making adjustments though. Google’s FLoC (Federated Learning of Cohorts) is expected to work almost as well for advertisers as the current model, and Facebook’s Aggregated Event Measurement seeks to replace the lost third-party data in a similar way.
- Remember that future results aren’t guaranteed, and there are much bigger world factors affecting marketers than cookies.
- As marketers, advertisers, data geeks, etc., it is our social responsibility to adjust to the new rules of the game.
So, how do you do this? Moving to first-party data collection is inevitable and GA4 is one of the first viable platforms to switch. Data Driven’s new Google Analytics 2021 course will tell you all you need to know about GA4 and how to move your clients over to this platform seamlessly.
The other option to ensure all the data you are collecting is first-party is by using something called server-side tagging for all your critical measurement pixels.
How does “normal” tagging with GTM work?
Regular tagging involves sending data to third-party servers like Facebook, Google Ads, etc in the form of http. On a more granular level, you are sending a request to Google’s CDN (Content Distribution Network) for them to send you the Analytics.js or gtag.js, libraries (JavaScript libraries that are necessary for you to track Analytics). Similarly, for Facebook, you would need to download the fbevents.js library from Facebook’s CDN.
So, even before you have sent them any hits, you are requesting resources from these third parties.
The problem with the http method is that it is fragile and vulnerable to being misused: For example, man-in-the-middle attacks or cross-site scripting. One of the big vulnerabilities to tracking is how these third parties are using the users’ browsers as a cookie store. The cookies (like bits of data stored about activity on a website) are essential to the web as they enable states to persist from one page to the next, without using storage, so that they can track user activity across different sites. Without cookies, every page would be completely isolated, and we wouldn’t know when users have gone from one page to another, even within the same site. But, by storing this data in the browser, it’s hard to control what happens to that data and that is why browsers are moving away from allowing third-party cookies.
Google’s FLoC model seeks to recreate this by only using data from its own platforms. This is feasible for Google as it has a range of platforms that most users use regularly e.g. Google Search, GMail, YouTube.
The other problem with sending data from third-party platforms is that when the data is sent to the vendor, it is not only receiving the data you sent but is also pulling additional data on the user from the browser. The site might not even realize that this is happening.
All of these problems – cookie stores, cross-site tracking, tracker pings, XSS attacks and personal information leaks – are a result of the system of sending data via http.
What is server-side tagging and how does it work as a solution
Having established that the current system of tagging is far from perfect, we still need to send data to the Facebook Pixel and Google Ads and Analytics to get all the data we need for our advertising campaigns. However, with server-side tagging instead of sending the data directly from the platform of the third party, we insert a barrier as an intermediary. This barrier is called a server container and prevents one side from seeing the data on the other side.
What are the features and benefits of Server-Side Tagging?
Having this container gives you a number of additional benefits:
- Hit validation – Currently, if you send data to Google Analytics that it doesn’t recognise as a hit, it will discard the data without informing you. With this method, the server container will inform you of the issue so that you can fix it before sending it to Google.
- Stream consolidation – Instead of sending the same hit to different vendors – for example, when someone adds something to a cart – you send the same event to FB, Google Ads and Analytics. With stream consolidation, you only send one event to the server container and the container will take care of distributing the event to the different platforms. This consolidation of streams also serves to improve performance on the client side by reducing the load on their servers.
- Anonymization – You can anonymize the source of the data completely. Currently, Google offers an anonymization service where it hides the last character of the user’s IP address. However, even though it doesn’t show on reports, the full IP is still stored on Google’s servers. When you use a server container, the vendor naver gets to see the IP address, it only ever sees the IP of the container (unless you choose to send the user IP).
- Consent management – This can be handled directly in the server in a more elegant way. Instead of creating a complex list of triggers and clauses for your tags, you can put the logic in once and let the container deal with it.
- Tracking protection protection – Server-side tracking enables you to get back a lot of information that may have been blocked by intelligent tracking prevention, which specifically targets JavaScript libraries. Because server containers run outside of JavaScript, you can circumvent these tracking protection mechanisms. You will also find that you can sidestep Ad blockers in the same way.
- Full ownership and control of the data entering the server environment – This helps to avoid all the potential misuse of data. Because you no longer have to download Google or Facebook’s libraries, you keep control of the data at all times.
- Helps with Content Security Policies – this is a way for the web servers and websites to determine what kind of third-party endpoints are allowed to be communicated with. Any endpoint added to the CSP makes the CSP weaker, so when you start moving the library loads to the server the data is consolidated and your CSP is shorter.
- Process keys, secrets and credentials out-of-sight of the browser or device – This means you can do API calls in the server, like credit card transactions, using only the User ID. Because the browser has no visibility into the transaction, you don’t need to worry about the details being leaked.
- Utilize HTTP responses – you can write cookie set headers to override tracking blockers and access cookies over their actual lifetime rather than the one set by the browser.
How to set up your server-side container
Anyone can set up server-side tagging right now – it’s all there inside GTM and ready to use. You can find a step-by-step set up guide in the Masterclass along with some tips for enhancing security.
What are the downsides of server-side tagging?
While server-side tagging offers numerous benefits to advertisers, it is not without its drawbacks. As a custom-made solution designed to keep things within the “rules of the game”, there are inevitably some associated downsides and limitations.
- Circumventing Ad / Content blockers – When you use server-side tagging, you can change the name of a website that is blocked by browsers with your own server name to circumvent the browser.
There are ethical concerns to doing this and if your methods are detected it may lead to damage to your brand.
- Opaque data collection – The browser no longer knows where the data that it is sending is going to. As we have seen with consolidation streams, you can take the hit and send it to a number of different vendors. By not allowing the browser transparency into this, you again may be exploiting a data privacy loophole which could be closed further down the line. You can help clients to trust you by being open and transparent about what you are doing with their data.
- No built-in consent management – Currently there is no way to manage consent through the API, but hopefully this will change in the future.
- Cost – Running this server will cost around 120 euros per month for 3 app instances in Google Cloud, which is the recommended minimum. However, you should think about this as an investment. The cost will go up depending on traffic, but you can disable App Engine Request logging to eliminate the logging charges.
- Poor availability / documentation of server-to-server endpoints – There is poor availability of server-to-server endpoints. So far, Google still has a Beta label on its server site tagging although Facebook can already be run through a server-site tagging configuration and works pretty well.
- Third-party cookies won’t work – although this is one of the reasons you have set up the server side tagging, it can prove problematic for applications which need third-party cookies to work, such as DoubleClick. In these cases, some other form of endpoint identification needs to be used. For example, Facebook uses identity hashing with hashed email addresses.
Many of these limitations and concerns may be addressed a little further down the line, but this solution is a very effective way of keeping your business within the rules of the game in the midst of an increasingly regulated advertising space.
To find out more about server-side tagging, check out our Masterclass on the subject. You also have these great resources for some extra insight:
Simo’s blog on server side tagging