The reason to open this post is that we have found there’s a need for our customers.
Currently, embedded forms respondents cannot be tracked by our customers, and the reason for this is that the script that is loaded in our renderer injects the cookie “hubspotutk” without some properties:
js.hs-scripts.com/6616343.js.js
Looking at the script, looks like it’s a loader of more scripts and not the one injecting the cookie itself, but this could be a first step to see the feasibility of the requested feature.
This cookie is considered as a cookie set in a 3rd party context, and browsers relatively recently started blocking them by default, unless you specify something in the cookie params when you set it.
We could try to tweak “hubspotutk” cookie by adding the properties
secure=true;samesite=none; - this approach, for instance, works with Google Analytics.
Please find an article here that follows this approach:
Could you please let us know is this is something feasible?
Many thanks for your time.
Best regards,
@mshamota
HubSpot cookies are first party cookies. The scripts responsible for setting HubSpot cookies will generally be hosted on a domain different from the customer’s website (i.e. the HubSpot analytics script is hosted at hs-analytics.net) and this is likely the reason that Chrome is flagging the cookies as being ‘associated with a cross-site resource.’ The HubSpot scripts setting the cookies are considered cross-site resources, however the cookies themselves are first party cookies and do not track visitors across multiple websites/domains.
For cookies that do not specify the SameSite attribute, the browser will default to treating these cookies as if the SameSite attribute is set to ‘Lax’ and this state is acceptable for the functions HubSpot uses its cookies for.
The wording in the Chrome warning about “will only deliver cookies” or “It has been blocked” refers specifically to Chrome not passing the cookie value along in the headers of the request. HubSpot analytics passes the values we need as query parameters on requests, so because our tracking doesn’t expect the cookie to be present in the header this does not affect our tracking functionality.
Hope this helps.
Thanks for your response Dennis. I think for most scenarios tracking is working fine.
Our problem is that the tracking functionality is not working for respondents on embedded Typeform iframes.
Is it feasible that this properties are added to cookies so we can try to solve this use case?
Thanks for your time.
Best regards
@mshamota , I would suggest creating an idea (with your specific use case).
All right, we will do that.
Thanks