Here is a great video describing an issue this new feature could help
fix. In this case the vendor TrustArc opts users out of Target Internet
wide. A feature like the one I describe able would help to undo a global
optout like this. GDPR bad practice from Weather Underground & TrustArc
- YouTube
Analytics has an option to add opt-in links as part of its opt-out
functionality. (using query parameters with the opt-out service)Add an
Opt-Out Link Please add this feature to the Target opt-out link service.
Adding an Opt-Out Link There are many use cases for this and even more
now that we are post GDPR. Also in this post GDPR world some vendors
like TrustArc are incorrectly configured to disable ALL Target testing
internet wide across all target users.
You can turn this feature "off" using comments around your custom code.
/* jshint ignore:start *///Code which causes warnings you don't care
about here/* jshint ignore:end */
I can't tell you how many times I've been asked to debug a "revenue not
capturing issue" just to find that an implementor on the client side
used the transaction ID field thinking it was setting s.purchaseID.
I know there is a staging environment for a very good reason but there
are cases where the staging library just isn't needed and approving then
building for staging is nothing more than additional clicks for the
launch user. For instance in the initial development stages when the
production embed code hasn't even been published yet. The idea here
would be add an option for users with sufficient access to build to
production from the development library menu.
It was said on a call that Launch will have great migration features
from DTM. One of these features would be the ability to have launch use
the embed code of an existing DTM property. So can Launch and DMT share
a staging library? My thinking is this. Since we can tightly control
when builds occur in Launch we could test a build and then quickly tear
down that build by making an update in DTM. This will give us the
ability to test launch in development environments and give us the
ability rever...
Today in DTM tag versions are "Pending Approval" and "Revision X" ,Y or
Z which is great. However some rules go though MANY saves before getting
approved and it would be very handy to save those revisions as well. My
Ideal is that all rule saves be given an incremental revision point
release. eg. "Revision 3.1" and Approvals given a new revision number
eg. "Revision 4"(Actually my IDEAL would be to save the incremental
revision before session timouts and give the user the option to restore
lost ...
I have multiple clients asked for the ability to generate a DTM JS
library for only the approved changes.This would allow them to test the
code about to be released to production without any changes currently in
development getting in the way. It would also alow for a more stable
version of the code to be deployed into staging environments. Currently
there are only 2 code versions:Staging which is actually all changes in
developmentProduction, all published changes. I would suggest the
current "...
