Hi everyone.
I had a question about the storing function of the Data Tag Tag Template.
I just started implementing it and it’s a very interesting feature but i was wondering if saving user data in the Local Storage or Cookies is actually safe.
I know that Local Storage and Cookies (unlike Session Storage) dont get deleted so the data can be found by malicious people.
I thought that this would be an issue if the data is hashed with hash256 but I found out that hash256 can be uncrypted.
The main points are: is it true that saving hashed user data in local storage and cookies is not safe? And is saving data there GDPR compliant?
sha256 is one-way cryptographic function, there is now way to decrypt except for essentially bruteforce, or some pre-made dictionaries of particular values
the GDPR part of it - please consult a lawyer, but so long as the cookie is in your cookie policy, I don’t see any issues
By “safe” I specifically meant: can this data be accessed by malicious actors in the browser (and possibly in an unhashed form)? My concern is: if someone with bad intentions got access to the user data I’m storing, could they actually misuse it?
Context
I’m trying to track user data so that the advertising platforms (Google Ads and Meta) can use it for enhanced conversions and better attribute the conversion.
The problem is that my lead event fires on a different page (the thank-you page) than the form page, so when the user lands on the thank-you page I no longer have the form data available.
Since we’re talking about PII, I know that both Google and Meta can hash the data with their own templates, and that would be the ideal solution if the lead event happened on the same page as the form.
But that’s not my case, so I thought the only possible solution was to store the PII in sessionStorage and pass it to the thank-you page, hashing it because it’s sensitive.
What I know so far
Google can detect whether the data is hashed or not based on the parameter name (e.g. phone_number vs sha256_phone_number).
I couldn’t find something equally clear for Meta in terms of naming conventions.
If I use the “Facebook Pixel by Stape” template, I see there’s an option to store hashed user data in local storage and send it with the Pixel event — so I was wondering if this template could actually cover my use case.
What I’m unsure about
If I send the PII already hashed from the browser, can Google/Meta still use it properly for matching, or is it better to let the platform do the hashing?
Is storing PII (even hashed) in sessionStorage considered “ok enough” in this scenario, or is it a bad practice from a security standpoint?
Is there a recommended way to move user data from the form page to the thank-you page when they’re separate?
Extra clarifications (to show I’m not ignoring best practices):
I know that client-side storage (sessionStorage / localStorage) is still exposed in the browser and could be accessed in case of XSS, so I’m trying to understand what is considered acceptable here from an ads/tracking perspective.
I also know that a server-side setup (server-side GTM / CAPI / Google Enhanced Conversions via server) would be safer because the PII wouldn’t stay in the browser, but right now I’m trying to figure out the cleanest client-side approach due to current constraints.
Of course, everything would be done only for users who have given consent to tracking and to the use of their data for advertising.
I would only send the fields strictly needed for matching (email, phone, maybe name + country) and not the entire form payload — so, data minimization.
Regarding Meta: does anyone know if there’s an equivalent to Google’s way of detecting hashed values by parameter name, or is it generally better to let Meta handle the hashing?
I’ve been through forums, communities and official docs but I still couldn’t find a clear end-to-end flow for “form on page A → lead fires on page B → send hashed PII to ads platforms” fully on the client side.
I’d really appreciate your point of view.
I hope my explanation was clear enough and that you can help me find the light on this (or just share your point of view so I can start somewhere) .
