Those who follow the constant evolution of digital marketing have probably noticed that tag management is repeating many of the same lessons learned by the web analytics community over a decade ago. In the early days of web analytics, the prevailing debate was “tags vs. logs.” As the sector started maturing, the marketplace picked the ultimate winner.
Log-based vendors relied on server logs for their data collection whereas tag-based solutions like Omniture and WebSideStory (both now part of the Adobe Marketing Cloud via acquisitions) relied on tags for data collection. Tags provided better data because they collected the data from where it mattered most: directly from browsers of site visitors. Getting the data from the source allowed for more accurate and timely data collection and as a result, log-based solutions fell by the wayside in favor of tag-based ones. By 2002, all new vendors realized the benefits of the tag-based approach and adopted this methodology. Tags won.
What does this have to do with tag management? Well, it turns out the tag management space is currently going through a similar debate. The debate of the client-side vs. the client-server method.
The client-server model works by making a server-call on each page to an application server. The job of the application server is to decide which tags need to be loaded on which pages. A request is then sent back to the web client, instructing it to load the appropriate tags.
The client-side model works by eliminating the application server from the process. Logic is placed in a JavaScript file, which can be downloaded from any fast server through a content delivery network (CDN). As the visitor traverses through the site, the appropriate tags are loaded.
The Market is the Ultimate Judge
While vendors from each side can boast about their architecture and methodology, there’s one fact that cannot be disputed and clearly states why the client-server model is becoming obsolete. In the last two years, many vendors have entered the space and not a single one has adopted the client-server model. New vendors have the advantage of studying existing vendors and adopting the best technology. In all cases, new tag management vendors have adopted the client-side methodology. Think about it. Those who know the space the most and are banking millions of dollars – vendors – are all adopting the client-side approach.
But why are new vendors, after careful analysis of the market, deciding to adopt the client-side methodology? The reason is that client-side is better, faster and more stable than its client-server counterpart. Here are some of the high-level advantages.
Client-side is Where the Data is
The primary difference between the two models is that in the client-server model, the logic of which tags to load sits on an application server in the cloud. In the case of client-side, this logic sits on the page, where data is richest. By putting the logic client-side, you can take advantage of all the data points available on page: meta tags, JavaScript variables, cookies, and more. At the application layer, you have access to only limited information such as page URL or page title. In the client-server model, in order to take advantage of a richer data set, programmers would have to pass all the data to the application server, which adds more latency and weight to the request. This could also have negative privacy implications if the data transmitted is sensitive.
Reduced Point of Failure
One of the many advantages of the client-side model is that it can completely eliminate the application server call altogether. The application server call is an additional point of failure that’s introduced on every page. Imagine having to make a round-trip call on every single page view for every single visitor just to determine which tags to load? This is both an extra step and a point of failure that’s introduced on every single hit. It’s not efficient.
Client-Side Logic is Faster
This goes without saying of course. When the logic is in the JavaScript, it will run much faster. In our tests, the client logic takes approximately 4-5 milliseconds, depending on the type of logic. No application server can make the round-trip in the same amount of time. In our tests we see this logic take approximately 200ms.
Myths debunked
Those still supporting the client-server model are defending it by making claims, some of which are listed here.
- File Size
One of the main arguments against the client-side model is that by adding the logic into the JavaScript, the file size gets bigger. The ultimate file size is dependent on a number of factors and not all vendors are the same. In the case of Tealium, one customer is using our solution to manage almost 200 tags. The customer’s JavaScript is less than 10KB. This is hardly a bloated file size. Enterprise solutions like Tealium allow clients to manage thousands of tags with ease. - Campaign Visibility
Another argument often used against the client-side model is that since the logic is in the JavaScript, then competitors can see a list of your vendors. Again, not all client-side solutions use the same code, but in case of Tealium, the vendor names are not displayed and replaced with an ID that’s unique to each client deployment.Having said that, anyone can use any number of tag inspection tools such as Ghostery to see which tags are loading on which pages. This is the case in both the client-side and client-server models. So there’s no real advantage that the client-server model provides in this case. - Client-Side is a Container Tag
Another misconception in the market is that client-side solutions are tag containers. The idea behind a tag container is that all tags are placed in a container and all tags load regardless of the rule. This is absolutely untrue and reflects the lack of knowledge by those making the claim. Deep conditional logic can be placed for each tag. For example, a Google AdWords tag can be programmed to load on the confirmation page only if the traffic came from AdWords. - Testing
Another common but incorrect assertion is that the client-server model is better suited for running testing tool in a ‘flicker-free’ fashion. This is false. You can easily use the client-side model to run testing tools such as Adobe Test & Target in a flicker-less mode. In fact, we recommend you download our new white paper on this topic, “Improving Testing & Optimization through Tag Management,” to learn more about our testing deployment capabilities for yourself.
What About the Server-to-Server Model?
A third method used in tag management is what’s referred to as the server-to-server model. In this method, a pixel request is sent into a server, from which the data is bifurcated and then transmitted to different vendors. This model has some merits and limitations that can be discussed in a separate blog post. In fact this model can be complemented with the client-side methodology for certain conditions – i.e. reducing the number of pixel calls for vendors supporting this model or providing a solution for non-JavaScript environments. Tealium supports both models, but for the purpose of this blog post, the discussion is centered on the limitations of the client-server methodology.
History Repeating Itself
The web analytics space carries many lessons with it that apply to what is currently taking place as a debate in the tag management space. Key among them is the type of technology adoption by vendors. By following the vendors, the market can clearly see which methodology is winning due to its superior capabilities and benefits. Just as web analytics vendors abandoned log-based systems in favor of using tags for data collection over a decade ago, we’re seeing tag management vendors adopting the more data-centric client-side methodology. These are clear signs that the client-server model will become obsolete in the not-so-distant future.
