Expand my Community achievements bar.

SOLVED

What are the risks of running Adobe Target and WebSDK from a Tags/Launch container that runs from GTM?

Avatar

Level 1

Hi everyone,
I just ran into an implementation of Target and Adobe Tags/Launch where the actual Tags script is being invoked from GTM (yes, from Google Tag Manager). So basically a tag in GTM is injecting the Tags script into the page.

What I am wondering is:
1) How much of an impact or what unintended consequences can I expect from such an implementation?

2) If I happen to have rules in Tags configured run WebSDK calls to send data to the Edge Network and then to AEP, should I expect a significant delay in those calls?

3) How would this type of implementation affect other Adobe products running from Tags, such as Target?

4) Are there any official Adobe document that recommends staying away of this configuration where one tag manager is calling another tag manager, not as a temporary solution, but for a long term production environment?

Any guidance would be really appreciated!

1 Accepted Solution

Avatar

Correct answer by
Employee Advisor

I'd expect that everything will work from a technical point of view but the big problem, as you alluded to, is the delay that this will introduce and the impact of that against personalisation activities that change page content. GTM can only be loaded asynchronously, so even loading Target directly via GTM ends up with flicker between default & variant content; so if GTM loads Tags which loads Target that flicker is going to be even worse. 

I don't think Adobe have any documentation on the topic but it's well established as bad practice to even be running more than 1 tag manager, let alone having 1 tag manager load another. There should be no good reason to run two tag managers - if Target should be loaded via the tag manager then you can't use GTM due to lack of sync loading functionality, and therefore Tags would be a better option; however, if GTM is the preferred tag manager then the best option would be to load the Target/Web SDK script in the <head> of the page so that personalisation use cases can be delivered without flicker   

View solution in original post

2 Replies

Avatar

Correct answer by
Employee Advisor

I'd expect that everything will work from a technical point of view but the big problem, as you alluded to, is the delay that this will introduce and the impact of that against personalisation activities that change page content. GTM can only be loaded asynchronously, so even loading Target directly via GTM ends up with flicker between default & variant content; so if GTM loads Tags which loads Target that flicker is going to be even worse. 

I don't think Adobe have any documentation on the topic but it's well established as bad practice to even be running more than 1 tag manager, let alone having 1 tag manager load another. There should be no good reason to run two tag managers - if Target should be loaded via the tag manager then you can't use GTM due to lack of sync loading functionality, and therefore Tags would be a better option; however, if GTM is the preferred tag manager then the best option would be to load the Target/Web SDK script in the <head> of the page so that personalisation use cases can be delivered without flicker   

Avatar

Level 1

Thank you @alexbishop, I really appreciate your input! This certainly confirm some of my concerns.