Tracking Script Implementation Forces Exposure of PII

We are trying to integrate some custom events from our non-hubspot-hosted website, but are having issues understanding how this is supposed to work without leaking personal information to the page.

Background:

  • We have a lot of existing users with email addresses (1M+)
  • We are in the progress of migrating to hubspot
  • We have a unique id associated with our users/contacts that is available to our client-side javascript
  • We don’t persist the email address of the user on the client, since that is pretty widely considered bad practice (correct me if I’m wrong here)
  • We thought that we’d just need to import our contacts into Hubspot with our custom user id, then we’d be able to associate that custom user id to a visitor so activity was associated back to the contact (appears to be incorrect)

Steps we have taken:

  • Added tracking script to all pages via Google Tag Manager
  • Added a small snippet of js that to identify the user to hubspot (we were hoping we’d only need to associate with the email address one time)
  • Added our custom user id to the contact (user_id)
  • I manually created my contact and set the user_id property to my personal user_id within our custom CMS
  • Created a custom event with custom properties associated with it
  • Added a GTM tag that sends the custom event on specific user actions on the page

Problem:

  • When setting just the custom id (user_id), no events are associated
  • When I manually set my email address and user_id at the same time for my client, events are correctly associated with my contact record
  • When I go back to setting only the user_id in the identify function, events are no longer associated with my contact record

Questions:

  1. Does the documentation here not suggest that the id can be used when the email and id were used together at least once? (“the visitor was previously identified by both ID and email”)
  2. At first, reading the same documentation link seemed to imply id was a special parameter. However, this post seemed to suggest the user to create the custom id associated with the contact. Should I be using id, or can i use any custom field (user_id)?
  3. The same documentation also seems to suggest to favor using email to associate events to the contact. Is this not bad practice, risking the exposure of PII to 3rd party scripts? How does hubspot justify making their customers do this?
  4. Is email always required to associate events to the contact?

Hi @rothnic

Thank you for reaching out.

I want to tag some of our experts on this @coldrickjack @LMeert @Anton @Mike_Eastwood do you have any thought for @rothnic on this?

Thank you!

Best

Tiphaine

I am new in this forum. I have some questions about this forum. These questions are shown below:

https://community.hubspot.com/t5/lotto4dReporting-Analytics/Tracking-Script-Implementation-Forces-Exposure-of-PII/td-p/685327

My question is about this thread. If you have any information about this thread. Please quote me and solve my problem.

Hi @rothnic,

I’ve spent about an hour trying to make it work testing various combination and this is my conclusion :

  1. The documentation does suggest the id can be used on its own and it is true, however you can only do that after the identify method has been used to tie both id and email together.
  2. The id is indeed special and is only to be used with the _hsq method.
    I thought I could use any external id in a custom property to make the identify work but none of my attemps were successful, except this scenario :
    - open a page in a browser with the hs tracker on it
    - use the identify method to pass an email and an id : _hsq.push([‘identify’, {email: ‘test@test.com’, id:‘123456’ }]);
    - open a page in another browser, and identify the user using : _hsq.push([‘identify’, {id: '123456’}]);
    I tried setting up a user_id property and load it with ‘123456’ and going through the aforementionned process but with ‘user_id’ instead of ‘id’ and that yielded no result.
    So I guess if you want to use an external id, it won’t be visible in HS (unless you have a property for it and you pass it along the identify method on top of the id, but both will be two completely separate properties with no link between them whatsoever), which is not as useful as I thought this would be.
  3. I can’t really comment on that one but usually trackers which work using PII ask that you use any encryption method (I’ve come across SHA 256 more often than not) → if you use a clear email, maybe the hsq function does the encryption, although it would be best security-wise in the case of GTM if you could already receive the encrypted email and simply pass it along.
  4. If you have to use the email at least once to tie it to the id, might as well send the email every time.
    Unless you only use the id and wait for your user to submit a form, which will retroactively tie all the analytics associated with that id with the contact (through I guess the hutk cookie value being passed along the form submission). But I doubt this is very practical for you !

Maybe the other experts tagged in this post have a better conclusion for this, but to my knoweldge and given the many tests done this morning, I don’t see how it could work any differently.
Hope this helps !
If it does, please consider marking this answer as a solution :slightly_smiling_face:

Best,

Ludwig

Thanks a bunch for the detailed exploration of this issue. What you say you experienced is how I read and interpetted the docs. However, I can’t reproduce the same behavior.

The custom events only show up if I set both email and id, or just use email. If I set them both, reload the page, then only use id going forward, I don’t see those events showing up for me. I have not set more than one id for my browser, which looks like the only thing in the docs mentioned that could mess this up. I can see the network traffic where the custom events are being sent to hubspot with the id field and related information of the custom event, but unless I also set email in that same pageview, the events don’t show up.

The only thing that looks different is that in your example you used a string to set the id field, but I’ve been setting a numerical id. However, when I look at the network traffic, whether it is set as a string or number, it seems to come through the same exact way. Setting it as a string also didn’t change the outcome I’m seeing where only events with email set on the same pageview get associated with my contact and show up in the timeline.

As a second pass on testing this, I was able to get the tracking to show up without having email present on each page view. I opened up a separate browser instance, cleared all cookies, browsed to our site, set the email and id via the identify function, and subsequent page views I didn’t need to set either the id or email.

So, my conclusion at this point is:

  1. Identify via email or form submission required on client: There is no way with hubspot to associate the visitor’s activity with an external id (id) without setting their email or having the user submit their email via a form. I believe this is a feature that HubSpot should support for those starting with existing contacts being imported, since it promotes bad practices.
  2. ID field isn’t useful for us given current functionality: The id field is really only useful when you want to associate events before you know their email address, but in our case we know it, we just don’t have easy access to it from the client-side javascript
  3. Email only required once (ideal conditions): You do not need to keep setting id or email after the first time for subsequent events to show up on the profile for some events to show up
  4. Email is required on each page if you don’t want to miss events: There is somehow a case where if you don’t keep setting email on each pageview that some events will not show up on the profile. My main browser is in this condition at the moment. I’m also logged into our hubspot account with the same browser, so maybe that is related? Something seems like it can get into a bad state and you could lose out on events if you don’t set email every time. I’m not even getting the default pageview event to show up when using my main browser, even after setting email via the identify method.

Given my experience in point 4 above, it seems like there is some missing explanation of how this works required by HubSpot.

Agreed !

And when you think that all this work is invalidated by visitors who ignore or refuse cookies… makes you want to cry :sweat_smile:

Anyway, we arrived at the same conclusion and I strongly agree there’s a lot of room for improvement on the tracking side of things.

Considering Google Analytics was rendered illegal in France (by the CNIL, the organization enforcing GDPR), there’s a plenty of room for HubSpot to get competitive advantage by refining their analytics systems and making them GDPR compliant.

You’re on the right track with setting up HubSpot tracking for your non-HubSpot-hosted website, but there are some key nuances to address in your approach. Let me walk you through the issue and how you might solve it:

Context:

  • Migrating to HubSpot: Since you’re migrating, you want to make sure that existing users can be associated correctly using a custom user_id, without exposing personal data like email addresses on the client side.
  • Tracking Existing Users: The goal is to ensure that once a contact is identified using their email, you can rely on the custom user_id in future interactions, without always passing email addresses.

Problem Breakdown:

  • Issue 1: Custom ID (user_id) Not Associating Events
    From your testing, events are only being associated with a contact when both the email and user_id are set, not when only the user_id is provided. This suggests that HubSpot’s identify function relies more on the email address to link the user session to the contact.
  • Issue 2: Manual Identification via Email Works
    When you manually identify a user with both the email, user_idevents and buffalo logistics tracking properly. But if you drop the email in subsequent interactions and rely on user_id, the connection to the contact breaks.