DTM Property – Report Suite – Staging/Production

Most developers who work with web sites are working on multiple environments. You’d at least have a development and production environment.

Web analytics is no different, we also have different environments. We have different environments in different areas, actually, to the point where I feel I need to explain what there is and how you should use it.

If you have followed this blog, you already know that Adobe Analytics has a concept called “Report Suite“, which is sort of a data container. You might also have grasped that the Tag Management tool (DTM) has “Properties”, and that there is a browser plugin that allows you to test “staging” code in your browser.

All of this is completely independent of your dev, staging and production environments.

Here’s how you should think about / use all of it.

Overall Setup

In DTM, you should have a single “Web Property” that you will use for your dev, testing, and production environments.

A Web Property contains all the “Tools” (Adobe Analytics is a “tool”, as is Google Analytics and Adobe Target), Rules, and Data Elements that are relevant. Those are obviously the same across dev, testing, and production. So one thing is easy: you need a single Web Property per site.

In Adobe Analytics, you should have one “Report Suite” per environment, i.e. one for production, one for development, and potentially one for staging, testing, UA, integration, or whatever environments you have.

A Report Suite contains the data. Data is what your friendly marketer uses to gain knowledge and improve performance. Production data must therefore be good data. That’s why data from tests or data generated while you develop should end up separately, and that is why we have a Report Suite per environment.

The different Report Suites are all configured exactly the same way!

There is an exception to that rule, of course.

If a change implies a change in tracking, the system that first gets the change will temporarily have a different Report Suite configuration.

Please make sure you or your friendly marketer check the configuration periodically, and update all Report Suites so they match.

Also, please note that it is entirely possible that the Report Suite that changes first could be production! Marketers are like that.

So much for the basics, let’s now look at your environments.

Development

While you’re developing, you want to try new things. You also want to shield your production environment from what you’re doing in your tests, i.e. not pollute your production reports with test data.

You are likely working on a dev or testing environment for this.

So the first piece of advice is: on your dev/test environment, include the DTM “staging” code.

You can use the production code and switch to staging using the browser plugin, of course, but I think it makes more sense to go straight for the stagin code. Less confusion.

What happens if you do that?

DTM will serve everything that has been put into it, approved and published or not. So you get to see what DTM would do if you published all the changes that are pending. You also get to see the effects of any changes you make straight away.

Depending on how the “Adobe Analytics Tool” in DTM has been configured, it also means that data will be sent to a different Report Suite (not production), which is good.

This is a BAD example:

As I said above, we’d like the Analytics data for the dev environment to go into the dedicated dev Report Suite.

That means that we have to set the report suite ID dynamically, maybe based on the URL or some flag in the Data Layer.

How can you do that? Check out this article and this article. The first one is my preferred method, as you might have guessed.

Staging/Testing/Integration/UA/…

Again, these are environments that are not production. Usually, they’re not quite DEV either. They kind of sit in the middle.

Everything I wrote about DEV applies here.

• Integrate DTM Staging code
• Track into a dedicated staging/testing/integration/UA/… Report Suite

Production

This environment is different. There will be no development here, and … sorry? Why are the web analytics guys laughing? Did I say something funny?

Anyway.

On production, we want to include DTM production code, of course.

We also want tracking to go into the production Report Suite.

The latter can easily be configured in DTM, so there is really nothing special we need to take into account here.

Production – sort of

With the exception of those laughing web analytics people in the back.

They will likely use DTM to modify tracking and other scripting directly on the live site. They want to be able to take the existing site, as it is, and add tracking to it, remove things they no longer need, or even drop totally new tags into it. That’s why they wanted a tag management system in the first place.

The good news is that you don’t have to take any of this into account.

There is a browser plugin that allows anyone to switch to DTM staging on your live site (for Chrome and Firefox). That way, the web analytics people can fiddle with DTM, try whether their code kills anything, and then ask you to review and publish.

The bad news is that you have to review.

And, boy, you should review. Don’t take this lightly. Those guys are no programmers.

DTM allows you to configure a Report Suite for production and one for staging. I said above that for staging, we’d overwrite that dynamically. You still want to set it, though, and the browser plugin in the hands of your web analytics colleagues is why you should.

It is up to you whether you give them a separate staging Report Suite or make them use the same you use for dev. I’d probably give them a separate one.

So there you have it: your recommended setup for making marketing and web analytics happy while still keeping your blood pressure at an acceptable level.