Change name of tracker variable in DTM with code configuration set to 'Managed by DTM'

[#1]

I need to change the name of tracker variable to from 's' to 's_xyz' while having the code configuration set to 'Managed by DTM' option. Is there anyway I could do it.?

[#2 · Accepted solution]

Thanks.  DTM holds the AA tracker object in an enclosure which prevents it from conflicting with other code at window scope. 

When you use the setting, "Managed by DTM", by default, you cannot reference the 's' object at window scope.  Typing window.s in the console WOULD NOT return the AA tracker object.  Typing window.s.t() would not cause a beacon to be sent.

Within DTM, in the context of the AA Tool (like in Custom Page Code of the Tool Settings, or in the AA custom code section of a DTM rule) you will reference the tracker as 's', but this will map to the local scope and will not map to the window scoped 's'.

In short, you SHOULD not have any conflicts to worry about.

If the other code on the page that uses 's'  is another Adobe Analytics implementation, then there are a few gotchas because there are some functions (even in the 'Managed by DTM' scenario) that can cause some issues.  I'm thinking specifically about the function, s_gi which returns an instance of the tracker.  If your other code using 's' is not Adobe Analytics, you should be just fine.

If you need to reference the AA tracker from outside of DTM and you need a name for it other than 's', you can add a line of code to your AA Tool settings in "custom page code" like so:  window.s_xyz = s

I think that covers it.  Please let me know if this answers your question.

-Stew

[#3]

I would recommend you just send data to multiple report suites in one beacon fire.

Multi-Suite Tagging

The main challenge here though is the variable and event sets in each may differ so one report suite will maybe miss custom events and props that the other has. I would recommend use yours as master then ask 2nd party if the variable provided are sufficient. Also bear in mind this method will increase your secondary server calls and potential monthly cost.

Applying 2 different adobe code types on the exact same page is very difficult as you are finding and I think not officially supported. Adobe reps can verify this statement.

Good luck

[#4]

I was afraid of that. I've handled this scenario, quite a few times in the past but it gets more complicated than what I could coach you through here.

This is the point where I'd suggest a short engagement with my company to find a custom solution that works in this outside-the-box scenario. Send me a direct message if you'd like to explore this option.

-Stew

[#5]

Thanks Stew for such a detailed explanation. But our problem is that the other code (implemented by a third party client) uses 's' and is also adobe analytics implementation. This is why we wanted to use 's_xyz'  instead. I'm seeing a lot of conflicts like data being sent to the wrong report suite.

Can you suggest the best solution for this scenario (assuming we cannot ask the other implementer to change the name of their tracker variable)

Edit: the other implementor is using SiteCatalyst code version H.27.5.

What should be the best implementation on our side to avoid conflict with their code.

Thanks in advance!

Yatin

[#6]

Thanks for replying. My need is that I'm trying to avoid conflict with other code on the page that uses 's'.

But it will be helpful if you can lay some light on other scenarios you've mentioned too.

[#7]

Perhaps... What is driving this need?

Are you trying to avoid conflict with other code on the page that uses 's'?

Is there existing code on the page that references the tracker object as 's_xyz'?

Are you just trying to avoid using 's' at window scope?

The answer to your question will depend on your answers to the above.