Adobe Experience Platform

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.

If we call a Direct Call Rule and set "s.abort = true" on the custom code, the tag won't abort. Just if we change the type of the direct call to s.tl. Please fix.

Since versioning in DTM is pretty lacluster at the moment, I try to liberally add notes whenever I make a change to things.  And they just keep piling up. I have rules 50+,100+ notes and there is no pagination for them so I have to scroll down forever before I get to the save/cancel buttons.   At a minimum, move the save/cancel buttons to ABOVE the notes so that their position is not affected by notes.  But ideally, there should be pagination for notes so that page load times do not become longer and longer as notes are added. 

One of the (few) great things about the old Adobe Tag Manager (pre-Satellite) was that s_code was integrated right into the product. You could easily click a checkbox to upgrade to the latest and greatest. Would love to see this implemented into DTM!

Hi,  Is it possible to name space s into analytics.s in DTM ? thanks,Devisree.

I think there's must be a way to lock a Page Rule while a user is making changes to it. Currently if more than one user access the same Page Rule and make changes on it, there will a versioning error. A "lock" mechanism would avoid that.

We wish to use notes to document our page rules, etc. but there is no way to edit or delete them.

Importing / exporting a container will be beneficial expecially to enable users to replicate an account's container and avoid starting from scratch again.