Adobe Experience Platform

DTM has support for eCommerce events such as prodView, but it has no native UI for setting the products variable! Right now, the official documentation suggests using custom code to set it.  This is the worst variable in all of the collector code to work with. The syntax makes our engineers downright angry. On top of that, the recommended way of piping Satellite variables in means that you may need to make 6+ calls to _satellite.getVar() to construct it. Having a sensible UI to set the specific parts of the product variable would be a very obvious use of DTM to set Adobe variables on demand. Please consider adding it!

While cleaning up the DTM, I always face the problem which rule to keep which to rule remove and this problem intensifies in case of Direct call rule. There should be a mechanism by which we can track the usage of the rule. Usage could be in format like number of times the rule is used and page wise usage.

The code for tools will be part of dtm-library (satellitelib*) anyway: whether you use the tool or not. This is a potential security risc.Example: Reference to "google-analytics.com/ga.js" is included although the tool is not integrated for the specific property.Improvement: Only incorporate code that needs to be included otherwise leave it out. It makes the code smaller and more secure.

Hello, It make sense to have two properties share the same embed code. This can be useful in the environment where two teams (analytics and marketing) have different responsibilities.First property can only have Rules for analytics tags and Second property will only have Rules for Third Party Marketing Tags, This enhances the roles-oriented capability of Dynamic tag management and let's you control your asset in better way during release and deployment. Regards

Not sure if anyone else is seeing this when using Chrome... But the revision list does not allow you to see the beginning of it, IF you have a ton of revisions. Please see attached. Can something be done here Adobe?

It should be possible to copy/clone an existing web property with all rules, setting for tools and data elements.Usecase: dozens of microsites, landing pages, externally hosted and maintained, should be tracked with one and the same tracking framework, but should still allow some individual requirements, plus have to be administered seperately.

I would love to see more robust error handling for data elements within DTM. Currently, if you have a DTM rule that calls a data element, and that data element causes a javascript error, you lose tracking for that entire call, instead of just the data element. Ideally, I would want to see DTM place the call to the data element into a try() block and output the specific error if it fails via the DTM debug mode.

would be nice to have the option to purge tool publish history, inclduing at the rule level. We have an old setup with 100 revisions, but no good way to navigate through them. For folks who want to start a clean slate, they are forced to a new property. Naming could help with this information overload issue.

would be nice to name a release with a friendly name instead of a generic number that gets auto created.

Right now, the session length for http://dtm.adobe.com is only 30 minutes.  Imagine this scenario: 1. Log into Tag Manager2. Set up a rule3. Go to paste a tag in, realize that you don't have it in proper form. Shoot an email off to a dev ORDig through your inbox, get a little distracted by another thread ORGo to the third party tool, log in, set up tool, copy tag4. Paste tag, hit submit.5. Get sent to the DTM login page. 6.Swear, log in again, repeat steps. As you can imagine, 30 minutes isn't really long enough to properly fit into a typical workflow, and I find that after submitting a change, I'm logged out more than I'm logged in. Any change we can bump it up?

Hi, 1.I would like to suggest an ability to copy the Data Elements, which was already mentioned in:http://ideas.omniture.com/t5/Idea-Exchange-for-Adobe/DTM-Data-Element-Exporting/idi-p/1168 3 If we are able to copy entire rules, why not copy data elements as well? This would make migrating between properties a lot easier. 2. I'd also like to have the ability to copy the entire properties. Here'a a scenario:When we deliver analytics for our clients we internally work on 2 or more environments, and then clients have their own internal environments as well (usually UAT, Staging and Prod). DTM by default supports staging and prod for one web property. Now if we could copy the entire properties we would probably have one property for our development needs (inside which we would have staging for development and "production" for testing) and we would simply create a copy of that property to support client systems (and then staging in that property would be used for clients for testing and pro

Currently, all conditions specified on a DTM rule must be met in order for the rule to fire.  So, if I want to fire a metric or a rule on a certain set of pages within DTM, and they don't have one single common value, I either need to use regex matching on the same exact data element, utilizing the "OR" operator to match multiple values, or I need to set up multiple rules. This becomes very painful when I also then need to ensure that the rule doesn't fire twice, by also adding regex to the second rule to make sure it wasn't already matched, and ti also means that I need to remember to update all of my rules by hand whenever I want to add a new analytics value or trigger a new script on those pages.   For a concrete example, let's say I want to set the "Channel" value based on either URL matching or a data element (defined by, say, a JS value.) Right now, I need to match based on the URL bit, then copy my rule and change the condition to match on the data element. And now that it is a

The ability to create an event-based rule based on clicks to certain elements in DTM is a huge leap for us. However, we're really limited by what is available right now, since not every scenario is listed in the "Event Type" dropdown, and we have to keep up with arbitrary changes to the front-end code to ensure that what we have set up doesn't break. This idea is the proposal that, in addition to all of the current capabilities, Adobe adds the ability to create an event listener for any JavaScript event (or at least, in the same spirt of a "Data layer," an "event layer"), so that we can truly separate the concerns of firing a meaningful event and tracking that event, from our other UI code. I would imagine that either we could specify the target, or Adobe could use a specific target. Use cases:Where the event is triggered by an AJAX response and not a direct user interaction (for instance, a successful login in an overlay, or a share to another service), we have a way to track itWhere

hi having the ability to specify precedence or order override when mutiple rules match would be very helpful. 

Today, DTM deploys mboxes around elements on the page using the mboxUpdate function. This works very well - it erases the opportunity for content flicker:- DTM hides the element with code in the - DTM calls mboxUpdate- mboxUpdate waits until window.onload to update the content  Unfortunately, some clients have very large windows of time between DOM Ready and window.onload It'd be interesting to add to DTM's interface to have the choice to deploy mboxes using either mboxCreate or mboxUpdate. Using mboxCreate, the content would no longer wait until window.onload. According to the documentation in T&T here: https://marketing.adobe.com/resources/help/en_US/tnt/pdf/testandtarget_integration.pdf - Page 13 The main difference between mboxCreate and mboxUpdate:- mboxUpdate can be used for elements loaded on the page dynamically- mboxCreate can only be used on HTML elements that exist on the page at initial load

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 "Staging Embed Code" be relabeled to "Development Embed Code" and the new option for approved changes be added with the "Staging Embed Code" label. 

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 changes on login... )If the data storage requirements for this are too large (which would shock me this is Adobe after all) then clearing the point releases after publishing would be an ok alternative. 

It usually takes quite some clicks to get to the features I need in the DTM. I suggest:- extended menus (e.g. Rules on hover would extend to Data Elements/Event based rules/Page load rules/Direct call rules.

This is just a simple aesthetics request. I think the Pagination controls should be at the top and bottom of each rules sections. IMG-section-1 shows my event based rules page, IMG-section-2 shows the bottom of that page with the Pagination controls, IMG-section-3 is showing where it would be nice to have Pagination controls in the top of the page.

It would be great to have an option, when creating a data element, to target your dataLayer object.It will allow users to make less errors as you constantly need to give the full path when using 'JS Object' type. So i will avoid to constantly write "dataLayer.".This could potentially be set within the application.

(Relatively) recently, Adobe allowed for rules and data elements to be copied over to another property.  However, only admin users have access to this feature!  Since all levels of users (User, Approver, Publisher, Approver+Publisher) can create/save rules, and can also have access to multiple properties, from a permissions PoV, there's no reason why they shouldn't be able to copy rules across properties they have access to.  I kinda feel like this is a bug more than a feature request... 

When editing the name of a Data Element it would be great for the system to automatically update all references to that particular Data Element item (i.e. %data element% or _satellite.getVar('data element')). For example if i correct my data element called "Page Name" to "pageName", updating all references of that Data Element will help a lot and ensure consistency and integrity.

When the iOS SDK was 4.x was released the lifecycle events were enabled automatically but unlike 3.x they cannot be disabled. We aren't using them very much if at all right now and it's a bit unfair that they are there driving up our server calls when we didn't consciously implement them. We should be able to have a way to disable the calls if we wanted to.

An intuitive Omniture JavaScript editor to customize the s_code file according to the variables / events / properties in place would bring a huge value to marketing people willing to quickly translate their business requirements into a concrete change to the tracking structure without having to get technical. Making the technology more transparent is a common trend these days and "Marketing Channels" feature clearly is a good example showing Adobe's wish to make their clients' day-to-day activities easier. . A further step would definitely be appreciated.Antoine.

In DTM, page load rules can be set to trigger/eval at Top of Page, Bottom of Page, DOM Ready, and Onload.  However, the only way to see this information is by going into the rule.  This is not very convenient when there are a lot of rules.  It would be nice to have a column added to the "Page Load Rules" overview page that shows when/where the rule is triggered at.