Dynamic Tag Manager (DTM) - Appmesaurment custom code section (No Customize page Code) + Module codes on UI

[#1]

Hi colleagues,

Since DTM's Team added the possibility that deployed Adobe codes, like Appmesaurment and Visitor API natively through DTM UI, I was thinking that would be well if all code (Heartbeat, Module integrate,...) may be deployed natively as well. That arises because I would want that new Appmesuement versions or whatever code are installing by default, and on the other hand, to have a section for customize my Appmesaument code.

I try do it through Customize page Code, but unfortunately seems that this section was not thought for do it, and we cannot executed this section before Appmesaurment code (for then can add into it custom code and then activate Code Managed by Adobe). Some idea for do it?

Finally, as I cannot do that, I suggest in Idea Exchange a method for:

    1. Possibility to add other code modules, like right now Appmesurment, be managed automatically by Adobe updates.

    2. Section (Or Customize page Code checkbox) through it to can add custom Appmesaurment Code.

Please, if actually somebody have any idea to do it, I really will appreciate if shared it, if not please vote my suggested idea:

                                http://adobe.ly/1m8a03b

[#2]

Hi Anna,

Before all thank you for your attention, and allow me to say that I'm excited that adobe provide us this tool,

So, I'll try to explain my idea, and the problems which I was encountering when I wanted do that. Also I would like to left clear that with "Custom" option I'm able to do that, but the idea is improving my process, and maybe all other users's process as well.

So, first doing some test I saw that the execution's order of AA deployment section (leaving part Data Elements and Rules) is like this:

[img]Screen Shot 2014-08-21 at 14.50.55.png[/img]

When I realised that the order is these, I thought that customize page is this part of code that we only want to be triggered once page is charged, and only once. Legacy implementations without DTM, used a little trick with true/false variable into do_plugins section:

[img]Screen Shot 2014-08-21 at 15.06.10.png[/img]

With this we get split a s.tl() (interactions) code with the s.t() (page loading) as do_plugins is called each time that those functions are called. So is exactly this that I miss in deployment UI AA, one part where we can do that.

Certainly, you can say me, welcome the event rules Julià! True, but unfortunately some plugins are created for to be fired into it, and also implementers can take advantage that do_plugins to be called each time that user's interactions take place, and use it as a "generall event rule".

So for solve that, I'm thinking that the best would be that "Managed by Adobe Section", should allow customize some code before that Appmeasurement has been executed. With this we got:

• Free us to make updates when Adobe update your core codes, Appmesaurement and modules (for this I published it on Idea Exchange that modules should have an option for be managed by Adobe as well), because them will be updates automatically.
• Have a section where we can costumize our do_plugins section, as a legacy implementations, and to can use as a general s.tl(); rule
• Use Costumize page code for make custom code once page is loaded, and only once (as works right now).

With this DTM executing as well as do a customized implementations:

1. Marketing Cloud Service ID (as a tool)
2. Customized code when Appmesaument and modules hasn't been executed (with suposed new feature)
3. Execution of Appmesurment and Modules (like Heartbeat)
4. Costumized code when Appmesaurment has been executed (with Costumize page code).

Under my point of vision, with this we respect legacy implementations and allow us more advantages in terms of implementation, and especially liberate us to actualize core codes if want costumize our Appmesaument code before it has been executed. Finally, and it is a personal opinion, "Managed by Adobe" should allow change the "s" object name, can trust me that many tools use the same object, like for example Sophus, and when we work with a big companies whose using a lot of third party tools, that's a problem.

PS: If you try to Execute Costumize page Code before UI, you'll realized that always Appmesaurement is executed before 😞

Hope this make sense for you. If really exists on option for solve the gap which I commented, please let me know,

Julià.