Cannot use multiple Segment integrations on the same website

[Vadorequest]

We use no-code tools, which already use Segment for their own purposes.

Because of that, we are stuck and can't use Segment for our own purposes, because the script attaches things to window.analytics and it is not possible to have multiple Segment integrations within the same page.

We really need a way to work around this.

Also, other libraries use window.analytics and they're therefore completely incompatible with Segment.
I believe it is possible to kill two birds with one rock here, and solve both issues at once.

It seems Segment had a "no conflict" option in v1, but it has been deprecated in v2, and it's only usable when self-hosting. (which is not possible in our case, and the no-code service we use don't self-host either)

[ohemi-newrelic]

+1
Is this being handled?
There should be an option to not attach the analytics instance to the window

[NicoleG25]

+2
This is really affecting us. Could you provide a solution/a workaround?

@nettofarah @silesky (sorry for the random tag but we're in a tough spot)
please let me know if there is anyone else I should talk to, to get this moving along :)

[silesky]

For reference, here's another similar open issue: #367

@NicoleG25
Sorry, this isn't on the roadmap for this quarter and I can't give any timeline -- we have a full plate right now. If enough people "thumbs up", we definitely take notice when it comes to our roadmap. Unfortunately, the original architecture for this library made some difficult-to-change assumptions.

For context: there are some significant potential conflicts around globals and in particular, around localStorage.

My advice is that for now, If you just want to make requests to analytics and can manage the userId / anonymousID generating or persisting an anonymousId on your own and don't need device mode plugins, you can use @segment/analytics-node with maxEventsInBatch: 1 which should work in any runtime where fetch is available. https://github.com/segmentio/analytics-next/tree/master/packages/node.

[Eunanibus]

Uncertain if this is relevant but I'm running into this issue using a Micro-frontend architecture.

The problem-space is that these are distinctly two different applications with separated sources and write keys, but incidentally due to an extremely common arhictecture pattern, we have events being written to the child node write-key from the parent application, seemingly because the window.analytics source is atomic.

Is there a workaround for micro-frontend architectures, two distinct applications that share the same browser window?

[silesky]

Also, other libraries use window.analytics and they're therefore completely incompatible with Segment.
I believe it is possible to kill two birds with one rock here, and solve both issues at once.

@Eunanibus We actually do support renaming the global analytics instances now, so you can have analytics1 and analytics2. Should work if you are careful to not use device mode destinations that conflict with one another between instances, as those load vendor scripts that might not play nice with multiple instances of themselves https://segment.com/docs/connections/sources/catalog/libraries/website/javascript/#installing-the-library-under-a-custom-global-namespace

[Eunanibus]

Thanks @silesky

To elaborate, the container application is legacy and uses a snippet.

The child container uses the direct npm dependency and AnalyticsBrowser class to instantiate analytics.

If I migrated both to use AnalyticsBrowser, is there a way to specify the namespace? Conversely, perhaps the easiest solution here is to configure the child container to use this different namespace.

Interested in your thoughts on the best approach here.

[silesky]

@Eunanibus
Using both to AnalyticsBrowser should work fine -- you shouldn't have any issues with events being sent to the wrong writeKey if you're just using vanilla Segment without device mode destinations.

Hey, there is a way to namespace, but I just realized that we didn't actually document it yet because it's a bit edge casey.
If you want to use a mixture of both the snippet (parent) and the npm version, you can use this globalAnalyticsKey option.

AnalyticsBrowser.load({ writeKey: .... }, { globalAnalyticsKey: 'SEG_DISABLE' }) 
// this is basically just a hacky way of saying 'do not flush' from the window["analytics"] keyed buffer 
// so there is no conflict between the npm version and the snippet version. 
// We have a betterment around this so the npm-installed library doesn't read from window event buffer at all, like the snippet library does

[Eunanibus]

Yep, I found this too, it was very buried but it is documented in the code.

This appeared to work fine, and instead of altering the parent container for a different namespace, I found that I could just adjust the child container namespace instead.

This (appears?) to have completely eliminated the conflict. So for anyone who maybe finds this in the future and is struggling with multiple Segment instances in a Micrfrontend (or Parent Child) architecture, make use of the globalAnalyticsKey option field to isolate them.