A while ago I asked if you could add user emails and usernames as dataLayer variables in issue #9 , You did so very quickly and I am very grateful. We use to define that manually and build our remarketing tag by referencing each datalayer variable we needed. It recently came to my attention that I can just call the google_tag_params hierarchy and receive all the values. Unforchantly in doing so, I noticed a small issue. The email and username are included within the google_tag_params: { }. It should be defined outside of that to avoid being invoked by the adwords remarketing script while allowing me to manually define it as a data layer variable for a range of other tags.
Emails should only be used for services offering customer matching, like Active Campaign JS User Cookies setting, Facebook Custom Match Pixel, Adroll Customer Match Pixel but not for Google services. Currently, the visitorType and visitorEmail are within the google_tag_params hierarchy, which means when you define the dataLayer v2 variable "google_tag_params" in Tag Manager and link it to the built in Adwords Remarketing Tag w/ datalayer matching, it will pull everything within thegoogle_tag_param.
This creates a breach of the Google Adwords remarketing terms and conditions as you mentioned. Since using the google_tag_params is the proper method for remarketing, this is not ok.
The solution is to keep the personal tags, visitorType and visitorEmail, outside of the google_tag_param. The current setup would allow me to remarketing to people directly using their emails, which is a No no. If you just moved these two dataLayer variables into independent hierarchies, this would be solved easily.
I have attached some screenshots to better explain what I did and why it can be a problem for some users. Short term solution is going back and manually defining all these attributes as variables then calling them in the remarketing tag, but when working on a lot of new clients that can be very time-consuming. For the average user following a tutorial, this would be overlooked and quickly cause then issues.
I just wanna note again, this feature is critical to many newer attribution solutions and web tracking automational software. It should not be removed, just relocated.
Image of problem below
Image of tag setup that causes this issue
Example of Proper Use case outside of the google_tag_params and defined as a seperate dataLayer variable
Example of Proper Use case outside of the google_tag_params and defined as a seperate dataLayer variable