Tag Management System = JavaScript Deployment Engine = Commodity

The Tag Management System (TMS) industry is growing at an exponential rate and there is no shortage of venture capital money and interest within the market. In fact, the largest TMS vendors have recently received influxes of cash greater than 10 to 15M+ each. The market has grown to the point where three of the largest technology companies (Adobe, Google, and IBM) in the world have created solutions and are giving them away for free.

Unfortunately, the “value” proposition that I continuously hear from the TMS vendors:

• We can deploy tags and pixels quickly
• We can help you avoid IT

Congratulations, you have a JavaScript deployment engine. If this “value” proposition remains consistent across the industry, how do you differentiate in a very competitive market where margins will face downward pressure in the near future? This story is already playing out in the digital analytics industry. See Google’s impact on the margins of SiteCatalyst. For the web analytics industry, data collection has become a commodity.

The main problem with the majority of the tag management systems today is that they were born out of the web analytics industry. This singular focus on tags for the web analytics industry is holding the industry back. I recognize that the TMS players can deploy marketing pixels and create hacks for deploying optimization solutions (damn flicker), but once again, the focus is on JavaScript deployment. There is definitely a strong ROI and TCO reduction story with the above approach, but I believe there is a significant opportunity cost for focusing exclusively on page level JavaScript injection.

The web analytics industry is a fraction of the total digital advertising spend and a tiny percentage of the revenue of the BI/CRM industries. Will focusing on JavaScript deployment close that gap? No. Even in concert with digital analytics and optimization, will this become a 10B industry? No.

To avoid the continued commoditization of this industry, a fundamental shift needs to happen quickly. Data exchange between the following mess of technologies needs to become a significant part of a customer’s strategy and the overall discussion within the industry.



This data exchange needs to be based on standards (Justin Cutroni is a key driver of this) and have consistent definitions around metrics, data elements, and how we define the customer in an omni-channel world. The creation of a data dictionary for digital marketing technologies will not only help with the governance and standardization of how data is collected, but it creates a foundation for data exchange between the marketing solutions pictured above. Through server direct integrations, it will allow customers to leverage the data and services that the above solutions offer. The reality is that most organizations are not going to bet their entire business on a Marketing Cloud or Enterprise Marketing Management Suite. Best of breed and point solutions will always exist because of the gaps in an uber platform approach. With that said, the data dictionary and data exchange architecture will make the integration of data faster and simpler. Lastly, the quicker we can move to a server direct model and lessen our dependence on tags, it will improve the overall customer experience and mend the fractured IT and Marketing relationship.

From a business value perspective, personalization, retargeting, DMP integration, and real time ad buys are a few examples of the marketing tactics that will benefit from this platform. What if you could exchange behavioral data from Google Analytics or SiteCatalyst in real time with Marin or Kenshoo to adjust your bidding logic? Your internal story to the executive team becomes a lot more compelling: “As a result of these adjustments to the bid logic, it yielded a X% increase in our ROAS.” Another simple, but valuable example can be found with your optimization strategy. What if you can leverage digital intelligence data from Webtrends and alter a Monetate personalization campaign within a visit? Sure, the individual solutions can scrape the pages for the same data, but that is not very efficient and it is still tag focused. This new data exchange architecture will put you in a position to quantify and internally communicate the ROI and TCO reduction story. Once again, what is the opportunity cost of not implementing this architecture?

In summary, the TMS industry can continue down the path of commoditization or it can elevate the conversation and focus on the strategic value of the platform. If you want to discuss tags and JavaScript deployment with Keystone Solutions, sure, we can help you. But, the leaders in digital are creating architectures that leverage the benefits of all of their existing digital marketing investments and Keystone is helping them achieve this today.

Contact me to find out how we are helping the largest brands in the world with this strategy and architecture.
email: chris@keystonesolutions.com
twitter: @chrisolenik

Building a Data Driven Culture: Process Integration

Often, the start of any new analytics practice is centered around technology, I blame the vendors for this. It’s in your vendors best interest that you get up and running as quickly as possible, the faster you deploy their solution, the faster they get paid.


This isn’t necessarily a bad thing, implementation has to be completed for your organization to have access to all the rich data you need to start building a data driven culture. However, what many companies fail to realize is that implementation is not limited to a technology task. Implementation also involves integrating your analytics practice into the fabric of your organization.

How many times have you heard something like this, “I’m so frustrated, our product team launched a new feature this morning and the CEO is demanding an analysis. We don’t even have the correct tracking on the new feature, I just found out about it this morning!!!”?

In our excitement to deploy our shiny new analytics solution, we rushed into the build without reading the instructions first. Had we slowed down at bit, we would have realized that one of the critical steps in the process was to ensure that the solution was integrated into our existing processes.

When I was running the analytics practice for 28 corporate brands at Spark Networks, one of the first things I did was to identify the process we followed for managing product enhancements. Internally, we used a solutions called JIRA to manage our software development lifecycle. It was critical that I fully understood the process for how new features were rolled out to our sites, from ideation to launch, and how our systems supported that process.

It became clear to me that I needed to integrate my analytics practice into the product request process that we managed within JIRA. The simple task of adding a few required fields to a JIRA request, made my life so much simpler and I never again had to tell the CEO, “we aren’t tracking that new feature yet.”

When a product manager submitted a feature request, they were now required to complete two additional fields in their request:

1) Is analytics required for this feature?
2) If yes, what are the requirements, if no, why not?

This simple update to the process forced product managers to stop and think about analytics as part of their process for rolling out enhancements to the site.

This example is only one place that I integrated analytics into the process and there are many, many more that I won’t go into detail on but to get you thinking, I also integrated my practice into:

  • Bi-Monthly Executive Staff Meeting
  • Creative Request Process
  • Email Marketing Process
  • Engineering Bug Tracking
  • Quarterly Earnings Calls
  • Product Launch Post-Mortem Reviews
  • And Many, Many More

Take the time to look around your organization and identify the areas that are critical to running the business, find ways for integrating your analtyics practice into these areas and you will take a huge step forward in building a data driven culture.

Of course, to accomplish this, it takes adoption and buy-in from across the organization, so I will address the importance of user adoption in the next part of this series.

TMS: Too Much Smoke

This is not a Tag Management 101, or a set of golden rules, or even a new revolution…again kind of post.  This is a cut through the smoke and mirrors to get down to the fundamentals of what the various Tag Management Systems in the market today can provide to your business.

 

We have worked with our clients to implement a variety of tag management systems in both simple and extremely complex environments, and as part of every engagement we spend the time to make sure that the introduction of a TMS into their digital ecosystem is part of a larger governance plan.   But before we start doing any work on the planning and implementation we take the time to make sure the client understands exactly what it is they have purchased.

 

If you just read the marketing propaganda you will get the impression that the TMS you just signed the contract on is the greatest thing since…

Better than sliced bread

…. the in car DVD players….way better than sliced bread.   Before we dive into what a Tag Management System can do for you, lets talk about what they can NOT do for you.

 

TMS is not Superman, it can not leap buildings in a single bound, there is no heat vision, or any other super powers either.   It also will not:

  • Eliminate the need for technical resources on your team to properly implement and maintain your tagging infrastructure.
  • Magically tag your site and align everything with your business goals, hopes, and dreams.
  • Free you from the critical need to do exhaustive QA and validation of new and existing tags.
So what does it do?
What would you say...you do here?

You have just purchased a very very nice…..wait for it…javascript deployment tool.  Sexy right?  Can’t you see people flocking to the streets clamoring for their very own javascript deployment tool?  No?  Neither can I.   But now that you have your own javascript deployment tool..er.. Tag Management System we can talk about the three main reasons that people need or want a TMS.

Speed:  You just want to go fast.  You want to reduce the length of time to not only deploy new code and tags to your site, but to gain the speed and agility to make code fixes when bad code makes it way to the site.

Reliability:  You want to bring consistency and reliability in the code,  You want the system you choose to have the highest level of availability and uptime to make sure that you are not introducing a system into the mix that is not going to stand up to the volumes of data that you will be passing through it.

Control:  Sometimes… IT is not a pleasant group to work with, and sometimes you feel like you are dealing with  “IT” and not the Technology team.  And once they figure out that they are losing control or some of their control you and your team you might have a bit of a fight on your hands.  Tag Management Systems also makes it easier, not easy, but easier to replace your analytics vendor if you choose to at some point in the future.

 

So what?  What does this mean to all of you out there that has purchased a Tag Management System or are planning to?  What is the real benefit of going through the effort to implement an enterprise class Tag Management System?  Here is the typical deployment cycle in a large enterprise without a TMS:

Before

And here is the typical deployment cycle after a full TMS implmentation:

Before you say, I thought I was getting the ability to instantly push new tags to my site, these diagrams map out the entire lifecycle of the deployment of tags.  From the initial request to business approval to code,QA, and deployment.   The part of these two diagrams I want to make sure you see is that the QA section does not and can not go away.  It is true you have the ability to push code changes to your site as frequently as you would like, with amazing speed.  That also means you now have the ability to push really crappy code to your site with amazing speed.   Think about that for a minute and then think about who on your teams you trust to get the ability to with a click of the mouse the ability to bring your website to its knees with sub-standard code if proper QA and testing has not been done.   Trust me, you do not want to be this guy.

This guy skipped the QA part, pushed crappy code and was fired.   Don’t be this guy.

 

If you have purchased a TMS, or you are thinking about a TMS, you need to take a step back and evaluate your specific needs and business problems that you are hoping to solve.  At Keystone Solutions we have worked with a large variety of clients in all the major verticals and the various Tag Management Systems and would be able to sit down and review your plans to help you map out a solution that will not only give you the speed, reliability, and control you desire, but the peace of mind that you have thought through all of the pitfalls and common mistakes out there.

 

 

 

Solving the Optimization Puzzle

Instead of testing for the sake of testing, you should have a methodical plan and strategy. Too many times, instead of thinking through and understanding the impact, we default to Band-Aids (quick fixes) but you need to step back and ask yourself “why?”Puzzled path #1

 

Leveraging both quantitative and qualitative data not only paints a holistic picture of your audience but also provides the insight you need to predict behavior. Ultimately, you need to be able to answer the “why?” – the root cause or reason behind the behavior.

 

Before starting any optimization test, the first thing you should do is take time and research who your audience is. Let’s say you run a test and the control wins, are you able to answer why the control won from a behavioral standpoint? If not, then you just wasted time and resources because the test did not provide any insight.

 

For example, we worked with a client who was sending Yahoo search traffic to a poorly performing, generic landing page. The quantitative data was there, but it wasn’t until we truly focused on the specific audience, that the landing page experienced a significant lift in conversions.

 

By collecting qualitative data from a competitive intelligence service, we were able to discover the demographics, lifestyle, and persona of the vistiors coming from Yahoo. Before, with the generic landing page, Yahoo users experienced a disconnect when coming to the page because it didn’t resonate with them, the message just wasn’t compelling. However, by incorporating the knowledge gained of visitors coming from Yahoo into the landing page experience, the landing page experience was optimized and conversion rates soared.

 

We were able to help answer the “why” and build tests off of a strong hypotheses from both quantitative and qualitative data. I’m not saying to drive your tests or create experiences solely off of qualitative data; rather, you should bridge quantitative with qualitative.

 

Take the time and know who your audience is by answering questions like:

 

1) What are the key pages people are visiting?

 

2) Once on the site, what actions are people taking?

 

3) What are the primary traffic sources?

 

4) What are the key demographics of site visitors?

 

5) Are there any social media trends?

 

6) Are visitors coming from specific geographic areas?

 

7) Can we develop unique personas of site visitors?

 

By layering qualitative data on top of your quantitative data, you can effectively show relevant content to your audience. Your audience is like a puzzle. If you try targeting with only half the puzzle completed, you may get some success, but you’re targeting half blind and it may result in wasted time, money, and resources. However, if you piece together the entire puzzle, the message you send is relevant and is more likely to move the needle. Keep in mind, there are several puzzles – don’t try to fit your audience into just one. You can’t expect what worked for one channel or vertical to work the same for all others. Traffic sources behave differently because the motivation is different.

 

You could produce a winning experience that works for your display channel but that doesn’t mean you will see the same results when tested against your search traffic. Why? Because visitors who come from display typically show different motivation from those vistiors coming from search. Just because an experience works for one channel doesn’t mean you should roll it out 100% – test it first.

 

Once you’ve solved the puzzle, you can show relevant content, answer the “why”, and predict behavior. You’ll spend less time, money, and resources to get the results you want.