So where is the non-stop demand for a Server-Side Tag Management solution?

In part one of my stream of consciousness *seriously, I have not proof-read this AT ALL! I laid out the current state of browser tracking, and the market conditions that are seemingly influencing the move away from traditional tag and pixel-based tracking techniques and towards the server-side alternative. I wanted to use this space to memorialize my own assessment of the key factors are blocking the otherwise ideal solution fit that is SSTM. I’ll start by highlighting the issues anyone familiar with SSTM, or those that have endeavored to do a quick Google search, are already informed of. This includes technical complexity, cost, and measurement parity. Much is already written about these challenges, but I’d like to add my own $0.02 to the conversation as I am of the belief that each potential hurdle has a weighted impact on adoption based on a myriad of factors associated with each organizations profile and respective needs. I’ll then end this chapter by drawing attention to what I think presents as the largest challenge to SSTM adoption that everyone talks about but nobody talks about (yes you read that correctly). Having only a single year of exposure to this market and being well outside the ten-thousand hour exposure for expertise, I don’t claim to have ANY of the answers here. The following is simply a collection of my thoughts from research, prospect discussions, and various inclinations that I have put to paper for the purpose of discussion and debate.

Challenge 1 - Technical Complexity

I think the perceived “technical complexity” of SSTM is a bit overstated. Taken at face value, the concept does appear to be far more technical demanding than the simple act of adding an HTML tag to a web-page via a content management system or traditional tag manager. SSTM introduces hosting requirements to capture and syndicate the event stream, events need to be “triggered” from the associated pages which often introduces developer input, and each integration needs it’s mappings configured and maintained to align with their respective API requirements. The truth however is that most SSTM’s have abstracted a lot of the technical complexity away from your base user and surfaced an interface that is in some ways familiar to toolsets currently in use. Providers like Stape.io abstract resource scoping tasks away from IT and ensure that the right GCP setup is spooled up to handle event volumes at a reasonable cost, while offerings from Taggrs, MagicPixel, or CommandersACT provide interfaces that allow for various levels of data mapping and integrations configurations. If “technical complexity” is such a red herring, then why is it still highlighted as a challenge? From what I can gather there are several situations where the promises of SSTM start to introduce a technical complexity that current offerings struggle to address fully.

I believe that perceived technical complexity with SSTM’s is a natural byproduct of its own promise. Investing in SSTM is not simply an exercise in future-proofing your ad-tech setups. As Google continues to pick the proverbial cookie can down the road, companies are incentivized to take the wait-and-see approach towards saga management given the associated change costs (more on cost later). Instead, many of the companies I speak with are only contemplating an SSTM switch because doing so introduces added benefits like fine-grained control over what data is syndicated to consumers, data enrichment for more precise measurement and analytics insight, and data consistency across their toolsets through a single collection endpoint. With those goals in mind, companies are not simply seeking functional parity with client-side tags, but are approaching SSTM as a component to a transformation in their data handling posture. In response, those SSTM’s the even attempt to address these needs do so with feature-sets that surface the required extensibility in a developer-oriented design. It is in harnessing these advanced capabilities that the SSTM implementations complexity profile begins to emerge as heavily dependent on an organizations technical resources.

Challenge 2 - Cost

Google Tag Manager (legacy client-side) is free.

That’s a tough hill to climb for any company humoring the adoption of a new piece of tech, especially as more and more digital marketing teams are being tasked to do more with less budget. Various analyst reports I’ve come across highlight CMO’s reducing mar-tech budgets upwards of 20% as incumbent investment decisions either proved ineffective, or became “orphaned” as their users left the company. Additionally, as mentioned previously, Google continues to delay the deprecation of third party cookies thereby removing the most critical compelling event surrounding server-side transitions. For those companies willing to make the early investment into their digital marketing future, calculating the return on said investment should be weighted against a few key factors that I believe are most critical in the decisioning process (in no particular order).

Trust - Does the organization have full faith in the reporting results surrounding ROAS? A class action lawsuit was recently filed against Meta for their overcharging of advertisers with regards to impressions on their site. By leveraging simple pixel-based tracking, most companies lose the ability to accurately align attribution metrics to true site traffic. Obviously calculating the return on SSTM investment needs to be done like any insurance policy, basing the potential over-spend against platform cost and management.

Strategy - As much as the industry hypes the value of more data, and better analytics, both concepts are altogether worthless unless an organization has a plan on how to leverage it. We know that SSTM’s can gather more dat due to their resiliency to browser restrictions, but has the organization put a value on that additional 40% bump? Is the current sample size large enough to infer an effective strategy? Does my customer data strategy provide surface a potential for more granular retargeting techniques?

Risk - Third party tags bring sites down. This is a fact. It happens. Often. I am usually keen to not injure up digital boogeymen as I think they are at times more bedtime story than real threat. For instance, you might have noticed I didn’t call out 3rd party data use in the “trust” section. This was by, design as any third party data consumer has acceptable use policies that clearly outline how syndicated data can and will be used by them. I personally feel that the scary tales of third parties selling visitor data gathered through tags are a bit overblown. That being said, I am intimately familiar with the impact that an offending third party tag/script can have on a mission critical digital property, and for some companies, the loss of that property can have significant monetary impacts. That impact however is not the same for everyone, so again the risk attached to site resiliency must be metered.

Challenge 3 - Measurement Parity

SSTM’s don’t have the ability to capture the cookie info needed to properly relay view-through behavior. Well that’s not entirely true. Most SSTM’s can’t relay view-through behavior for unknown visitors. Meaning that this can only be properly attributed to ad behavior after the visitor has authenticated. Moving to an SSTM also results in an initial measurement shock to companies as a myriad of factors result in seemingly new behavioral patterns. When evaluating the SSTM switch, companies need to weigh the investment against the loss in anonymous view-through signaling, and investment into strategizing against unfamiliar interaction patterns. Similar to the previously mentioned challenges, the issue of measurement parity only becomes prominent in organizations whose digital marketing and analytics strategies maintain a mid to high level of tactical sophistication.

Challenge 4 - Change Management

Given the perceived technical complexity involved in the setup, configuration, and maintenance of an SSTM, organizations see a future where tag management as owned by both marketing and IT. With this new paradigm comes operational updates to the protocols and procedures associated with the deployment of the server-side equivalent of the tag. Within larger organizations these changes are often less intrusive as many enterprises maintain something of a “shadow IT department” within their individual marketing units. This hybrid team structure not often seen in small and mid-sized organizations however, presenting as a far more onerous task that is more of a distraction than value add.

This last challenge nicely segues into what I think is the largest challenge to SSTM that everyone talks about, but no one talks about. My attempt at clever wordplay is not unintentional nor for cheap laughs, but to emphasize just how pervasive this issue is in the resistance to SSSTM adoption. As I’ve researched the space, spoken to current customers and prospects alike, I hear the same aversion to tag management (specifically SSTM) over and over again:

It complicates the IT-Marketing communication channel.

The issue is that marketing owns access to the toolsets typically associated with tags and therefore the critical configuration information required for the connections to take place and the integrations to deliver on the intended measurement use cases. At the same time, IT ends up owning the keys to the SSTM itself in an effort to ensure that the platform is operating properly, event capture overruns don’t run wild, and customizations for advanced use cases are created and deployed successfully. While some SSTM’s have begun implementing certain operational controls and governance capabilities, these are in large part “bolt-on” functions serving as band-aids to the root problem and more often than not failing to provide direction on best practices for utilizing said capabilities. Some of my favorite quotes from a rather LOOOOOONG Reddit thread on the topic capture anecdotal conversations I’ve personally had on the topic:

“…what i hate more is the interactions i have to have with marketing teams regarding this tool.”

“The problem is that there are a whole slew of tools out there that are marketed to marketers that make it sound like they can hold the keys to everything.”

And my favorite:

“Build a better relationship with marketing because they’ll eventually find a way to accomplish their goals without you.

…their eng department wouldn’t help. Own the interaction and handle it. All they should be providing is a CSV of events they need tracked.”

From a technical standpoint current SSTM tooling works well if your marketing team is also the IT team or has direct, exclusive access to a “shadow IT group” under them. But this is rarely the case, and even in these situations, issues around communicating requirements, needs, and the resultant tracking are often missing. In my opinion, what is needed in the space is an SSTM that puts the needs around COMMUNICATION and GOVERNANCE at the forefront of their product focus. The industry doesn’t need a more “dumbed down” SSTM for marketers, nor does it need more super advanced, developer centric features for use cases that serve a single customer on the summer equinox, when mars is in retrograde (though as a developer, that flexibility would be nice).

One common thread you might infer from looking at these challenges and how I feel they are weighted by those considering the move to SSTM, is their alignment to the enterprise consumer. These are organizations with large, well-trafficked digital footprints, large marketing staff, multiple brands, sophisticated digital marketing strategies, and significant digitally influenced revenue streams. This would imply that the SSTM market is in need of an enterprise SSTM offering as this group is currently under-served through current offerings.

As you might be able to tell from the declining writing quality, it’s getting a bit late on my side of the planet. In my next stream of consciousness I’ll endeavor to outlay my thoughts on the functional and non-functional requirements needed to address the challenges I’ve laid out here. Not to make too large a plug, but I will also be highlighting how MetaRouter is uniquely evolving as it grows into the role of the predominant enterprise SSTM offering in the market.

‍