Alice manufactures a product

She displays the product info here: alice.com/product-001
She has set a button [Purchase now] pointing to the checkout page.

Bob runs a checkout service

Alice has contracted his services.
Alice has configured product 001 in Bob's service
Bob's system creates 2 relevant URLs:
- To initiate checkout: bob.com/pay/product-001
- The thank-you page: bob.com/thank-you/product-001

Charlie is an affiliate for this product

Charlie has a Google Tag Manager with ID GTM-999999
Charlie agrees with Alice and Bob that his affiliateId will be 777.
Charlie wants to track the sales funnel at the 3 pages (product checkout-init checkout-complete) to optimize his budget.
Both Alice and Bob agree to receive the affiliate ID in the URL.
If ?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.

Question

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?

CodePudding user response：

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

CodePudding user response：

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.

Finally, arguably the best way, would be having Bill and Alice connect their implementators with Charlie's analysts and have them implementing whatever tracking the analysts require. It is usually not much for affiliates and that's exactly how enterprise analytics works in the world of big corp. Since Charlie is an affiliate, there's a reasonable expectation that there will be more affiliates. Which now allows Bill's and Alice's implementators to build some rules and semi-automated solutions for a complete affiliate onboarding analytics-wise. They will end up having a few look-up tables (or just a neat JS var) and a few pixel/GA tags using the LUT for account ids.

Done! Pretty solid ground to support virtually unlimited number of affiliates with no significant strain on the implementation side.

Letting Charlie and the others having their containers on pages is a sure way to chaos. It will likely end up taking more time and effort than any other option.