DTM permissions and workflow

Some time ago, I received an urgent call from a customer that claimed that DTM broke their website. They wanted to see me immediately, as that was causing a huge impact in them. Fortunately, the problems only manifested in staging, but they could not move to production. Once I arrived at my client’s office, I immediately realised what had happened: the data analyst had created some data elements using JavaScript he found on the Internet and he just copied and pasted the code. The code worked on his computer, so he went to approve and publish it. The reality was that his code only worked in IE and crashed in other browsers.

As I have already explained, there are many benefits from using a tag management solution. However, with great power, comes great responsibility. Using DTM does not mean that marketers can implement anything they want and publish rules as they like. To the contrary, they must be very strict. The previous example is exactly the opposite of what must be done.

The solution I suggested to my client is to follow a very strict workflow and use wisely the permissions:

  • Anybody who needs to create new rules should be given the User role. This allows the user to create new rules and make sure they work fine using the right DTM plugin.
  • You need to have a group of testers that have the Approver role. They are responsible of making sure the new rules not only work fine in one browser, but they are cross-browser compatible, do not break the website, capture the expected data…
  • Once the rules have been approved, it is time to publish them. Very few people should have the Publisher role and publishing rules should be done very carefully, just like a typical code release.

Workflow

Some additional recommendations:

  • Publish rules at a certain time every week, so that, in case something goes wrong, it is easy to identify that the new rules are the culprit and roll back to the previous approved version.
  • Get some developer’s time in order to create JavaScript rules. He will probably need 5 minutes per rule and will do it right the first time.
  • The testers, ideally, should be the same as the website testers, so that the tests are full tests, with the right tools and environment.

Custom conditions in DTM

When creating both page load rules and event based rules in DTM, you have the option of configuring some conditions to determine when to fire those rules: parts of the URL, cookies, browser properties, JavaScript variables… If you add more than one condition, the AND boolean operator is applied to all conditions. However, in some cases, these out-of-the-box conditions are not enough. Thankfully, DTM offers the custom condition, where you can write pure JavaScript.

The first thing to note is that the snippet of code must return a boolean. It might work with expressions that can be evaluated as true/false (like empty/non-empty string, 0 or different than 0), but I have just not tried them. In other words, there must be a return statement within the code. In fact, the return statement must be at the very end of the code.

This code will NOT work:

condition_not

What I always do in this situation, is create a variable named ret and return it at the very end.

condition_yes

Execute JavaScript in event based rules

If you create an event based rule that is fired upon click of a link and you want to execute some JavaScript, chances are that, if you add it to the “JavaScript/Third Party Tags”, it will never be executed. The reason is that the browser has already been instructed to unload the page and move to a new URL. It will not have time to load an external JavaScript and executed; if fact, I think that it will not even attempt to do it.

What can you do in this case? Use the custom condition of the rule, to make sure the JavaScript is executed. For example, to write a cookie:

custom_js

There is no need to return true in this case. However, it is more convenient to leave it as shown, as the console will then show the rule as executed.

Capture information from the clicked element

Imagine you have an event based rule in which you want to capture the full URL of the clicked linked and store it in prop1. Your first idea would be to create a data element that returns this.href:

de_this

However, one limitation of data elements is that they have no idea of what DOM element has been clicked, if any. If you try to use the this keyword in data elements, you will get a surprise: it will not work as expected.

One possible solution is to go to the custom code of the Analytics section as set the value there:

custom_code_this

Remember to include s.linkTrackVars if you are making an s.tl() call.

I do not like the previous approach, as it is not elegant and you need to explicitly open the editor to see the contents of the rule. My preferred solution is to use the custom condition and set a data element on the fly; then, in the analytics section, just reference the data element as usual:

custom_setvar

prop_de

 

Do you have any other uses for the custom conditions in DTM? I would love to hear your opinions on that.

How to organize a web analytics team

A few months ago, I was working with a customer on premise and the manager asked me a tricky question: how to organise the analytics team. That company was undergoing significant changes in the analytics front, as a few key members of this team were leaving. As with most questions in life, there is not a clear and definitive answer to this particular one. However, I can share what I have been seeing in my customers.

When companies are small, they inevitably go for cheap or free web analytics solutions. In fact, this is a no-brainer, given the cost of the licenses of proprietary solutions. In these companies, there is only one person in charge of the task of analysing visitor’s behaviour and, usually, this is only one of the many tasks he has to do. As the importance of web analytics grows, this person ends up working full time on web analytics. Sometimes, a second person joins this mini-team, but within a broader team that manages all internal analytics and reporting.

The next breakpoint happens when the company as a whole realises the benefits of having a very good understanding of the customer behaviour. In this situation, more and more people want to have access to the statistics gathered by the analytics tool. Not just only the web analysts, but others in the marketing department (or even other departments) want to have first hand data. These other roles do not need full access nor are going to spend their full working day on the web analytics tool, but they want to be able to self serve. As a consequence, more people demand more features and capabilities.

Inevitably, this approach leads to larger analytics teams, with a manager and a team of two or three people that are working full time on all aspects of the analytics: reporting, ad-hoc analysis, implementation, supporting other users… But not only that, another consequence is that free solutions become a problem rather than a solution and more powerful tools are needed, like Adobe Analytics. As an example, I remember one company switching to Adobe Analytics just because their previous solution did not scale well.

The last big change comes when the websites and apps are in continuous development, constantly adding new features, with releases every few weeks. It becomes impossible to keep up with the changes in the development and, at the same time, satisfy the reporting needs. At this point, there is a need to split the web analytics team in two: one dedicated exclusively on the implementation and another on the reporting. These two teams have different line managers, although they are closely connected.

Even in this situation, there is still room for improvement, especially in big corporations. You can see further separations in both teams for apps/web, different websites, desktop/mobile web…

In parallel to all of this process, there is another tip I would like to share. The web analytics job market is fairly small, but very dynamic. There are very few good web analysts and recruiters are always luring web analysts to fill vacancies in other companies. It is therefore very important to have a healthy balance between junior and senior analysts. Both are needed and junior team members need to receive a good training to be able to fill in the gap when more senior members or even the manager, eventually leave the company.

As I said, this is only my experience, but after having worked with dozens of companies, where this pattern tends to repeat, I am inclined to believe that this is the best approach as of today.