alice.com/product-001[Purchase now] pointing to the checkout page.bob.com/pay/product-001bob.com/thank-you/product-001GTM-999999affiliateId will be 777.?affiliateId=777 is added to any of the 3 pages, then Alice and Bob will display the tag GTM-999999 along with their own GTMs if already in place.This enables Charlie to send "pixel trackers" (*) to the pages. He can send the trackers of Facebook, Twitter, Google Analyics, etc. at his own will; as well as any other "pixel" he creates himself.
(*) We all know that the "pixel" name comes from the ancient times when we set a 1x1 transparent image. But now it's not an image. It's a javascript and therefore much more powerful. But also dangerous.
If Alice and Bob render Charlie's GTM... will Charlie be able to inject ANY javascript at will (for example one for spying third-party cookies or re-rendering visible blocks of the page, or crawling the DOM to discover emails rendered there)? Or GTM "filters out" what can be sent or not to the browser?
That's a very valid concern. And yes, Charlie will be able to execute arbitrary JS on those pages. Reading/rewriting cookies, changing the whole DOM, forcefully redirecting people to other sites. Basically, a lot of things.
Therefore, Alice and Bob should be extremely careful when allowing third-party tag management systems. Well, no, they should not allow them at all.
This is done differently. Other ways to consider:
Give Charlie's devs access to Bob's and Alice's GTMs and give them write permissions. Here is info on how to do that: https://support.google.com/tagmanager/answer/6107011?hl=en and some info on permissions: https://support.google.com/tagmanager/answer/6107011?hl=en#container_permissions
Make a few new GTM containers for Charlie. Bill will make one and share the write access, Alice will make one and share the write access. It's similar to the previous but now all Charlie's logic is in a separate container.
In both cases, write access for Charlie's devs implies requirement for Bob's and Alice's devs to validate the changes by Charlie's devs. The second case, however, will require syncing two containers on a page. It may require advanced GTM knowledge. In particular, defining tracker names for all containers to avoid data intermingling. But there's a good reason GTM does not recommend defining trackers. When you define trackers, GTM starts behaving differently. If before you could expect from each tag to execute in its own context, now you won't be able to do that, so a lot of fields that were not explicitly set for this tag, but was set to the previous, will be inherited by this tag, so the context will start being persistent. That requires a bit different approach to tracking. A bit unusual. GTM allows all the tools necessary to accommodate it properly, but even senior GTM devs are often oblivious to those tools. And it leads to bugs that are rather harder to tackle.
Done! Pretty solid ground to support virtually unlimited number of affiliates with no significant strain on the implementation side.
GTM by itself does not filter, you have to create the setup accordingly.
Allowing to load a complete GTM container sounds like overkill and is rather dangerous no matter what. But you can create allow-lists or deny-lists to restrict tag deployment, and allow only certain categories of tags.
A deny list needs to exclude custom HTML (javascript), else it is pointless (since Charlie could just implement prohibited pixels via Javascript). It might be difficult to set this up so that the allow/deny lists only affect Charlies container and not your own.
The better way is to have Charlie supply a custom template for his tracking tag. Custom templates in GTM use "sandboxed javascript", a subset of JS with access to some Google APIs that prevents dangerous operations (e.g. DOM access). You can set additional permissions of what Charlies tag is allowed to do or not (setting Cookies, sending pixels to certain urls, loading scripts etc).
To make this more explicitly, if you allow a third party to render a GTM container under their control into your site, you surrender control of your site to them and they can steal data, read cookies, deface your site and do anything else that is possible with Javascript.
You can mitigate this via deny-lists and template policies, but the much better idea is not to allow this in the first place and look for a less obtrusive solution.
Also if you are in the jurisdiction of the GDPR and the ePrivacy direction, you need to make sure that Charlie implements his tracking in a compliant fashion and there is no way you can do this.