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.
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.
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. 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.