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.
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.
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.
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
This environment is different. There will be no development here, and … sorry? Why are the web analytics guys laughing? Did I say something funny?
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.
5 thoughts on “DTM Property – Report Suite – Staging/Production”
As a good practice, I try to use the DTM Switch plugin to test most new/updated staging rules on the Production environment. No matter how hard IT tries, there are often small differences between how the staging and production platforms work/perform, so this is just another level of testing.
Of course there are times when that is not practical, such as when a new rule is using a value which is only available on staging since the code setting that value has yet to be pushed to production. But even then there are tools which may be able to help, such as Charles. Say if your DTM rule is using a new value set within an updated .js file, you can tell Charles to use the staging version of that file on the production site.
It’s not always practical to test on Production, but it’s a good idea when possible and I’ve caught a few issues which would have gone live if I hadn’t done it.
Very close to what I do.
I guess the rift between IT/dev & marketing/WA is bigger than we think it is…
thanks for the great article. I am setting reportsuites dynamically based upon the URL using custom code. Is there a way to check for staging/production within the custom code? Otherwise a user could go to the production url, switch to staging and send data to production report suites.
Absolutely! There is a “sdsat_stagingLibrary” property stored in localStorage which you can read like so:
Great! Thanks for the quick reply!