No beating about the bush this time, I’ll just spit out what I have to say:
There is no reason to embed DTM staging libraries anywhere, like, ever!
I don’t actually think this is controversial, more of an example of what I heard a colleague say the other day: “common sense” and “common practice” are not the same thing. Indeed.
It is common sense that you should only ever use the production embed code for your DTM Web Property, but it is common practice to embed staging libraries anyway. Please don’t!
Common Sense
Maybe it isn’t as common sense as I think, so here are my reasons:
Reason #1 — When someone embeds staging libraries on a site (maybe a dev, staging or UA site), then I am unable to test my current tracking on that site, unless I have not changed anything in DTM since the last publish. How likely is that? Unlikely.
Reason #2 — (this one’s worse) Everyone browsing the dev/staging/ua site in question is served my half-baked, non-approved and unpublished Javascript. Why would anyone want that?
Those are two good reasons, and I’m sure there are others. On the other hand, I have not seen a single good reason to embed staging libraries.
And yes, reason #1 is less deadly then it looks. With the right tools (Charles), you can work around it. But why should you have to?
And reason #2 is worse if it is actually me doing the Javascript voodoo, because I am certain most colleagues in our industry do it better than I do. They still make mistakes, we all do.
Doing it the right way
So the correct way to handle this is to always use the production embed code, whether that is for the Akamai-hosted or self-hosted libraries.
Good.
Settled.
Some people need to actually look at the unpublished stuff in DTM, though.
That is not a problem at all.
Analytics people — I am prepared to bet that they know how to use either the DTM Switch plugin or Jim Gordon’s DTM Cheat Sheet and can therefore effortlessly switch over to DTM staging libraries for themselves.
IT/Dev people who are supposed to approve changes — given that the job of those people is to approve changes made in a Javascript-heavy tool, I presume they can easily be taught about the DTM Switch Plugin and or how to manually select staging libraries.
And that’s it, likely.
AEM
Some specific content for those of you working on web sites based on AEM, the Adobe Experience Manager.
The DTM Cloud Service has a tick box that you should tick. This one:
![[screenshot]](https://webanalyticsfordevelopers.files.wordpress.com/2017/10/1711xx-no-staging-prod.png)
(To be honest, the DTM Cloud Service should allow us to treat Author differently, i.e. deploy a different DTM Web Property on Author, because there is a fundamental difference between the published site (Visitors! Doing things!) and Author (your colleagues, generating and managing content), and the tracking should therefore be totally different. I’m sure we’ll have that at some point.)
Your Analytics colleagues will almost always work on the current live site.
Do not be surprised if they never ask you where the dev / staging / UA site is, they simply don’t need those.
They’ll happily head to the production site, switch DTM to staging, and hack away.
The only exception to that is when there is a bigger change coming and you tell them before go-live. In that case, they will go to your dev or staging site and work on their DTM setup, but they can still switch to DTM staging themselves, so that is not an argument for embedding staging libraries.
Thank you!
Web Analytics for Developers 
There is one reason.
If you use Staging, you have this nice out-of-the-box handling of Reporting Suite ID assignment that is driven by the application itself.
Otherwise you have to introduce some custom solution (Data Element-based or [please don’t do this]Hostname-based assignment using s.sa or custom AppMeasurement Library Management disabling the nice feature of nearly-automatic upgrades of the main library). And that often introduces new space for errors (Production data in Staging Reporting Suite).
LikeLike
True.
I actually prefer using custom code with s.sa, and I usually make the corresponding Data Element anyway.
LikeLike
I haven’t decided yet, if in this specific case I should try to disguise the technical details behind a strongly named Data Element like “Environment” : “INT” and deciding the Reporting Suite “behind the scenes” or leaving the developers to decide the exact behavior by themselves by exposing a Data Element called “Reporting Suite ID”.
Do you have any thoughts on this?
LikeLike
I always have a “Report Suite ID” Data Element, and I simply put s.sa(_satellite.getVar(“Report Suite ID”)); into a doPlugins via the “Customize Page Code” part of the Analytics tool.
Simplicity.
LikeLike
I agree that within DTM the use of a staging vs production environments creates a lot of overhead. But as Lukas mentioned here already: the fact that you can link an environment to a specific report suite can be a reason to use different environments.
However, I got the impression that Adobe will enforce the use of different environments even more within Launch. It looks like you will have to publish a tag in development first, then push it to staging and only then you can send it to production. And most important: it looks like putting a tag in the production environment is equal to publishing the tag… So, I expect that the DTM switch will allow you to switch between the environment that is loaded on the page instead of including unpublished tags.
Note: these are assumptions based upon the first looks at Launch. I don’t have hands-on experience yet. So, if someone has: please confirm or reject.
LikeLike
Hi Jente,
That is pretty accurate from what I have seen, yes. We’ll see what a hypothetical “Launch Switch” plugin will do, exactly.
But even with Launch, you could embed a non-production environment into your pages, and even with Launch, I would never add a dev environment. Maybe staging.
Cheers,
Jan
LikeLike
Hi Jan,
We learned fairly quickly that it made more sense to only give the production version of the tags to developers after a couple of instances where they forgot to update the tag as they rolled the site into production.
Cheers,
Trenton
LikeLike
I’ve know people who have been recommending this for years. I’ve yet to buy into it working in my very large organization. The thought of having to explain how to use the Switch tool to dozens (maybe hundreds) of programmers around the world, our varius QA people around the world, vendors who help us QA our marketing tags, and others, is a recipe for disaster. And any of us who have used the Switch tool a lot know how often we forget to switch it back, and the number of emails and Slack messags I get from confused users who forget the same thing is more than enough to negate some of the benefits of using the prod library on all environments.
Also, I’ve run into so many issues with developers not being careful in their coding and causing js errors when the code in the DTM tags try to reference objects that don’t exist on that environment yet. You can say all day long that they should follow good coding practices so that doesn’t happen, but the reality is many don’t. So I get lots of urgent emails from IT asking why some DTM code is causing errors or breaking the staging/dev site, which both takes up my time and makes our team look bad.
And that is just my top 2 reasons, there are more. I’m open to recommendations of how to overcome these concerns; and no, telling me to just educate and/or enforce my Switch rule on everyone in the company is not a valid response (I’ve had a number of “experts” try to tell me that).
LikeLike
I can’t say I agree with this at all.
Firstly, I deploy the staging libraries by default to all our non-prod environments so that if any new changes made by either myself or the broader digital development team break any functionality (either in the website code, application code, or indeed analytics code), they are immediately noticeable when regression testing is done.
Let’s say I make a change to my custom s code library, or I add a page load rule with some custom JS. I want my development team to be able to have visibility of this immediately, so that if this new JS inclusion breaks something else on the website, it can be effectively troubleshooted.
DEV and TEST environments are just that – they are NON-PRODUCTION environments.
Why would you want PROD libraries in a NON-PROD environment??
LikeLike
Sorry, but one other thing:
Why do you think Git uses branches? Would you work on your master/release branch in a NON-PROD environment, or your develop branch??
LikeLike
Cleve & Kevin, you have raised some good points.
I am wondering whether there is a size of org / team where everything changes…
My gut reaction to your arguments was “well, I can build all of that into the code in DTM in one way or another…”, but that makes the overall setup more complex.
Maybe the Launch-way of doing things is the answer: create dedicated environments, and use them appropriately.
Food for thought.
LikeLike