Multiple Launch Properties on the Same Web Page

[#1]

I know that this was basically impossible to do in DTM, but I'm wondering how feasible it would be to allow the property administrator to configure Launch's primary object from _satellite to another string so that multiple properties could coexist on the same page.

My reason for wanting this is to allow a configuration where two or more Launch instances are deployed on the same page.

I have come across scenarios in the past when this would be absolutely ideal (especially if both were driven from the same event-centric data layer).

Example 1: A holding company wishes to collect analytics data globally on all of its brand websites.  The individual brands also wish to collect analytics data but don't want to be bound by the SDR of the holding company.   Having multiple Launch properties on the page would allow this.

Example 2: A solution is designed for a website that is fully driven from data layer events but the organization's IT staff will not be able to deliver the application modifications to implement the data layer events for 6 to 9 months due to a backlog of higher priority projects. A second Launch property could be deployed to implement the data layer events via (less robust) DOM scraping rules.  These temporary shimming rules could be removed one by one as the events are provided formally in subsequent sprints.  By having the shims in a second Launch property, the maintainers of the first will not be confused by the shims and will be less likely to repeat the pattern.

[#2]

This is not supported in any fashion at this time.  Please do not do this.

[#3]

Fully understood.  This is why I'm asking for an official and supported way to accomplish the same end.

[#4]

I would suggest posting an idea to cover this line from your first post, instead of renaming the _satellite object.

"My reason for wanting this is to allow a configuration where two or more Launch instances are deployed on the same page." 

[#5]

Rudi, Please see my edits on the original idea. 

[#6]

i wish you would have not edited this idea.  That way the history if renaming the satellite object and that being something that is not supported would still be here.   Im not a fan of revising comments and such.  

[#7]

Supporting the renaming of _satellite would be the easier part. The more difficult part would be avoiding conflicts in persistence layers (e.g., localStorage, sessionStorage, cookies) and conflicts in in-memory objects (e.g., the same extension in two properties loading the same library twice).

I believe our direct team could prevent conflicts in our code accordingly, but placing a burden on extension developers to ensure no conflicts if their extension is used twice on the same page would be the rub for me.