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!
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.
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?
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.
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.
And that’s it, likely.
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:
This screenshot shows the correct state of that box: ticked.
(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.