Hi Dan, thank you for your reply.
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_numbervssha256_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
sessionStorageconsidered “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) .
