There is a caveat at the bottom of this answer for AudienceStream that I'd like you to read if you are presently, or may be in the future, using AudienceStream from these collect tags.
Presently, mappings for the collect tag are not supported
In addition, although you can alter the data that is sent via the collect tag by using JS extensions scoped to it and manipulating the 'b' object, the configuration for the collect tag does not look at the 'b' object to determine the server to send to.
There are ways to do this via JS extensions scoped to the collect tag, but it depends on which version of the collect tag you are using. So I would reach out to email@example.com if you must use this approach.
There is another approach, which is to use more than one copy of the collect tag, and use a load rule to determine which one should fire.
If you are planning to send these collect tags to AudienceStream, then you will run into an issue. The issue is that AudienceStream is designed around the assumption that an anonymous visitor identfier is not shared across more than one AudienceStream profile. That would not be the case here. The same anonymous visitor identifier might be sent to a different AudienceStream endpoint depending on your conditions.
You can put in place an extension scoped to all collect tags in the iQ profile to avoid this issue, but be sure to put this extension in place before you put these collect tags live. This is true no matter which approach (load rules or another method above) you use.
The extension works by altering the outgoing value of the anonymous identifer to make it different for each endpoint.
Again, the specifics of the extension depend on your specific setup, so reach out to firstname.lastname@example.org for help with it.