Category: Tag Management

Tag Management, Technical/Implementation

Single-Page Apps: Dream or Nightmare?

Posted on by Josh West

A few months ago, I was discussing a new project with a prospective client, and they described what they needed like this: “We have a brand new website and need to re-implement Adobe Analytics. So far we have no data layer, and we have no developer resources in place for this project. Can you help us re-implement Adobe Analytics?” I generally avoid projects just like this – not because I can’t write server-side application code in several languages, but because even if I am going to write code for a project like that, I still need a sharp developer or two to bounce ideas off of, and ask questions to find out where certain files are located, what standards they want me to follow, and other things like that. In an effort to do due diligence, I asked them to follow up with their IT team on a few basics. Which platform was their site built on? Which programming languages would be required?

When they followed up by saying that the site was built on Websphere using ReactJS, I was sure this project was doomed to failure – every recent client I had worked with that was using either of these technologies struggled mightily, and here was a client using both! In addition, while I understand the premise behind using ReactJS and can generally work my way through a ReactJS application, having to do all the heavy lifting myself was a terrifying thought. In an effort to do due diligence, I agreed to discuss this project with some members of their IT team.

On that call, I quickly realized that there had been a disconnect in how the marketing folks on the project had communicated what the IT folks wanted me to know. I learned that a data layer already existed on the site – and it already contained pretty much everything identified in the solution design that needed to be tracked. We still had to identify a way to track a few events on the website (like cart adds), but I felt good enough about the project to take it on.

This project, and a handful of others over the past year, have challenged some strong opinions I’ve held on single page applications (SPAs for short). Here are just a few of those:

  • SPAs have just as many user experience challenges as the page-based applications they are designed to replace.
  • SPAs are present a major measurement challenge for traditional analytics tools like Adobe or Google Analytics.
  • Most companies move to an SPA-based website because they look and sound cool – they’re just the latest “shiny object” that executives decide they have to have.

While I still hold each of these opinions to some degree, the past few months have given me a much more open mind about single-page applications and frameworks like React or Angular. Measurement of SPAs is definitely a challenge – but it’s not an insurmountable one. If your company is thinking about moving to a single-page application, you need to understand that – just like the site itself is going to be fundamentally different than what you’re used to – the way you measure it will be as well. I’d like to offer a few things you’ll want to strongly consider as you decide how to track your new SPA.

A New Data Architecture

In many ways, SPAs are much better equipped to support a data layer than the old, Frankenstein-ish website you’re moving away from. Many companies I know have such old websites that they pre-date their adoption of a tag management system. Think about that – a tool you probably purchased at least six years ago still isn’t as old as your website itself! So when you implemented your TMS, you probably bolted on your data layer at the same time, grabbing data wherever you could find it.

Migrating to an SPA – even for companies that do this one page at a time – requires a company to fundamentally rethink its approach to data. It’s no longer available in the same ways – which is a good thing. Rather than building the data layer one template at a time like in the past, an SPA typically accesses the data it needs to build a page through a series of APIs that are exposed by back-end development teams. For example, data related to the authenticated user is probably retrieved as the page loads from a service connected to your CRM; data relevant to the contents of a customer’s shopping cart may be accessed through an API integrated with your e-commerce platform; and the content for your pages is probably accessed through an integration with your website CMS. But unlike when you implemented your data layer the first time – when your website already had all that data the way it needed it and in the right locations on the page – your development team has to rethink and rebuild all of that data architecture. You both need the data this time around – which should make collaboration much easier and help you avoid claims that they just can’t get you the data you need.

Timing Challenges for Data Availability

As part of this new approach to data, SPAs typically also introduce a shift in the way they make this data accessible to the browser. The services and APIs I mentioned in the previous section are almost always asynchronous – which introduces a new challenge for measurement teams implementing tracking on SPAs.

On a traditional website, the page is generated on the server, and as this happens, data is pulled into the page from appropriate systems. That data is already part of the page when it is returned to the browser. On an SPA, the browser gets an almost “empty” page with a bunch of instructions on where to get the relevant data for the page; then, as the user navigates, rather than reloading a new page, it just gets a smaller set of instructions for how to update the relevant parts of the page to simulate the effect of navigation.

This “set of instructions” is the API calls I mentioned earlier – the browser is pulling in user data from one service, cart data from another, and product/content data from yet another. As data is made available, it is inserted into the page in the appropriate spot. This can have a positive impact on user experience, because less-relevant data can be added as it comes back, rather than holding up the loading of the entire page. But let’s just say it presents quite a challenge to analytics developers. This is because most tag management systems were built and implemented under the assumption that you’d want to immediately track every page as it loads, and that every new page would actually be a new page. SPAs don’t work like that – if you track an SPA on the page load, or even the DOM ready event, you’re probably going to track it before a significant amount of data is available. So you have to wait to track the initial page load until all the data is ready – and then you have to track subsequent page refreshes of the SPA as if a new page had actually loaded.

You may have experienced this problem before with a traditional website – many companies experiment with the idea of an SPA by trying it out on a smaller part of their website, like user authentication or checkout. Or you’ve maybe seen it with certain third-party tools like your recommendation engine – which, while not really an SPA, have similar timing issues because they feed content onto the page asynchronously. The good news is that most companies that go all-in on SPAs do so all at once, rather than trying to migrate single sections over a longer period of time. They undertake a larger replatforming effort, which probably makes it easier to solve for most of these issues.

Figuring out this timing is one of the most important hurdles you’ll need to coordinate as you implement tracking on an SPA – and it’s different for every site. But the good news is that – as long as you’re using one of the major tag management systems – or planning to migrate from Adobe DTM to Launch as part of your project – it’s the hard part. Because every major TMS has a solution to this problem built right in that allows you to fire any tag on any event that occurs on the page. So your web developers just need to notify your analytics developers when the page is truly “ready.” (Again, if you’re still using Adobe DTM, I can’t emphasize strongly enough that you should switch to Launch if you’re building an SPA. DTM has a few notable “features” that pose major problems for SPAs.)

A New Way of Tracking Events

Another major shift between traditional websites and SPAs is in how on-page events are most commonly tracked. It’s likely that when you first implemented a tag management system, you used a combination of CSS selectors and custom JavaScript you deployed in the TMS, along with events you had your web developers tag that would “trigger” the TMS to do something. Because early sales teams for the major TMS companies used a pitch along the lines of “Do everything without IT!” many companies tried to implement as much tracking as they could using hacks and one-offs in the TMS. All of this custom JavaScript may have had the effect on your TMS of moving all your ugly, one-off tracking JavaScript from your website code to your TMS – without making the actual tracking any cleaner or more elegant.

The good news is that SPAs will force you to clean up your act – because many of the traditional ways of tracking fall down. Because an SPA is constantly updating the DOM without loading a new page, you can’t just add a bunch of event listeners that bind when the page loads (or on DOM ready). You’d need to turn off all your listeners on each page refresh and turn on a bunch of new ones, which can be tedious and prone to error. Another option that will likely not work in every case is to target very broad events (like a body “click”) and then within those handlers just see which element first triggered the event. This approach could also potentially have a negative impact on the user’s experience.

Instead, many teams developing an SPA also develop a new model for listening and responding to events that, just like the data layer, can be leveraged by analytics teams as well.

The company I mentioned at the beginning of this post had an entire catalog of events they already needed to listen for to make the SPA work – for example, they needed to listen for each cart add event so that they could send data about that item to their e-commerce system. The e-commerce system would then respond with an updated version of all the data known about a future order. So they built an API for this – and then, the analytics team was able to use it as well. Without any additional development, we were able to track nearly every key interaction on the website. This was all because they had taken the time to think about how events and interactions should work on the website, and they built something that was extensible to other things on the website than just its core purpose.

This is the kind of thing that a company would almost never do with an old website – it’s a large effort to build this type of event service, and it has to be done inside an old, messy codebase. But when you build an SPA, you have to do it anyway – so you might as well add a little bit more work up front to save you a ton of time later on. Developers figure these kinds of things out as they go – they learn tricks that will save time in the future. SPAs can offer a chance to put some of these tricks into action.

Conclusion

There are many other important things to consider when building a single-page application, and it’s a major undertaking that can take longer than a company plans for. But while I still feel that it’s more difficult to implement analytics on an SPA than any other type of web-based application, it doesn’t have to be the nightmare that many companies encounter. Just remember to make sure your development team is building all this new functionality in a way that everyone can benefit from:

  • While they’re making sure all the data necessary for each view (page) of the website is available, make sure they provide hooks so that other teams (like analytics) can access that data.
  • Consider the impact on your website of all of that data showing up at different times.
  • Develop an event model that makes it easy to track key interactions on the site without relying on fragile CSS selectors and DOM hacks.

A few weeks ago at our ACCELERATE conference, I led a roundtable for the more technical minded attendees. The #1 challenge companies were dealing with when it came to analytics implementation was SPAs. But the key is to take advantage of all the opportunities an SPA can offer – you have to realize it gives you the chance to fix all the things that have broken and been patched together over the years. Your SPA developers are going to spend a lot of time getting the core functionality right – and they can do it in a way that can make your job easier, too, if you get out in front of them and push them to think in innovative ways. If you do, you might find yourself wondering why some folks complain so much about tracking single-page apps. But if you don’t, you’ll be right there complaining with everyone else. If you’re working with SPAs, I’d love to hear from you about how you’re solving the challenges they present – or where you’re stuck and need a little help.

Photo Credit: www.gotcredit.com

0
Tag Management

Adobe Launch Linking to DTM

Posted on by Eric Peterson

Earlier this week I mentioned a feature that allows you to link your Adobe Launch files to your old DTM files. Some have asked me for more details so you now get this follow-up post.

Essentially this feature allows you to make the transition from DTM to Launch easier for sites that were already implemented with DTM. How does it make it easier? Well, let’s say you are an implementation manager who spent years getting DTM in place across 100+ sites that are each running on different platforms and managed by a multitude of internal and external groups. That isn’t a process that most people get excited to revisit. To avoid all that, Adobe has provided this linking feature. As you create a new configuration in Launch those Launch files can just replace your DTM files.

Let’s imagine that you have a setup where a variety of sites are currently pointing to DTM code and your newer implementations are pointing to Launch code. This assumes you are using one property across many sites which may or may not be a good idea depending on your needs. You could visualize it like below where the production environment for both products is used by different sites.

Once you enable the linking, the production code is now shared between the two products. The new visual would look something like this:

It is just a one-way sharing, though. If you were to link and then publish from DTM that would not impact your Launch files. It would impact the DTM files. It’s best to get to the point where you have published in Launch and then just disable the DTM property.

How to Enable Linking

Here is how it is done if you are starting from a brand new property in Launch. You should do these steps before any site is using the Production embed script from Launch. This is because Adobe will give you a new embed code during this process.

  1. The new property will already have Environments enabled (this may be new, I was under the impression you had to create the environments from scratch). Find your Production environment, consider the warning above, and, if all is well, delete it.
  1. Once deleted then hit the Add Environment button and select Production. This will allow you to add a new Production environment to replace the one you just deleted.
  2. As you are configuring the environment  just toggle the “Link DTM embed code” on and paste in your DTM embed code.
  1. Save your settings and if everything checks out ok you will be given new Production embed code. This embed code is what you would use for any production sites.

Other Considerations

  • The embed code will change every time you delete and add a new Production environment. You’ll want sites with the Launch embed code to have the latest version. I haven’t tested what will happen if you try to implement a site with the old Production embed code. It makes me uneasy, though, so I would just avoid it.
  • Note that in my picture above I only show the Production environment being shared. This actually brings up an important point around testing. If you have a staging version of the old sites that uses the staging version of the DTM script then you really can’t test the migration to Launch. The linking only updates the production files. But really you neeeed to test. In order to do this I would recommend just using a tool like Charles or Chrome overrides to rewrite the the DTM embed code to your Launch embed code.
  • Watch out for old methods. When Adobe warned of the transition from DTM to Launch they noted that only the methods below will be supported. If you did something crazy on your site that has outside-of-DTM scripts using something in the _satellite object then you’ll need to figure out an alternative. Once you publish your Launch files to the DTM location, any other methods previously made available by DTM may not be there anymore. Here are the methods that you can still use:
    • _satellite.notify()
    • _satellite.track()
    • _satellite.getVar()
    • _satellite.setVar()
    • _satellite.getVisitorId()
    • _satellite.setCookie()
    • _satellite.readCookie()
    • _satellite.removeCookie()
    • _satellite.isLinked()
  • You can see Adobe’s documentation around this feature here. Especially important are the prerequisites for enabling the linking (DTM and Launch need to be associated with the same org, etc)
0
Tag Management, Uncategorized

Thankful Launch Features

Posted on by Eric Peterson

In honor of Thanksgiving last week I wanted to take a moment to provide a possibly odd mashup between holiday and tag management systems. When I’m converting an implementation from Adobe DTM to Adobe Launch there are a few small features that I’m grateful Adobe added to Launch. Here they are in no particular order…

Better Support for the S Object

Adobe Analytics implementations have traditionally leveraged an ‘s’ global object. The standard setup in DTM would either obfuscate the object that Adobe Analytics used or just not make it globally scoped. This could be annoying when you wanted some other script to use the ‘s’ object. You can force DTM to use the ‘s’ object, but then you would lose some features like the “Managed by Adobe” option for your app measurement code. Here is the DTM setup:

Now in Launch you can opt to “make tracker globally accessible” in your extension configuration.

This will create the ‘s’ object at the window scope so you can have other scripts potentially reference the object directly. With this you get the added benefit of future library updates being easier. Having scripts that directly reference the ‘s’ object isn’t something you should plan on leveraging heavily. However, depending what you are needing while migrating it sure can be useful.

Ordering Tags

When you have an implementation with dependencies between tags the ordering is important. In DTM you had some ordering available by using different event types on the page (top of page, page bottom, DOM ready) but no supported ordering at the time of a single event (although I did once find an unsupported hack for this).

With Launch the ordering is built right into the event configuration of your rules.

It is pretty simple. The default number is 50. If you need something to run earlier on the same event just give it a lower number.

Modifying default values sometimes make me nervous, though, so if you do change the number from 50 just do yourself a favor and update the event name and even the rule name to reflect that. Because my names often represent a list of attributes, I’ll just add “order 10” to the end of the name.

Link Launch to DTM Embed Code

When you configure environments in Launch you will get new embed code to implement on your site. If you were on DTM for a long time and had a bunch of internal or agency groups implement DTM across many different applications then chances are making a global code updates like this is tough! Fortunately, Launch has a feature that allows you to simply update your old DTM payload with the new Launch logic without making all those updates. When creating a new production environment you can just add your DTM embed code to the field shown below. Once that is done, your production Launch code will also publish to the old DTM embed file as well. With this any site on the old or new embed code will have the same, consistent code. Yay!

So what’s one of your favorite Launch features? Comment below!

0
Industry Analysis, Tag Management, Technical/Implementation

Stop Thinking About Tags, and Start Thinking About Data

Posted on by Eric Peterson

Nearly three weeks ago, I attended Tealium’s Digital Velocity conference in San Francisco. I’ve attended this event every year since 2014, and I’ve spent enough time using its Universal Data Hub (the name of the combined UI for AudienceStream, EventStream, and DataAccess, if you get a little confused by the way these products have been marketed – which I do), and attended enough conferences, to know that Tealium considers these products to be a big part of its future and a major part of its product roadmap. But given that the majority of my my clients are still heavily focused on tag management and getting the basics under control, I’ve spent far more time in Tealium iQ than any of its other products. So I was a little surprised as I left the conference on the last day by the force with which my key takeaway struck me: tag management as we knew it is dead.

Back in 2016, I wrote about how much the tag management space had changed since Adobe bought Satellite in 2013. It’s been awhile since tag management was the sole focus of any of the companies that offer tag management systems. But what struck me at Digital Velocity was that the most successful digital marketing organizations – while considering tag management a prerequisite for their efforts – don’t really use their tools to manage tags at all. I reflected on my own clients, and found that the most successful ones have realized that they’re not managing tags at all – they’re managing data. And that’s why Tealium is in such an advantageous position relative to any of the other companies still selling tag management systems while Google and Adobe give it away for free.

This idea has been kicking around in my head for awhile now, and maybe I’m stubborn, but I just couldn’t bring myself to admit it was true. Maybe it’s because I still have clients using Ensighten and Signal – in spite of the fact that neither product seems to have committed many resources to their tag management products lately (they both seem much more heavily invested in identity and privacy these days). Or maybe it’s because I still think of myself as the “tag management guy” at Demystified, and haven’t been able to quite come to grips with how much things have changed. But my experience at Digital Velocity was really the final wake-up call.

What finally dawned on me at Digital Velocity is that Tealium, like many of their early competitors, really doesn’t think of themselves as a tag management company anymore, either. They’ve done a much better job of disguising that though – because they continue to invest heavily in TiQ, and have even added some really great features lately (I’m looking at you, New JavaScript Code Extension). And maybe they haven’t really had to disguise it, either,  because of a single decision they made very early on in their history: the decision to emphasize a data layer and tightly couple it with all the core features of its product. In my opinion, that’s the most impactful decision any of the early tag management vendors made on the industry as a whole.

Most tag management vendors initially offered nothing more than code repositories outside of a company’s regular IT processes. They eventually layered on some minimal integration with a company’s “data layer” – but really without ever defining what a data layer was or why it was important. They just allowed you to go in and define data elements, write some code that instructed the TMS on how to access that data, and then – in limited cases – gave you the option of pushing some of that data to your different vendor tags.

On the other hand, Tealium told its customers up front that a good data layer was required to be successful with TiQ. They also clearly defined best practices around how that data layer should be structured if you wanted to tap into the power of their tool. And then they started building hundreds of different integrations (i.e. tags) that took advantage of that data layer. If they had stopped there, they would have been able to offer customers a pretty useful tool that made it easier to deploy and manage JavaScript tags. And that would have made Tealium a pretty similar company to all of its early competitors. Fortunately, they realized they had built something far more powerful than that – the backbone of a potentially very powerful customer data platform (or, as someone referred to Tealium’s tag management tool at DV, a “gateway drug” to its other products).

The most interesting thing that I saw during those 2 days was that there are actual companies for which tag management is only a subset of what they are doing through Tealium. In previous years, Tealium’s own product team has showcased AudienceStream and EventStream. But this year, they had actual customers showing off real-world examples of the way that they have leveraged these products to do some pretty amazing things. Tealium’s customers are doing much more real-time email marketing than you can do through traditional integrations with email service providers. They’re leveraging data collected on a customer’s website to feed integrations with tools like Slack and Twilio to meet customers’ needs in real-time. They’re solving legitimate concerns about the impact all these JavaScript tags have on page-load performance to do more flexible server-side tagging than is possible through most tools. And they’re able to perform real-time personalization across multiple domains and devices. That’s some really powerful stuff – and way more fun to talk about than “tags.” It’s also the kind of thing every company can start thinking about now, even if it’s something you have to ramp up to first.

In conclusion, Tealium isn’t the only company moving in this direction. I know Adobe, Google, an Salesforce all have marketing tools offer a ton of value to their customers. Segment offers the ability to do server-side integrations with many different marketing tools. But I’ve been doing tag management (either through actual products or my own code) for nearly 10 years, and I’ve been telling customers how important it is to have a solid data layer for almost as long – at Salesforce, we had a data layer before anyone actually called it that, and it was so robust that we used it to power everything we did. So to have the final confirmation that tag management is the past and that customer data is the future was a pretty cool experience for me. It’s exciting to see what Adobe Launch is doing with its extension community and the integration with the newest Adobe mobile SDKs. And there are all kinds of similar opportunities for other vendors in the space. So my advice to marketers is this: if you’re still thinking in terms of tags, or if you still think of all your third-party vendors as “silos,” make the shift to thinking about data and how to use it to drive your digital marketing efforts.

Photo Credit: Jonathan Poh (Flickr)

0
Tag Management

GTM: Using Multiple Inputs for RegEx Tables

Posted on by Eric Peterson

I’m a big fan of RegEx table variables in Google Tag Manager. These are especially useful if you have implemented a gtm blacklist with your GTM setup to avoid custom scripting. If that is your situation (likely not) then this variable type will provide some flexibility that you wouldn’t have otherwise.  Keep in mind, though, that RegEx Tables have one limiting factor that sometimes take a bit of extra work…they only allow for a single input variable:

This can be limiting in scenarios where you want to have an output that depends on a variety of inputs. As an example, let’s say that we want to deploy a bunch of Floodlights, each with a different activity string, based on a combination of an event category, event action and URL path. For this example, you can just assume that the event category and action are being pushed into the dataLayer. Now, I could probably create a trigger for each floodlight and avoid doing any of this; however I find that approach less scalable and tends to make a mess of your GTM configuration. Let’s just say I don’t want to be miserable so I decide to not create a trigger for each floodlight. Instead we can have all that logic in one place by just concatenating together the different variables we want and use the RegEx table to identify a match as needed. To do this I just create a new variable that pulls in all the other variables like so:

Notice that I like to use a name/value concatenation so it ends up looking like URL parameters. I use “^” as the delimiter since that is pretty unique. I avoid using delimiters that are leveraged in URLs (such as ?, &, #). Also using a name with the value helps to ensure that we don’t accidentally match on a value that is unexpectedly in one of the other variables.

With the concatenation of variables giving us a new, single input I can now set up my regex table as needed:

Once I have worked out my RegEx table logic to match correctly on what I want I then just plug it into my floodlight as normal:

And with that you have now deployed a bunch of floodlights with a single tag, trigger, and variable. I have found this to be useful in simplifying the GTM setup in a bunch of scenarios so I hope it helps you too!

 

 

0
Adobe Analytics, Tag Management, Technical/Implementation, Testing and Optimization

Adobe Target + Analytics = Better Together

Posted on by Josh West

Last week I wrote about an Adobe Launch extension I built to familiarize myself with the extension development process. This extension can be used to integrate Adobe Analytics and Target in the same way that used to be possible prior to the A4T integration. For the first several years after Omniture acquired Offermatica (and Adobe acquired Omniture), the integration between the 2 products was rather simple but quite powerful. By using a built-in list variable called s.tnt (that did not count against the 3 per report suite available to all Adobe customers), Target would pass a list of all activities and experiences in which a visitor was a participant. This enabled reporting in Analytics that would show the performance of each activity, and allow for deep-dive analysis using all the reports available in Analytics (Target offers a powerful but limited number of reports). When Target Standard was released, this integration became more difficult to utilize, because if you choose to use Analytics for Target (A4T) reporting, the plugins required to make it work are invalidated. Luckily, there is a way around it, and I’d like to describe it today.

Changes in Analytics

In order to continue to re-create the old s.tnt integration, you’ll need to use one of your three list variables. Choose the one you want, as well as the delimiter and the expiration (the s.tnt expiration was 2 weeks).

Changes in Target

The changes you need to make in Target are nearly as simple. Log into Target, go to “Setup” in the top menu and then click “Response Tokens” in the left menu. You’ll see a list of tokens, or data elements that exist within Target, that can be exposed on the page. Make sure that activity.id, experience.id, activity.name, and experience.name are all toggled on in the “Status” column. That’s it!

Changes in Your TMS

What we did in Analytics and Target made an integration possible – we now have a list variable ready to store Target experience data, and Target will now expose that data on every mbox call. Now, we need to connect the two tools and get data from Target to Analytics.

Because Target is synchronous, the first block of code we need to execute must also run synchronously – this might cause problems for you if you’re using Signal or GTM, as there aren’t any great options for synchronous loading with those tools. But you could do this in any of the following ways:

  • Use the “All Pages – Blocking (Synchronous)” condition in Ensighten
  • Put the code into the utag.sync.js template in Tealium
  • Use a “Top of Page” (DTM) or “Library Loaded” rule (Launch)

The code we need to add synchronously attaches an event listener that will respond any time Target returns an mbox response. The response tokens are inside this response, so we listen for the mbox response and then write that code somewhere it can be accessed by other tags. Here’s the code:

	if (window.adobe && adobe.target) {
		document.addEventListener(adobe.target.event.REQUEST_SUCCEEDED, function(e) {
			if (e.detail.responseTokens) {
				var tokens = e.detail.responseTokens;
				window.targetExperiences = [];
				for (var i=0; i<tokens.length; i++) {
					var inList = false;
					for (var j=0; j<targetExperiences.length; j++) {
						if (targetExperiences[j].activityId == tokens[i]['activity.id']) {
							inList = true;
							break;
						}
					}
					
					if (!inList) {
						targetExperiences.push({
							activityId: tokens[i]['activity.id'],
							activityName: tokens[i]['activity.name'],
							experienceId: tokens[i]['experience.id'],
							experienceName: tokens[i]['experience.name']
						});
					}
				}
			}
			
			if (window.targetLoaded) {
				// TODO: respond with an event tracking call
			} else {
				// TODO: respond with a page tracking call
			} 
		});
	}
	
	// set failsafe in case Target doesn't load
	setTimeout(function() {
		if (!window.targetLoaded) {
			// TODO: respond with a page tracking call
		}
	}, 5000);

So what does this code do? It starts by adding an event listener that waits for Target to send out an mbox request and get a response back. Because of what we did earlier, that response will now carry at least a few tokens. If any of those tokens indicate the visitor has been placed within an activity, it checks to make sure we haven’t already tracked that activity on the current page (to avoid inflating instances). It then adds activity and experience IDs and names to a global object called “targetExperiences,” though you could push it to your data layer or anywhere else you want. We also set a flag called “targetLoaded” to true that allows us to use logic to fire either a page tracking call or an event tracking call, and avoid inflating page view counts on the page. We also have a failsafe in place, so that if for some reason Target does not load, we can initiate some error handling and avoid delaying tracking.

You’ll notice the word “TODO” in that code snippet a few times, because what you do with this event is really up to you. This is the point where things get a little tricky. Target is synchronous, but the events it registers are not. So there is no guarantee that this event will be triggered before the DOM ready event, when your TMS likely starts firing most tags.. So you have to decide how you want to handle the event. Here are some options:

  • My code above is written in a way that allows you to track a pageview on the very first mbox load, and a custom link/event tracking call on all subsequent mbox updates. You could do this with a utag.view and utag.link call (Tealium), or trigger a Bootstrapper event with Ensighten, or a direct call rule with DTM. If you do this, you’ll need to make sure you configure the TMS to not fire the Adobe server call on DOM ready (if you’re using DTM, this is a huge pain; luckily, it’s much easier with Launch), or you’ll double-count every page.
  • You could just configure the TMS to call a custom link call every time, which will probably increase your server calls dramatically. It may also make it difficult to analyze experiences that begin on page load.

What my Launch extension does is fire one direct call rule on the first mbox call, and a different call for all subsequent mbox calls. You can then configure the Adobe Analytics tag to fire an s.t() call (pageview) for that initial direct call rule, and an s.tl() call for all others. If you’re doing this with Tealium, make sure to configure your implementation to wait for your utag.view() call rather than allowing the automatic one to track on DOM ready. This is the closest behavior to how the original Target-Analytics integration worked.

I’d also recommend not limiting yourself to using response tokens in just this one way. You’ll notice that there are tokens available for geographic data (based on an IP lookup) and many other things. One interesting use case is that geographic data could be extremely useful in achieving GDPR compliance. While the old integration was simple and straightforward, and this new approach is a little more cumbersome, it’s far more powerful and gives you many more options. I’d love to hear what new ways you find to take advantage of response tokens in Adobe Target!

Photo Credit: M Liao (Flickr)

0
Adobe Analytics, Tag Management, Technical/Implementation

My First Crack at Adobe Launch Extension Development

Posted on by Josh West

Over the past few months, I’ve been spending more and more time in Adobe Launch. So far, I’m liking what I see – though I’m hoping the publish process gets ironed out a bit in coming months. But that’s not the focus of this post; rather, I wanted to describe my experience working with extensions in Launch. I recently authored my first extension – which offers a few very useful ways to integrate Adobe Target with other tools and extensions in Launch. You can find out more about it here, or ping me with any questions if you decide to add the extension to your Launch configuration. Next week I’ll try and write more about how you might something similar using any of the other major tag management systems. But for now, I’m more interested in how extension development works, and I’d like to share some of the things I learned along the way.

Extension Development is New (and Evolving) Territory for Adobe

The idea that Adobe has so freely opened up its platform to allow developers to share their own code across Adobe’s vast network of customers is admittedly new to me. After all, I can remember the days when Omniture/Adobe didn’t even want to open up its platform to a single customer, much less all of them. Remember the days of usage tokens for its APIs? Or having to pay for a consulting engagement just to get the code to use an advanced plugin like Channel Manager? So the idea that Adobe has opened things up to the point where I can write my own code within Launch, programmatically send it to Adobe, and have it then available for any Adobe customer to use – that’s pretty amazing. And for being so new, the process is actually pretty smooth.

What Works Well

Adobe has put together a pretty solid documentation section for extension developers. All the major topics are covered, and the Getting Started guide should help you get through the tricky parts of your first extension like authentication, access tokens, and uploading your extension package to the integration environment. One thing to note is that just about everything you define in your extension is a “type” of that thing, not the actual thing. For example, my extension exposes data from Adobe Target for use by other extensions. But I didn’t immediately realize that my data element definitions didn’t actually define new data elements for use in Launch; it only created a new “type” of data element in the UI that can then be used to create a data element. The same is true for custom events and actions. That makes sense now, but it took some getting used to.

During the time I spent developing my extension, I also found the Launch product team is working continuously to improve the process for us. When I started, the documentation offered a somewhat clunky process to retrieve an access token, zip my extension, and use a Postman collection to upload it. By the time I was finished, Adobe had released a Node package (npm) to basically do all the hard work. I also found the Launch product team to be incredibly helpful – they responded almost immediately to my questions on their Slack group. They definitely seem eager to build out a community as quickly as possible.

I also found the integration environment to be very helpful in testing out my extension. It’s almost identical to the production environment of Launch; the main difference is that it’s full of extensions in development by people just like me. So you can see what others are working on, and you can get immediate feedback on whether your extension works the way it should. There is even a fair amount of error logging available if you break something – though hopefully this will be expanded in the coming months.

What Could Work Better

Once I finished my extension, I noticed that there isn’t a real natural spot to document how your extension should work. I opted to put mine into the main extension view, even though there was no other configuration needed that would require such a view. While I was working on my extension, it was suggested that I put instructions in my Exchange listing, which doesn’t seem like a very natural place for it, either.

I also hope that, over time, Adobe offers an easier way to style your views to match theirs. For example, if your extension needs to know the name of a data element it should populate, you need a form field to collect this input. Making that form look the same as everything else in Launch would be ideal. I pulled this off by scraping the HTML and JavaScript from one Adobe’s own extensions and re-formatting it. But a “style toolkit” would be a nice addition to keep the user experience the same.

Lastly, while each of the sections in the Getting Started guide had examples, some of the more advanced topics could use some more additional exploration. For example, it took me a few tries to decide whether my extension would work better with a custom event type, or with just some custom code that triggered a direct call rule. And figuring out how to integrate with other extensions – how to access other extensions’ objects and code – wasn’t exactly easy and I still have some unanswered questions because I found a workaround and ended up not needing it.

Perhaps the hardest part of the whole process was getting my Exchange listing approved. The Exchange covers a lot of integrations beyond just Adobe Launch, some of which are likely far more complex than what mine does. A lot of the required images, screenshots, and details seemed like overkill – so a tiered approach to listings would be great, too.

What I’d Like to See Next

Extension development is in its infancy still, but one thing I hope is on the roadmap is the ability to customize an extension to work the way you need it. For a client I recently migrated, they used both Facebook and Pinterest, though the extensions didn’t work for their tag implementation. There were events and data they needed to capture that the extension didn’t support. I hope that in a future iteration, I’ll be able to “check out” an extension from the library and download the package, make it work the way I need and either create my own version of the extension or contribute to an update of someone else’s extension that the whole community can benefit from. The inability to customize tag templates has plagued every paid tag management solution except Tealium (which has supported it from the beginning) for years – in my opinion, it’s what turns tag management from a tool used primarily to deploy custom JavaScript into a powerful digital marketing toolbelt. It’s not something I’d expect so early in the game, but I hope it will be added soon.

In conclusion, my hat goes off to the Launch development team; they’ve come up with a really great way to build a collaborative community that pushes Launch forward. No initial release will ever be perfect, but there’s a lot to work with and a lot of opportunity for all of us in the future to shape the direction Launch takes and have some influence in how it’s adopted. And that’s an exciting place to be.

Photo Credit: Rod Herrea (Flickr)

0
Tag Management, Technical/Implementation

Helpful Implementation Tip – Rewrite HTML on Page Load with Charles Proxy

Posted on by Tim Patten

There are a variety of methods and tools used for debugging and QA’ing an analytics implementation.  While simply using the developer tools built into your favorite browser will usually suffice for some of the more common QA needs, there are times that a more robust tool is needed.  One such situation is the need to either swap out code on the page, or add code to a page.

To use an example, there are many times that a new microsite will be launching, but due to dev sprints/cycles, the Tag Management System (TMS), and dataLayer, that you are going to be working with hasn’t been added to the site yet.  However, you may need to get some tags set up in the TMS and ensure they are working, while the engineering team works on getting the TMS installed on the site. In these situations, it would be very difficult to ensure that everything in the TMS is working correctly prior to the release.  This is one of many situations where Charles Proxy can be a useful tool to have available.  

Charles Proxy is a proxy tool that sits in the middle of your connection to the internet.  This means that it captures and processes every bit of information that is sent between your computer and the internet and therefore can allow you to manipulate that information.  One such manipulation you can perform is to change the body of any response that is received from a web server, i.e. the HTML of a web page.

To go back to my example above, let’s say that I wanted to install Google Tag Manager (GTM) on a webpage.  I would open up Charles, go to the Tools menu and then go to Rewrite. I would then create a new rule that replaces the “</head>” text with the dataLayer definition, GTM snippet and then the “</head>” text. (See below for how this is setup).  This will result in the browser (only on your computer and only while Charles is open with the rewrite enabled) receiving an HTML response that contains the GTM snippet.

Example Setup

Step 1: Open the Rewrite tool from the “Tools” menu.

Step 2: Click the add button on the bottom left to add a new Rewrite rule.  Then click on the Add button on the middle right to add a configuration for which domains/pages to apply this rewrite rule to.

Step 3: Click the Add button on the bottom right.  This will allow you to specify what action you want to take on the domains/pages that you specified.  For this example, you will want to choose a “Type” of “Body” and “Where” of “Response” as you are modifying the Body of the response. Under “Match” you are going to put the closing “</head>” tag as this is where you are going to install the TMS.  Then, under “Replace”, you will put the snippet you want to place before the closing head tag (in this example, the TMS and dataLayer tags) followed by the same closing “</head>” tag. When you are done, click “OK” to close the Action window.

Step 4: Click OK on the Rewrite Settings window to save your rewrite rule.  Then refresh the domains/pages in your browser to see whether your new rewrite rule is working as expected.

Why use Charles instead of standard browser developer tools?

While you could perform this same task using the developer tools in your chosen browser, that would have to be done on each page that you need to QA, each time a page is loaded.  A Charles rewrite, on the other hand, would be automatically placed on each page load. It also ensures that the GTM snippet and dataLayer are loaded in the correct place in the DOM and that everything fires in the correct order.  This is essential to ensuring that your QA doesn’t return different results than it would on your production site (or staging site once the GTM snippet is placed).

There are many ways that Charles rewrites can be used.  Here are a few examples of when I utilize rewrites –

  • Changing the container bootstrap/container that is used for staging sites (this is less common, but sometimes needed depending on the situation);
  • Adding/changing core JavaScript that is needed for analytics to function;
  • Modifying HTML to test out specific scenarios with tracking (instead of having to do so in the browser’s developer tools on each page load);
  • Manipulating the dataLayer on each page prior to a staging site update.  This can be useful for testing out a tagging plan prior to sending to a dev team (which helps to ensure less back and forth in QA when something wasn’t quite defined correctly in your requirements).

I hope you have found this information useful.  What are your thoughts? Do you have any other great use cases that I may have missed?  Leave your comments below!

0
Adobe Analytics, Featured, Tag Management, Technical/Implementation

A Coder’s Paradise: Notes from the Tech Track at Adobe Summit 2018

Posted on by Josh West

Last week I attended my 11th Adobe Summit – a number that seems hard to believe. At my first Summit back in 2008, the Great Recession was just starting, but companies were already cutting back on expenses like conferences – just as Omniture moved Summit from the Grand America to the Salt Palace (they moved it back in 2009 for a few more years). Now, the event has outgrown Salt Lake City – with over 13,000 attendees last week converging on Las Vegas for an event with a much larger footprint than just the digital analytics industry.

With the sheer size of the event and the wide variety of products now included in Adobe’s Marketing and Experience Clouds, it can be difficult to find the right sessions – but I managed to attend some great labs, and wanted to share some of what I learned. I’ll get to Adobe Launch, which was again under the spotlight – only this year, it’s actually available for customers to use. But I’m going to start with some of the other things that impressed me throughout the week. There’s a technical bent to all of this – so if you’re looking for takeaways more suited for analysts, I’m sure some of my fellow partners at Demystified (as well as lots of others out there) will have thoughts to share. But I’m a developer at heart, so that’s what I’ll be emphasizing.

Adobe Target Standard

Because Brian Hawkins is such an optimization wizard, I don’t spend as much time with Target as I used to, and this was my first chance to do much with Target Standard besides deploy the at.js library and the global mbox. But I attended a lab that worked through deploying it via Launch, then setting up some targeting on a singe-page ReactJS application. My main takeaway is that Target Standard is far better suited to running an optimization program on a single-page application than Classic ever was. I used to have to utilize nested mboxes and all sorts of DOM trickery to delay content from showing until the right moment when things actually took place. But with Launch, you can easily listen for page updates and then trigger mboxes accordingly.

Target Standard and Launch also makes it easier to handle a common issue with frameworks like ReactJS where the data layer is being asynchronously populated with data from API calls – so you can run a campaign on initial page load even if it takes some time for all the relevant targeting data to be available.

Adobe Analytics APIs

The initial version of the Omniture API was perhaps the most challenging API I’ve ever used. It supported SOAP only, and from authentication to query, you had to configure everything absolutely perfectly for it to work. And you had to do it with no API Explorer and virtually no documentation, all while paying very close attention to the number of requests you were making, since you only had 2,000 tokens per month and didn’t want to run out or get charged for more (I’m not aware this ever happened, but the threat at least felt real!).

Adobe adding REST API support a few years later was a career-changing event for me, and there have been several enhancements and improvements since, like adding OAUTH authentication support. But what I saw last week was pretty impressive nonetheless. The approach to querying data is changed significantly in the following ways:

  • The next iteration of Adobe’s APIs will offer a much more REST-ful approach to interacting with the platform.
  • Polling for completed reports is no longer required. It will likely take several more requests to get to the most complicated reports, but each individual request will run much faster.
  • Because Analytics Workspace is built on top of a non-public version of the API, you truly will be able to access any report you can find in the UI.
  • The request format for each report has been simplified, with non-essential parameters either removed or at least made optional.
  • The architecture of a report request is fundamentally different in some ways – especially in the way that breakdowns between reports work.
  • The ability to search or filter on reports is far more robust than in earlier versions of the API.

Launch by Adobe

While Launch has been available for a few months, I’ve found it more challenging than I expected to talk my clients into migrating from DTM to Launch. The “lottery” system made some of my clients wonder if Launch was really ready for prime-time, while the inability to quickly migrate an existing DTM implementation over to Launch has been prohibitive to others. But whatever the case may be, I’ve only started spending a significant amount of time in Launch in the last month or so. For customers who were able to attend labs or demos on Launch at Summit, I suspect that will quickly change – because the feature set is just so much better than with DTM.

How Launch Differs from DTM

My biggest complaint about DTM has always been that it hasn’t matched the rest of the Marketing Cloud in terms of enterprise-class features. From a limited number of integrations available, to the rigid staging/production publishing structure, I’ve repeatedly run into issues where it was hard to make DTM work the way I needed for some of my larger clients. Along the way, Adobe has repeatedly said they understood these limitations and were working to address them. And Launch does that – it seems fairly obvious now that the reason DTM lagged in offering features other systems did is because Adobe has been putting way more resources into Launch over the past few years. It opens up the platform in some really unique ways that DTM never has:

  • You can set up as many environments as you want.
  • Minification of JavaScript files is now standard (it’s still hard to believe this wasn’t the case with DTM).
  • Anyone can write extensions to enhance the functionality and features available.
  • The user(s) in charge of Launch administration for your company have much more granular control over what is eventually pushed to your production website.
  • The Launch platform will eventually offer open APIs to allow you to customize your company’s Launch experience in virtually any way you need.

With Great Power Comes Great Responsibility

Launch offers a pretty amazing amount of control that make for some major considerations to each company that implements it. For example, the publishing workflow is flexible to the point of being a bit confusing. Because it’s set up almost like a version control system like Git, any Launch user can set up his or her own development environment and configure in any number of ways. This means each user has to then choose which version of every single asset to include in a library, promote to staging/production, etc. So you have to be a lot more careful than when you’re publishing with DTM.

I would hope we’ve reached a point in tag management where companies no longer expect a marketer to be able to own tagging and the TMS – it was the sales pitch made from the beginning, but the truth is that it has never been that easy. Even Tealium, which (in my opinion) has the most user-friendly interface and the most marketer-friendly features, needs at least one good developer to tap into the whole power of the tool. Launch will be no different; as the extension library grows and more integrations are offered, marketers will probably feel more comfortable making changes than they were with DTM – but this will likely be the exception and not the rule.

Just One Complaint

If there is one thing that will slow migration from DTM to Launch, it is be the difficulty customers will face in migration. One of the promises Adobe made about Launch at Summit in 2017 was that you would be able to migrate from DTM to Launch without updating the embed code on your site. This is technically true – you can configure Launch to publish your production environment to an old DTM production publishing target. But this can only be done for production, and not any other environment – which means you can migrate without updating your production embed code, but you will need to update all your non-production codes. Alternatively, you can use a tool like DTM Switch or Charles Proxy for your testing – and that will work fine for your initial testing. But most enterprise companies want to accumulate a few weeks of test data for all the traffic on at least one QA site before they are comfortable deploying changes to production.

It’s important to point out that, even if you do choose to migrate by publishing your Launch configuration to your old production DTM publishing target, you still have to migrate everything currently in DTM over to Launch – manually. Later this year, Adobe has said that they will release a true migration tool that will allow customers to pull rules, data elements, and tags from a DTM property into a new Launch property and migrate them without causing errors. Short of such a tool, some customers will have to invest quite a bit to migrate everything they currently have in DTM over to Launch. Until then, my recommendation is to figure out the best migration approach for your company:

  1. If you have at least one rockstar analytics developer with some bandwidth, and a manageable set of rules and tags in DTM, I’d start playing around with migration in one of your development environments, and put together an actual migration plan.
  2. If you don’t have the resources yet, I’d probably wait for the migration tool to be available later in the year – but still start experimenting with Launch on smaller sites or as more resources become available.

Either way, for some of my clients that have let their DTM implementations get pretty unwieldy, moving from DTM to Launch offers a fresh start and a chance to upgrade to Adobe’s latest technology. No matter which of these two situations you’re in, I’d start thinking now (if you haven’t already) about how you’re going to get your DTM properties migrated to Launch. It is superior to DTM in nearly every way, and it is going to get nearly all of the development resources and roadmap attention from Adobe from here on out. You don’t need to start tomorrow – and if you need to wait for a migration tool, you’ll be fine. But if your long-term plan is to stay with DTM, you’re likely going to limit your ability in the future to tap into additional features, integrations and enhancements Adobe makes across its Marketing and Experience Cloud products.

Conclusion

We’ve come a long ways from the first Summits I attended, with only a few labs and very little emphasis on the technology itself. Whether it was new APIs, new product features announcements, or the hands-on labs, there was a wealth of great information shared at Summit 2018 for developers and implementation-minded folks like me – and hopefully you’re as excited as I am to get your hands on some of these great new products and features.

Photo Credit: Roberto Faccenda (Flickr)

0
Adobe Analytics, Tag Management, Technical/Implementation

Adobe Data Collection Demystified: Ten Tips in Twenty(ish) Minutes

Posted on by Eric Peterson

We are all delighted to announce our first of hopefully many live presentations on the YouTube platform coming up on March 20th at 11 AM Pacific / 2 PM Eastern!  Join Josh West and Kevin Willeitner, Senior Partners at Analytics Demystified and recognized industry leaders on the topic of analytics technology, and learn some practical techniques to help you avoid common pitfalls and improve your Adobe data collection.  Presented live, Josh and Kevin will touch on aspects of the Adobe Analytics collection process from beginning to end with tips that will help your data move through the process more efficiently and give you some know-how to make your job a little easier.

The URL for the presentation is https://www.youtube.com/watch?v=FtJ40TP1y44 and if you’d like a reminder before the event please just let us know.

Again:

Adobe Data Collection Demystified
Tuesday, March 20th at 11 AM Pacific / 2 PM Eastern
https://www.youtube.com/watch?v=FtJ40TP1y44

Also, if you are attending this year’s Adobe Summit in Las Vegas … a bunch of us will be there and would love to meet in person. You can email me directly and I will coordinate with Adam Greco, Brian Hawkins, Josh West, and Kevin Willeitner to make sure we have time to chat.

0
Adobe Analytics, Tag Management, Technical/Implementation

Star of the Show: Adobe Announces Launch at Summit 2017

Posted on by Eric Peterson

If you attended the Adobe Summit last week and are anything like me, a second year in Las Vegas did nothing to cure the longing I felt last year for more of a focus on digital analytics rather than experience (I still really missed the ski day, too). But seeing how tag management seemed to capture everyone’s attention with the announcement of Adobe Launch, I had to write a blog post anyway. I want to focus on 3 things: what Launch is (or will be), what it means for current users of DTM, and what it means for the rest of the tag management space.

Based on what I saw at Summit, Launch may be the new catchy name, but it looks like the new product may finally be worthy of the name given to the old one (Dynamic Tag Management, or DTM). I’ve never really thought there was much dynamic about DTM – if you ask me, the “D” should have stood for “Developer,” because you can’t really manage any tags with DTM unless you have a pretty sharp developer. I’ve used DTM for years, and it has been a perfectly adequate tool for what I needed. But I’ve always thought more about what it didn’t do than what it did: it didn’t build on the innovative UI of its Satellite forerunner (the DTM interface was a notable step backwards from Satellite); it didn’t make it easier to deploy any tags that weren’t sold by Adobe (especially after Google released enhanced e-commerce), and it didn’t lead to the type of industry innovation I hoped it would when Adobe acquired Satellite in 2013 (if anything, the fact that the biggest name in the industry was giving it away for free really stifled innovation at some – but not all – of its paid competitors). I always felt it was odd that Adobe, as the leading provider of enterprise-class digital analytics, offered a tag management system that seemed so unsuited to the enterprise. I know this assessment sounds harsh – but I wouldn’t write it here if I hadn’t heard similar descriptions of DTM from Adobe’s own product managers while they were showing off Launch last week. They knew they could do tag management better – and it looks like they just might have done it.

How Will Launch Be Different?

How about, “In every way except that they both allow you to deploy third-party tags to your website.” Everything else seems different – and in a good way. Here are the highlights:

  • Launch is 100% API driven: Unlike most software tools, which get built, and then the API is added later, Adobe decided what they wanted Launch to do; then they built the API; and then they built the UI on top of that. So if you don’t like the UI, you can write your own. If you don’t like the workflow, you can write your own. You can customize it any way you want, or write your own scripts to make commonly repeated tasks much faster. That’s a really slick idea.
  • Launch will have a community behind it: Adobe envisions a world where vendors write their own tag integrations (called “extensions”) that customers can then plug into their own Launch implementations. Even if vendors don’t jump at the chance to write their own extensions, I can at least see a world where agencies and implementation specialists do it for them, eager to templatize the work they do every day. I’ve already got a list of extensions I can’t wait to write!
  • Launch will let you “extend” anything: Most tag management solutions offer integrations but not the ability to customize them. If the pre-built integration doesn’t work for you, you get to write your own. That often means taking something simple – like which products a customer purchased from you – and rewriting the same code dozens of times to spit it out in each vendor’s preferred format. But Launch will give the ability to have sharable extensions that do this for you. If you’ve used Tealium, it means something similar to the e-commerce extension will be possible, which is probably my favorite usability/extensibility feature any TMS offers today.
  • Launch will fix DTM’s environment and workflow limitations: Among my clients, one of the most common complaints about DTM is that you get 2 environments – staging and production. If your IT process includes more, well, that’s too bad. But Launch will allow you to create unlimited environments, just like Ensighten and Tealium do today. And it will have improved workflow built in – so that multiple users can work concurrently, with great care built into the tool to make sure they don’t step on each others’ toes and cause problems.

What Does Launch Mean for DTM Customers?

If you’re a current DTM customer, your first thought about Launch is probably, “Wow, this is great! I can’t wait to use it!” Your second thought is more likely to be, “Wait. I’ve already implemented DTM, and now it’s totally changed. It will be a huge pain to switch now.”

The good news is that, so far, Adobe is saying that they don’t anticipate that companies will need to make any major changes when switching from DTM to Launch (you may need to update the base tag on each page if you plan to take advantage of the new environments feature). They are also working on a migration process that will account for custom JavaScript code you have already written. It may make for a bit of initial pain in migrating custom scripts over, but it should be a pretty smooth process that won’t leave you with a ton of JavaScript errors when you do it. Adobe has also communicated for over a year which parts of the core DTM library will continue to work in the future, and which will not. So you can get ready for Launch by making sure all your custom JavaScript is in compliance with what will be supported in the future. And the benefits over the current DTM product are so obvious that it should be well worth a little bit of up-front pain for all the advantages you’ll get from switching (though if you decide you want to stick with DTM, Adobe plans to continue supporting it).

So if you have decided that Launch beats DTM and you want to switch, the next question is, “When?” And the answer to that is…”Soon.” Adobe hasn’t provided an official launch date, and product managers said repeatedly that they won’t release Launch until it’s world-class. That should actually be welcome news – because making this change will be challenging enough without having to worry about whether Adobe is going to get it right the first time.

What Does Launch Mean for Tag Management?

I think this is really the key question – how will Launch impact the tag management space? Because, while Adobe has impressively used DTM as a deployment and activation tool on an awful lot of its customers’ websites, I still have just as many clients that are happily using Ensighten, GTM, Signal, or Tealium. And I hope they continue to do so – because competition is good for everyone. There is no doubt that Ensighten’s initial product launch pushed its competitors to move faster than they had planned; and that Tealium’s friendly UI has pushed everyone to provide a better user experience (for awhile, GTM’s template library even looked suspiciously like Tealium’s). Launch is adding some features that have already existed in other tools, but Adobe is also pushing some creative ideas that will hopefully push the market in new directions.

What I hope does not happen, though, is what happened when Adobe acquired Satellite in 2013 and started giving it away for free. A few of the the tools in the space are still remarkably similar in actual features in 2017 to what they were in 2013. The easy availability of Adobe DTM seemed to depress innovation – and if your tag management system hasn’t done much in the past few years but redo its UI and add support for a few new vendors, you know what I mean (and if you do, you’ve probably already started looking at other tools anyway). I fear that Launch is going to strain those vendors even more, and it wouldn’t surprise me at all if Launch spurs a new round of acquisitions. But my sincere hope is that the tools that have continued to innovate – that have risen to the challenge of competing with a free product and developed complementary products, innovative new features, and expanded their ecosystem of partners and integrations – will use Launch as motivation to come up with new ways of fulfilling the promise of tag management.

Last week’s announcement is definitely exciting for the tag management space. While Launch is still a few months away, we’ve already started talking at Analytics Demystified about which extensions our clients using DTM would benefit from – and how we can use extensions to get involved in the community that will surely emerge around Launch. If you’re thinking about migrating from DTM to Launch and would like some help planning for it, please reach out – we’d love to help you through the process!

Photo Credit: NASA Goddard Space Flight Center

0
Tag Management

Guess Who – Client Errors!

Posted on by Eric Peterson

Recently I have received an interesting theme of questions related to client errors. These are errors that happen as your site is trying to make requests for various tags that should be included on the page but the browser (aka “the client”) shuts them down for one reason or another. These errors always negatively impact whatever systems was depending on that tag. Most of the time these errors don’t have a notable impact on the user experience but sometimes they do so in generally it is best to prevent these from happening.

Here are three errors for you to gander at. Try just looking at the error and see if you can guess at what is causing the problem. Then compare that to my description below.

Refused to load the script…violates the following Content Security Policy directive


In this case the team was trying to implement Google Tag Manager on a new application that had fairly stringent security measures in place. This is the sort of error that completely ruins whatever a script may want to do so best to resolve it right away.

For this error you mostly just need to know that a site can declare a Content Security Policy (“CSP”) that determines what content on the site is allowed to do and what scripts can be included. Some sites don’t have a CSP which pretty much allows you to run scripts freely. In this case a CSP was in place and because GTM wasn’t included in their GCP it was blocked and unable to deliver any of the many important tags that it needed to.

To resolve this issue the developers just had to update the CSP to include googletagmanager.com and then GTM started working. But don’t stop there…because GTM will include other tags that each run their own scripts you should also do an audit of all your potential tags and ensure that each of their script libraries are part of your CSP. If not, then GTM will try to fire your tag but the browser will reject it.

Mixed Content: The page…requested an insecure script

For this one the page was trying to include a tag but it was getting shut down by the security police!

This one is fairly self explanatory.  Pages that use a secure, HTTPS page should also use tags that run on HTTPS. If they don’t then they will be blocked. Typically I just see this happen if a user is running a tag outside of a tag management systems or using custom scripting in the TMS. The tagging templates that TMSs provide will handle this for you.

To fix this one just update your code to dynamically use the HTTPS version of the tag on pages using HTTPS. Somewhere in the tag code there is likely a reference to a JS file and you’ll see “http” being used as the protocol which is typically where your update will happen. Keep in mind that most of the time you can just change “http” to “https” or just use the relative “//” reference. Be careful, though, because sometime other parts of the URL may need to change to properly reference the secure version of the tag. These details can be provided by whatever vendor that tag belongs to.

net::ERR_BLOCKED_BY_CLIENT

Here we have a big mess of errors and all have the same “net::ERR_BLOCKED_BY_CLIENT” message. This was pretty much happening to every tag and it looked as if the whole tagging setup was imploding!

Remember, if you see “client” in the error that refers to your browser. This error is basically saying that the browser blocked the request from happening. The other interesting point about this error is that it didn’t show for me when I took a look at the same page. So I made a suggestion for something my client could check for and, sure enough, he found that he had an ad blocker installed and the ad blocker was shutting down all of his tags. Fortunately, this just impacts what he was seeing and not all users to the site. Simply disabling the blocker solved the issue for him.

Note that while there is a negative impact to the tag here there isn’t anything you can do about what people have installed on their browser. Best to understand it but not sweat it 🙂

In Closing

Well, I hope that helps to give a little context on a few client errors you may run into. What other errors would you include in this list?

0
Featured, Tag Management

Tag Management: It’s Not About the Tags Anymore

Posted on by Eric Peterson

Last month I attended Tealium’s Digital Velocity conference – the only multi-day conference this year held by one of the major tag management vendors. Obviously, Adobe held its annual Summit conference – by far the largest event in the industry – but Adobe DTM is unlikely to ever receive as much attention as other products in the Marketing Cloud suite that Adobe is actively trying to monetize. Google will likely hold an event later in the year – but if the past few years are any indication, GTM will receive less attention than other parts of the Analytics 360 suite. Ensighten opted for a “roadshow” approach with several one-day stops in various cities. Signal never really had an event to begin with. I had wondered before heading off to San Diego what this change actually meant – but those 2 days made it pretty clear to me: the digital marketing industry – led by the vendors themselves – is moving on from tag management. In fact, I’m not even sure “tag management” is the right name for the space in the digital marketing industry occupied by these companies.

Don’t get me wrong – tags are still vitally important to a digital marketing organization. And the big 5 vendors – Adobe, Ensighten, Google, Signal, and Tealium – are all still making investments in their tag management solutions. But those solutions are really just a cog in a much larger digital marketing wheel. All of the vendors whose core offering started out as tag management seem to be emphasizing their other products – such as Ensighten’s Activate, Signal’s Fuse, and Tealium’s AudienceStream – at least as much as the original tools with which they entered the marketplace.

This is a fascinating development to watch – five years ago, most companies’ tags managed them – and not the other way around. It was still somewhat of a rarity for a company to use a tag management system. I remember sitting through demos while working at salesforce.com and wondering how many companies would actually benefit from paying for such a tool – because we had an extremely sophisticated tracking library of our own that we had developed internally that fed all of our tagging efforts. I quickly came to realize that most companies aren’t like that – tagging is often an afterthought. Developers are usually uninterested in the nuances of each vendor’s specific tag requirements, and marketers often lack the technical chops to deploy complex tags on their own. So it was natural that systems that offered a slick user experience and allowed marketers to add their own tags quickly, with far less IT involvement than before – even if sales people tended to oversell that particular advantage!

However, once it became possible to increase the speed at which tags hit the site, and to decrease the impact they had on page load time and user experience, it was only natural that a whole world of possibilities would open up to digital marketers. And it turns out that the tag management vendors have been working on ways to leverage those possibilities for their own benefit. Instead of focusing on tags, these vendors (some more than others) are starting to focus more on data than tags – because the data allows them to expand what they can offer their customers and justify the investment those customers are making. This development was probably inevitable, though it was sped up once Adobe acquired Satellite, and suddenly there were multiple “free” tools readily available in the market. It used to be that tags were the lifeblood of digital marketing – but not anymore. The data those tags represent is really the key – and vendors that realize that are finding themselves with a leg up on their competition. Vendors that emphasize the data layer and integrate it tightly into their products are much better positioned to help their customers succeed, because they can leverage that data in so many ways besides tags:

  • When your data is solid, you can seamlessly “unplug” a problem tag and replace it with a more promising vendor tag. A good data layer dramatically lowers switching costs.
  • Data – especially unique identifiers like a customer loyalty ID – can become a real-time connection between your websites and mobile apps and traditionally “offline” systems, allowing you to target website visitors with data that has historically only been available to your CRM or your email marketing system.
  • Data can make the connection between a web visitor and mobile app user, allowing you to reach the “holy grail” of marketing – people (instead of visitors or users).

The result of all these market changes is that tag management has reached a point in its lifecycle much faster than web analytics did. Web analytics tools had been around for nearly 10 years before Google bought Urchin, and nearly 15 before the acquisitions of Coremetrics and Omniture. It took about the same time for the vendors themselves to start diversifying their product suites and acquiring their competitors. It took half that time for Adobe to acquire Satellite, Ensighten to acquire TagMan, and products like AudienceStream and Fuse to be released.

The truly great part of tag management is how it has “democratized” digital marketing. Most of my clients have adopted more digital marketing products after implementing tag management because of the ease of deployment. But while they rely on a few key partners in their efforts, they tend to leverage their TMS as a quick and easy way to conduct “bake-offs” between prospective tools. I’ve also seen clients have more success because tag management tools have broken down walls not only between IT and marketing, but also between individual teams within marketing as well – because when you have a solid data layer, everyone can benefit from it. Ranking priorities between the analytics team and the display team, or between the social media team and the optimization team, no longer means the loser must wait months for their work to be completed. Everybody has always wanted the same data – they just didn’t know it. And now that they do, it’s much easier to get everyone what they want – and in a much more timely manner than ever before.

So tag management is no longer a novelty – I’m not really sure how any company can survive without it. But the name “tag management” actually seems a bit limiting to me – if that’s all you’re using your vendor for, you’ve missed the point. If you’re still relying on hundreds of one-off Floodlight tags, rather than pushing actual data from your website into Doubleclick to power much richer remarketing segments; or if you’re not using your data layer to quickly evaluate which vendor to partner with for a new display ad campaign; or if you haven’t yet realized that you can turn your tag management system into the equivalent of a first-party DMP, then it’s time to tap into the power of what these tools can really do. It’s not about the tags anymore, it’s about the data – and how to use that data to improve your customers’ experiences.

Photo Credit: Nate Shivar (Flickr)

0
Featured, Tag Management, Technical/Implementation

A Developer’s Perspective on Features Every Tag Management System Should Offer

Posted on by Josh West

Almost 2 years ago I wrote a blog post on some of the major questions companies face when choosing a tag management system. I very carefully crafted a post that talked about the main trends in the industry and some of the strengths of the major products in the industry. I wasn’t prepared for the response that post received, though in hindsight I should have been: I heard from nearly all the major TMS companies, and each seemed to feel a lot more strongly about any perceived weaknesses I mentioned than about any of the strengths. But that post taught me an important lesson about the weight that a Demystified opinion can carry throughout the analytics community, and about the competitive nature of the tag management space.

Since then, I have chosen my words very carefully when mentioning any of the 5 leading tag management systems. I always preface my comments by saying that we have clients using all of them, and doing so quite successfully. I even refer to the companies by listing them in alphabetical order, and then explain the reason for the order I have chosen – lest anyone think it’s an unofficial ranking of my fondness for any of them (in this regard, DTM benefited a lot more from its acquisition by Adobe than Signal did by rebranding!).

However, seeing how I lead Demystified’s tag management practice, it’s probably time to dangle a toe back in treacherous water. I’d like to provide a list of what I call “essential features” that any tag management system should offer. In some cases, the feature is offered by all of them, and in others, by only one or two – but I will leave you to research that, rather than pointing it out for you. A few caveats before I get started:

  • You’ll find no mention at all of delivery network (100% client-side versus client/server hybrid). I find that both approaches offer such a dramatic improvement in page performance over traditional tagging that I have little interest in picking nits one way or the other.
  • I feel similarly about the synchronous/asynchronous argument as well. There are compelling reasons for both, but you can deploy any system either way (though it may go against the vendor’s best practices). Just remember to make it clear to each vendor you talk to if you plan on deploying synchronous tags (like an A/B testing tag) through their system, and find out whether such tags are supported, and any special considerations for implementing them.

Creating a list like this is a bit tricky because some of the tools are free. While it’s obviously much more palatable to forego a particular feature when you’re not paying for the tool, there are some features that are important enough to me that I’d have to have them whether the tool was free or not. Without further ado, here is my list of essential tag management features:

1. Support for versioning and rollbacks. This is the absolute most important feature any tag management system has to support. Any time you’re dealing with remotely hosted JavaScript, you must be able to remove a rogue vendor’s code at a moment’s notice. Don’t assume that an annoying error or warning icon in the corner of the browser is your worst-case scenario; a broken user experience or a cross-site scripting error could carry a huge cost to your business. The closer the system comes to the version control employed by IT teams, the better – the ability to stage changes, save them for a later release while still deploying new tags that are ready and tested, or revert to a previous version in production without completely losing those changes in your development environment are incredibly valuable features. I’ve seen people lose their jobs because the wrong content ended up on a website at the wrong time, and a company just couldn’t remove it fast enough.

2. Customizable integrations with your most common tags. If you’re new to tag management, you probably don’t realize what goes on under the hood when you implement a tag in the TMS. If the TMS offers a supported tag integration with a particular vendor (often called a template, tool, or app), that integration generates a block of JavaScript that represents what the “average” company uses to implement the vendor’s tag. Most of the time, that’s all you need – you just specify which pages the tag goes on, where to find the data the tag needs, and you’re done. But the ability to customize that code block when you need to is important – because every once in awhile, you’re bound to want to work with a vendor in a slightly different way than everyone else does – and the alternative to customizing the integration offered by the TMS is just to write your own completely. Isn’t that one of the main problems you were trying to solve in the first place.

3. The ability to handle frequent, repetitive tasks without a developer. The original promise of tag management was that you could add third-party tags to your site without a developer. The past few years have proven the fallacy of that idea – but it sure is nice to let your marketers make basic changes to tags. If you decide you want to capture the page title in an Adobe eVar, or that you need to pass the product name to Adwords or DFA, those are simple changes you shouldn’t have to send to a developer. It should be easy to get data you already have (and have already configured in your TMS) to other vendors that want it.

4. The ability to send the same data in a slightly different format with little effort. If you’ve spent even the slightest time looking at what data you’re actually sending to your tag vendors, you’ve seen some common threads. They all want the same things: which products a customer purchased, how much they paid, the unique ID generated to a web lead in your CRM, and so on. But they likely want this data in a different format: one vendor may want a list of products delimited by a comma, and another may want them delimited by a pipe. A good TMS has integrations that don’t require you to customize the format of all this common data – it will do it for you.

5. Support for events, interactions, and data that changes throughout a page’s lifecycle. We’re moving from the world of multi-page to single-page web apps. While your TMS likely offers you a way to track these interactions, look for one whose API most closely matches the model used by your IT team – whether it’s JavaScript you’ll have them add when interactions occur, or the ability to “listen” for events they’re already capturing. And make sure that as you configure data elements in the system, those elements can be updated throughout the page’s lifecycle – it’s incredibly annoying to have to develop a hack to something as common as that an unknown user authenticates on your site using Ajax, but your TMS doesn’t know because when the page first loaded the user was still anonymous. Your development team will be more supportive of tag management if they feel the tool supports them – rather than the other way around.

6. Consideration for tag optimization and caching. Besides decoupling your IT release process from your digital marketing and tagging effort, it’s possible that the greatest potential benefit in migrating to a tag management system is the improvement it provides to your website’s performance. But the TMS should allow you the flexibility to fine-tune that performance benefit by loading only the code and logic required for the tags on that page, rather than loading the code and logic that could be required for all tags used across your site. Even if all that logic is cached, it still needs to be run on page after page after page. In other words, there’s no reason for your homepage to load code that doesn’t actually need to run until it’s time to fire order confirmation tags. I also love it when a system allows you to cache code and reuse it throughout the site when you need the same basic tag throughout your site. If you load a Doubleclick tag on 50 pages on your site, and the only difference is the ‘type’ or ‘cat’ parameter, there’s no reason for the TMS to reload an uncached version of that logic on all 50 pages – load it once and have it run again and again from the browser cache. If the TMS allows you to manage those subtle differences in a single place rather than in 50 different tags, this also offers a huge benefit to the folks managing your tags, who now can support a single tag implementation instead of 50. Even small optimization features can make the end-users of your TMS and your website very happy.

So if you’re new to tag management, hopefully this list helps you choose the tool that will be the best fit with your organization. And if you adopted tag management earlier, hopefully it it helps you make sure you’ve got the right system in place – and the right processes to manage it. I’ve tried to come up with a list of features that will appeal to both developer and marketer end users, because both play an important part in a company’s digital marketing efforts. And in the end, that’s what tag management is really about – all these tags serve no useful purpose on your website if they’re not allowing you to run your online business more effectively.

Photo Credit: Bill Dickinson (Flickr)

0
Tag Management

Time for Tag Management Vendors to Grow Up

Posted on by Josh West

As I have written before, Analytics Demystified are big fans of Tag Management Systems, and I believe we are at the point where our entire client base is either on TMS or will be in the very near future. The advantages of TMS, especially when coupled with solid governance and the right resources managing the technology, are so many that we have simply stopped counting, and our most advanced clients are starting to do things with tag management that we’re not sure even the vendors imagined.

Speaking of tag management vendors, sometimes watching the competitive landscape evolve is like watching the entire 10 year evolution of the web analytics sector happen in fast-forward … good, bad, and ugly. Market share is constantly in flux, outside (investor) interest ebbs and flows, prices are falling, employees are moving around, and sadly we are seeing the same snippiness, FUD, and otherwise uncouth behavior that characterized the worst aspects of our industry during the early days.

Sigh.

Fortunately for all involved, many of the TMS vendors have banded together with the World Wide Web Consortium (W3C) and have authored a first-of-its-kind proposed standard for the creation of the digital data layer that forms the foundation of every “best of breed” tag management deployment. The group, chaired by IBM’s Viswanath Srikanth, had 100+ participants and over 50 companies contribute to the creation of the specification which is now available for download via the W3C.

How cool is that?

Built around a common set of definitions and widely used Javascript, the document outlines how data layers can (and should) be built to facilitate the deployment of tag management systems. What’s more, assuming the vendor participants in the W3C working group follow through on their commitment to support this standard, those companies leveraging the W3C work will essentially enable a “plug and play” environment allowing for even greater portability of systems including TMS.

At Analytics Demystified we are excited to start leveraging this document in our client work and are looking forward to years of growth in the TMS sector. We never had any kind of standard in the early days of web analytics — the technology didn’t lend itself to it and the competitive landscape would have never let it happen. Hopefully the participation of many of the major vendors and their commitment to support the W3C standard will demonstrate that the aforementioned “snippiness” is just growing pains and the TMS sector will mature as quickly as they emerged.

If you’d like help interpreting the W3C document and deploying tag management on your sites drop me a line, we’d love to hear from you.

 

0
Tag Management

TMS Best Practices: Get the Data Layer Right

Posted on by Josh West

Over the past year or so, I’ve had the opportunity to see some “do’s” and “dont’s” when implementing a tag management system. I thought today I’d share some thoughts on the most important item on the “do” list: Every good TMS implementation I’ve seen is supported by a carefully planned, well-documented data layer.

The initial sales pitch used by the various vendors – and by marketing folks to their IT departments – is often that a TMS will solve all their problems. Among other things, a TMS can do the following:

  • See any piece of data in the DOM
  • Bind to any DOM event
  • Replace all your tags with a single tag

Companies often assume that these three things mean you’ll never need to engage your development team again. While a good tag management implementation will definitely make the lives of marketing and IT folks easier, this just isn’t true. And if you try to make it true by relying exclusively on what you can see on the page and in the DOM, you’re likely to give yourself major headaches at some point – because what you can see changes way more often than anyone realizes.

Developers are notorious (I speak from experience) for looking for ways to simplify code, make it more semantical, and remove things they think are no longer needed. In almost all cases, this is a good thing. But what is no longer needed for a functioning web application may still be mission-critical to your web analytics implementation. Consider the following code snippet:

 

Lets say you log into your TMS of choice, and you set up your add-to-cart tracking in the following way:

  • Attach an on click handler to all links with class “add”.
  • Find the parent <div> and use its “data-id” attribute as the product ID.
  • Grab the nearest <span> with class “price”, remove the first character (dollar sign), and treat that value as the current price.
  • Track an “add-to-cart” event.

That’s exactly what you bought a TMS for, right? To make your life easier – and boy, was it easy to set up that tracking for your new cart add functionality. But how quickly it can all go wrong:

 

  1. What if your developer decides to change the markup for price, to separate the price from the currency. Now, according to your analytics data, your new price for this item is “.99”. Ouch!
  2. Next, your developer decides that “data-id” is a poor name for your product IDs, because all your IDs start with “SKU-“. Wouldn’t it be better to use “data-sku” instead? Now you’re tracking cart adds, but not cart adds by product ID.
  3. Finally, your development team loves HTML5, and they decide that <article> is more semantically correct than <div>. But your tracking depended on a CSS selector of “div.product”. At this point, your tracking is completely broken.

These are just a few reasons that I strongly recommend that my clients to create a data layer – that is, a catalog or dictionary for all the data points used by all your third-party tags. Your data layer should primarily be made up of a single JavaScript data object, and depending on the vendor you choose, this may be required.. But even if your tool doesn’t require it, you should do it anyway. A data object is a logical, semantical, code-based representation of all the key information we might want to know about a page when it loads:

  • The page’s name
  • Site-related information (site name, country and language)
  • Visitor-related information (login ID, logged in or out)
  • Any events taking place as part of the user loading the page (product view, internal search, etc.)
  • If an e-commerce site, any product-related information (the product being viewed, all products in the cart, etc.)
  • Any other information that might be required or useful to track the page via your analytics tool or any other third-party tags

In code, your data layer may end up looking something like this:

 

Having a good data layer in place makes your life much easier when using your TMS to implement your tags. You’re left with a simple mapping exercise to make sure that all the right data points end up going to the right tags, rather than having to use Firebug to find every possible piece of data you may want in the DOM, and then write code to access it correctly.

Let me leave you with 10 tips to build a data layer that works for you (and not the other way around):

  1. Most importantly, document it. Create a shared, central document that shows each item in your data layer, how it is set, how it can be retrieved, and which tags use it.
  2. Use a dedicated data object. In some cases, you may still rely on query parameters, cookies, or the DOM, but you should have high confidence these values won’t change. Having all your data in one place makes it less likely that a code change will ruin your data.
  3. Make your data layer as granular as possible. For example, your page name may combine country, language, and a friendly page name. Separate those into 3 unique elements in your data object, and then use your TMS to combine them together. This preserves your flexibility if you ever change your mind.
  4. Use terminology that makes sense to your organization. If you use the term “order ID”, you shouldn’t care that SiteCatalyst calls it “purchaseID” or DoubleClick calls it “ord”. Your TMS will take care of that.
  5. Don’t overload or overcomplicate. If an element isn’t used on a page, either don’t include it in the data object for that page, or set it to an empty string. Values like “null” can cause problems in your code and yield strange values in your reports.
  6. Use string representations of “true” and “false” rather than booleans. This might drive your developers crazy, but it’s much easier to check for certain strings than booleans in JavaScript (while very cool, the difference between “==” and “===” in JavaScript isn’t the easiest concept for non-developers to understand).
  7. Consider setting numeric values like prices to strings. This may require some extra code in the event that calculations are necessary, but you’ll have fewer times when you need to calculate than when you’ll want actual strings, so it’s easier just to stay consistent.
  8. Understand the trade-offs between using nested objects and arrays. For example, your developer might prefer an array of product objects to represent your shopping cart, but your TMS vendor may prefer several arrays of each product attribute (one for IDs, one for names, etc.). A single array of objects may be more semantically correct, but it’s much faster to loop through several arrays that have all their items in the same order. Your tool may make this decision for you – but know why you’ve chosen the approach you have.
  9. Don’t be afraid of quick fixes – but don’t be afraid to “fix your fixes”, either. Sometimes you’ll be in a hurry and might need to rely on DOM manipulation or quick fixes for your tracking. Make sure these are clearly documented, and work to move that data into the data object as quickly as possible.
  10. Hold everyone in your organization accountable. Make sure your data layer stays accurate over time, and that it remains the single source of truth for all your tags. If your data layer is accurate, your data will be accurate, too.

Getting your data layer right is the most important thing you’ll do when implementing your TMS. It’s what allows your development team to be website experts, without needing to be experts in every tag you might use. But it also forces marketers adhere to the centralization that was likely a key reason IT went along with the TMS in the first place. So get your data layer right – and keep everyone happy, all the way around!

0
Adobe Analytics, Tag Management

Adobe acquires Satellite – what next?

Posted on by Eric Peterson

The Twitterverse was buzzing this morning about Adobe acquiring Satellite from SearchDiscovery, and while neither side has yet to make a public announcement, I have gotten confirmation of the big news. Suddenly, my post from a few days ago feels a bit dated! Time will tell how large the ripple effect from this acquisition turns out to be, but it definitely has the potential to shake up a young, dynamic market. I haven’t had as much experience using Satellite as I’d like, but I expect that to change quickly. I’m really intrigued by this move, because I feel like both companies bring exactly what the other needs:

  • Adobe provides tag management at the best possible price (free to clients) but has struggled to gain much traction with its own tag manager, largely due to the heavy focus on Adobe technology.
  • Satellite has a fresh UI and a really innovating approach to tagging – but so far, heavily funded start-ups like BrightTag, Ensighten, and Tealium have been playing with a bit of an advantage. This move can really help Satellite expand its reach.

Clearly with this acquisition the team at Satellite will greatly benefit from Adobe’s position with the enterprise. Adobe now has a unique opportunity to take Satellite’s core offering and add real value to it. And it definitely fits with Adobe’s strategy of acquiring smaller, up-and-coming firms (Neolane is the most recent example) and give them a bit of extra “juice” to take that next step.

Congrats to both companies! I look forward to seeing your growth together, and also to see where this takes the rest of the industry.

0
Analytics Strategy, Tag Management

Tag management systems: How do I choose?

Posted on by Josh West

Since I joined Analytics Demystified a few months ago, I’ve spent quite a bit of time deep-diving into the various tag management tools. I had worked with most of these tools previously, but I’ve had the chance to meet with their leadership and development teams, and really get a feel for where they’ve come from, where they’re heading, and where the industry is at generally – so I figured I’d share a few thoughts.

In the early days of tag management, the leading tools either offered only professional services and no product (“Hey, just let us write all your analytics code for you in a central place”), or just made a developer manage tags in yet another environment that they weren’t familiar with. These tools are much better now, with the idea of a data layer, “tag templates”, and the ability to easily connect your data to your tags.

Still, there’s a lot of room for improvement, and in my view there isn’t one single tool that addresses all of the challenges that a dynamic, data-driven organization faces in their quest for rapid deployment, data integrity, and marketing agility. Here are my top three questions that a company must answer when choosing a tag management vendor:

  1. Am I trying to remove my development team from the tagging process – or am I trying to free my tagging process from my development team’s deployment cycle?
  2. What role does testing and optimization play in my organization?
  3. How do I prioritize scalability, speed, and tool usability in my selection of a tag management system?

Question #1: Am I trying to remove my development team from the tagging process – or am I trying to free my tagging process from my development team’s deployment cycle?

The historical schism between Marketing and IT becomes the central question when it comes to tag management: how can the enterprise improve their analytical efficiency? On one hand, the development team doesn’t want to “waste” time and effort on tagging anymore; on the other, the marketing team is frustrated by the lengthy release cycles their development team offers them to release new tags.

If you’re trying to solve for the first part of the question, you may be in for an uphill battle and might end up disappointed. Even the most user-friendly tools don’t totally remove the need for a developer. After implementation, a marketer may be able to add the simplest conversion or remarketing tags, but web analytics tags like Adobe Analytics (formerly SiteCatalyst) are complicated, especially with dynamic interactions to be tracked after a page has loaded. You should plan on needing some development help even after implementing a TMS, though it will be less than before.

It’s a much more realistic goal to address the second question and separate your tagging from traditionally lengthy release cycles. Your development team may still need to help you write some code to target a particular page event, or write some custom JavaScript to manipulate a particular value in your data layer for a new tag – but (ideally) they can do it without being tied to a release several months in the future.

Regardless, these questions aren’t as much a TMS selection question as an internal process and governance issue. When you have answered the question your TMS choices will narrow, but if you don’t address this question “head on” no TMS will help you.

Question #2: What role does testing and optimization play in my organization?

Optimization is becoming increasingly critical for data-driven organizations, and unfortunately, it’s the most difficult use case for a tag manager to address. This is because according to best practices, testing tags must load synchronously on a page to function properly. For example, the Adobe Target (formerly Test&Target) “mBox” blocks everything below it from loading, by design, until Adobe returns the new content.

On this specific point I see the current TMS vendors as being differentiated. Ensighten is the current leader in providing easy integration with optimization tools; it is also the only tag management system whose best-practice implementation starts with a synchronous tag. Conversely, Tealium and BrightTag use an asynchronous tag, which has several advantages, the most common being no page blocking. This is ideal for almost any tag except optimization tags. Both these tools offer a synchronous deployment approach and other alternatives to prevent “flicker” when the page loads, but they are not as simple to implement.

On the question of testing, at least for now you will need to decide if you value an asynchronous tag or the ability to stick with a standard tagging strategy for your optimization program.

Question #3: How do I prioritize scalability, speed, and tool usability in my selection of a TMS?

As I mentioned earlier, each of the tag management leaders have strengths and weaknesses. Three important factors to consider when choosing a TMS are scalability, speed, and usability – and there isn’t a single tool currently available that has cornered the market on all three.

  • Scalability: You want to choose a tool that can grow with your organization. Ensighten and BrightTag both utilize a tag that combines client-side and server-side technology. IT departments and security teams often worry about overloading the DOM – and while there is a limit to what you can do with a purely client-side solution, I’ve found it to be more of a “theoretical” limit. If your TMS-deployed tags are still slowing down your site, it’s probably not the tool’s fault! You can succeed with either approach if you plan well and execute on that plan – but it’s up to you to decide what works best for your tagging roadmap.
  • Speed: The flip-side to that additional server-side request is speed. Every bit of code delivered by Tealium can be served from a static CDN (like Akamai), which means it can potentially load much faster than a tool requiring server-side technology – and they, BrightTag, and Ensighten support the bundling of your most commonly-used tags, which speeds things up even more. With careful planning around your tool’s scalability and speed constraints, any of these tools can likely yield a successful implementation – but you need to be aware of the strengths and weaknesses of your tool.
  • Usability: The first releases of the leading TMS tools were clunky from a usability point-of-view. Instead of being able to manage your tagging code within your CMS, in an environment you were comfortable with, you had to cut and paste your tags into a less familiar tool. Now, all the major tools offer “tag templates”, which simplify and standardize the implementation of the leading tags. Right now, Tealium’s template library and collection of helpful extensions is the richest and most user-friendly, and now everyone is heading in that direction. A good tag manager will have the capability to access critical data on the page – BrightTag’s data binding features, for example, are great at this.

Two last points before I wrap up:

  1. I’ve intentionally tried to focus primarily on strengths, not weaknesses, of the products I’ve mentioned – to identify areas where a particular product does something really well. But don’t read too much into not seeing a product mentioned with a particular topic. Plus, I value our partnerships with the various tag management companies – and I obviously have lots of friends and former colleagues scattered throughout the industry.
  2. It’s quite possible your company uses or has researched a tag management tool I didn’t specifically address. For the most part, I tried to stick to the tools our clients use most frequently, because they’re what I’m most familiar with. But there are a few other tools I really need to get my hands on, and as soon as I do, I’ll share my thoughts on them as well.

In summary, when you choose your TMS, it will be critical to identify your top requirements and make sure you pick a solution that covers them best. You’ll likely encounter some trade-offs along the way, because there’s not a perfect tool out there. But any of the solutions can make your life easier and improve the speed with which you can deploy your tags.

At Analytics Demystified, we’re excited about the trends in the industry – and we’d love to talk more with you as you consider which tool works best for you!

0
Analytics Strategy, General, Tag Management

New White Paper on Tag Management from Demystified!

Posted on by Eric Peterson

Lately it seems like nearly every conversation I have with a client or prospect touches on Tag Management Systems (TMS). If it’s not a client or prospect, it’s a Venture Capitalist asking who they should throw money at, or it’s a new TMS firm pitching us on why they are the “easiest, fastest, most best-est TMS in the Universe …” Were I a less patient man I would probably stop answering the phone; were I more patient, I would probably author Tag Management Demystified …

Turns out I fall somewhere in the middle.

In the midst of spending hours every day talking about TMS with a variety of interested parties, and while helping our clients select and deploy a wide range of tag management solutions, I have somehow managed to find the time to do two really great things. The first was to attend the Ensighten Agility conference a few weeks back in San Francisco, the second, to assist Demystified Partner Brian Hawkins in authoring a great new white paper on Testing and Tag Management.

Ensighten Agility was a treat to attend. I had missed the event the last two years due to a variety of schedule constraints, but it was amazing to see how Ensighten’s presence, team, and customer base has grown in such a short amount of time. Josh Manion and his team are to be applauded for putting together such a wonderful event and for getting great speakers, ranging from my personal favorite Brandon Bunker (Sony) to the always popular Joe Stanhope (formerly of Forrester Research, now at SDL) and a very funny presenter from Microsoft who’s name I will omit since she shared perhaps a little more than her corporate handlers may have liked.

At Agility, Analytics Demystified Partner Brian Hawkins had the opportunity to speak and present a technical perspective on how TMS like Ensighten are being used to dramatically accelerate the testing and optimization process within the Enterprise. Brian is our lead for Testing, Optimization, and Personalization at Demystified, and his tactical chops were on full display during his speech. In a nutshell, if you’re not leveraging TMS for testing … you’re missing a HUGE opportunity.

Interested? You should be!

Fortunately for you, just in case you missed Agility, Brian has teamed up with Ensighten to author what we believe to be the definitive piece on testing and tag management. Even more fortunately, the nice guys at Ensighten are making the white paper freely available for download via their web site!

Download “Empowering Optimization with Tag Management Solutions” now from Ensighten

If you’re interested at all in tag management, especially if you’re interested in tag management and testing, reach out and let us know. We have a ton of experience with the former … and have more experience than anyone with the latter … and we’re always happy to help.

0
Analytics Strategy, Tag Management

The Evolving Tag Management Marketplace

Posted on by Eric Peterson

Today started with a flurry of communication about Adobe’s intent to start giving their Tagmanager product away to all SiteCatalyst customers at no charge. I see this change as having significant impact on the larger tag management and digital analytics marketplace, so I figured it was worth writing about.

Adobe’s news, confirmed but still not official, follows the launch of Google’s free Google Tag Manager by just over a month. This timing may be a coincidence — stranger things have happened — but it is just as easy to imagine that someone in Adobe decided that it was better to shake up the tag management market than to try and compete head-to-head on more robust, less expensive, and more widely adopted solutions. Additionally it is worth noting that IBM/Coremetrics made a similar decision months ago, essentially to provide access to their Digital Data Exchange product at no charge to customers.

For those of you keeping score at home, from the perspective of the traditional web and digital measurement vendors, here is broadly how things look today:

Vendor TMS Strategy TMS Cost TMS Maturity
Adobe In-house Product Free Emerging Platform
IBM In-house Product Free Emerging Platform
Webtrends Third-Party Solutions $ to $$$$$ Varies by Vendor
Google In-house Product Free Emerging Platform
comScore Third-Party Solutions $ to $$$$$ Varies by Vendor

As you can see, three out of five of the market leaders as listed by Forrester Research in their Q4 2011 Web Analytics Wave report are currently providing their own in-house tag management product to customers at no charge. Only Webtrends and comScore at this point are left relying on third-parties, essentially forcing customers to either allocate budget, negotiate contracts, and manage another vendor or leverage Google’s tag management platform, a frightening prospect these days given Google’s continued push into Enterprise-class analytics.

What’s more, the real impact will likely be felt less in the halls at Webtrends, IBM, Google, and comScore and more at stand-alone tag management vendors like Ensighten, BrightTag, Tealium, TagMan, and others. This group, well summarized by Joe Stanhope in his recent report “Understanding Tag Management Tools and Technology”, breaks along two lines of maturity: Emerging and Mature.

By “Emerging” I mean simply platforms that are earlier-stage start-ups, built on open source code bases, or otherwise not a full-bore efforts on the part of leadership teams and investors. In this group I count Search Discovery’s Satellite product, UberTags, Tag Commander, and until recently SiteTagger (who were acquired by BrightTag this past August.) I also count the offerings from Adobe, IBM, and Google in this list — each are a great first-effort from their respective owners, but each have functional gaps relative to the mature platforms listed below.

The “Mature” platforms, at least in my mind, are BrightTag, Ensighten, Tealium, and TagMan. Each of these companies are growing, well funded, stable, and reasonably focused in their efforts to create value for the tag management market and their shareholders alike. And, while I admittedly don’t know the TagMan guys very well, the other three are all known to Analytics Demystified to have happy and satisfied Enterprise-class customers who are increasingly dependent on their platforms for their analytics and optimization strategies.

The challenge all of these companies now face is this: without regard to relative maturity or technical sophistication, the two biggest companies in the digital measurement space (Adobe and Google) are now giving away tag management. What’s more, Adobe’s solution is essentially already deployed as part of most SiteCatalyst customer’s existing deployments, giving Adobe PR the license to declare that “Tagmanager is the world’s most widely deployed tag management solution” if they wanted.

Touche, Adobe. Touche.

While without a doubt the usual platitudes about “rising tides” and “market education” will be brought up, as will the typical FUD about “fox in the henhouse” and “vendor lock-in”, I wanted to drill down a little and provide my personal perspective on who Adobe’s announcement helps and who it hurts. Feel free to disagree with me here in comments … I know not everyone will like what I’m about to say.

Who Adobe Giving Away Tag Management Helps …

In the short-term, Adobe’s announcement helps more or less every SiteCatalyst customer who has been wondering if tag management is right for their company. The pricing barrier is gone, the deployment barrier is gone (assuming you have the right code base deployed), and for the most part the decision barrier is gone. You don’t have to decide whether it’s right to send even more data to Google … you’re already in bed with Adobe so pull those covers up a little more and snuggle in for a long Winter’s, umm, adventure learning how to actually leverage tag management.

Okay, that analogy stunk. Sorry.

Once Adobe flips the switch, every company leveraging SiteCatalyst has the immediate green light to start to explore tag management. Keep in mind, as with everything else, it’s not the tool you use, it’s how you use it … and if you’d like help getting started with the actual process of tag management please let me know. Analytics Demystified is very experienced with the process of bringing TMS up within the Enterprise …

Adobe’s announcement (again, when they officially make it) will also have that “rising tide” effect I alluded to above, without a doubt. Especially considering the money that Adobe is spending on advertising and marketing lately, if Tagmanager is rolled into that it is likely that an even greater number of CEO/CIO/CTO types will be asking their analytics teams about tag management, thusly generating substantially more interest in the topic at vendors across the board.

Longer-term, Adobe and Google’s announcement will help all companies. Trust me here, tag management is the future of digital measurement, analysis, and optimization. Based on work with our clients in the past two years, tag management is Pandora’s box — once it’s opened you can never, ever return to the way things were. And while I certainly don’t want anyone reading this to think that “tag management is easy” — it’s not — with the right people, process, and technology in place, tag management is enabling a whole new type of digital analytics. Again, contact me directly if you’d like to learn more about how tag management might be able to transform your company.

Who Adobe Giving Away Tag Management Hurts …

Much the same as I opined in my Good Guy/Scumbag Google blog post on the same subject, the Adobe announcement is not all good news. While Adobe customers can certainly bask in the altruism of their vendor — regardless of the reason they decided to make Tagmanager free … free is free — not everyone can be happy about this.  Here are a few companies who I think are going to be hurt by Adobe’s decision:

  1. Adobe’s competitors in the digital measurement space. Within the Enterprise market I certainly consider Adobe the market leader. While they are certainly not perfect, post-acquisition I have seen a steady increase in the focus and commitment the company exhibits towards the analytics market and, while I can never be entirely sure if they are actually leading the way or just following very quickly, the result is the same and Adobe continues to log impressive wins in the market. Giving away tag management — even if they have been doing it all along as a practical matter — only makes them a stronger competitor in the RFP process up against the likes of IBM, Google, Webtrends, and comScore. Seemingly overnight, free tag management has become “table stakes” in the digital measurement arena.
  2. The Emerging tag management vendors. Here the pain is equally inflicted by Google and Adobe. To me it is not clear that companies will continue to pay for a solution that has, in the blink of an eye, moved from the hottest technology out there to a commodity market. Yes, Adobe and Google’s solutions are emerging themselves, and  yes, each has as many limitations as they do advantages, but the one thing that Google buying Urchin years ago has taught us is that “free” is very compelling, especially when the final value proposition from the change being considered is not 100% clear.
  3. The Mature tag management vendors. I suspect that today was one of those “ugh, f*ck” days at Ensighten, TagMan, Tealium, and BrightTag … a day that is sadly increasingly common. The competition among these four is fierce, and I suspect the last thing that any of the executives and investors at any of these firms wanted to see on the heels of a free Google entry was a widespread and automatic deployment of a no-cost tag management from the platform (Adobe) that, honestly, benefits the most from tag management in the first place. To be fair, each of these vendors has a technological and methodological advantage over both Adobe and Google — each in their own way — but again, I consider it likely that at a minimum sales cycles will lengthen, prices will be forced down, and future rounds of investment will be somewhat harder to come by.
  4. Tag management investors. Tag management vendors of all types have seen substantial investment from venture capitalists around the globe. Given my writing about tag management I have spent countless hours on the phone with investors considering getting into the sector and, on every call, I was inevitably asked “do you think Google or Adobe or IBM will get into the space?” Now we have our answer, and what’s more, each of these three companies see a greater advantage in having their code deployed than they do trying to use TMS to drive revenue. Unfortunately revenue and adoption is the name of the game for investors, and that game just changed.

I suspect that there is some argument to be made for “this decision by Adobe (and Google) hurts everyone” given that if I am right about points #1 through #4 above it is likely that innovation in the tag management space will slow. Here I am not so convinced — knowing the leaders at most of the Mature TMS vendors moderately well I rather expect them to respond to Adobe and Google by making even better, even more sophisticated, and even more compelling offerings for as long as the market will let them. These guys are a smart bunch, and not a one of them to my knowledge is a quitter, so I expect them all to put up a good fight … driving innovation.

Again, for at least as long as the market will let them.

What do you think? Are you using SiteCatalyst and ready to give Tagmanager a try? Are you more likely to consider SiteCatalyst because they’re giving tag management away? Or does Adobe’s decision not really change your approach towards TMS … and if not, why not?

As always I welcome your comments and thoughts.

0