Cookie Consent: Separate the Analytical role of the HubSpot Cookie from the Tracking role

The Challenge


By default, in part, HubSpot determines the Original Source of a contact based on the First Page Seen property value. The First Page Seen value can only be recorded once a visitor has accepted cookies. More specifically, the First Page Seen property is populated when the HubSpot script is loaded.


Consider the following scenario


  1. A visitor lands on page X and the URL contains UTM parameters for tracking purposes that correspond to a Paid Search campaign
  2. The HubSpot script is loaded as part of the normal page load
  3. Once the page has loaded, the visitor accepts the cookie consent notice (the HubSpot script is *not* reloaded)
  4. The visitor navigates to page Y on the same website
  5. The visitor populates a form on page Y to access an asset

In the above scenario, page Y would be recorded as the First Page Seen, which has the knock-on effect of defining the Original Source as Direct Traffic instead of the correct identification as Paid Search.


The information available on HubSpot cookies states that the __hs_do_not_track cookie "still allows anonymized information to be sent to HubSpot". However, if the HubSpot script is loaded and the Do Not Track cookie is set then the Original Source is still not correctly assigned in the above scenario.


In the case where UTM parameters are present, the Original Source is calculated from the First Page View property.




If the HubSpot script is loaded, the First Page View property should be sent to HubSpot in either case as it represents valuable "anonymized information" prior to cookie consent being given.


Without such an approach, there is diminished value in any analytical feature of the HubSpot platform as the data cannot be relied on as being accurate. Furthermore, the Original Source property is one that is often synchronised to contact records within CRM systems from which ROI reports are determined. Therefore, there is a significant business risk associated with this problem if not resolved as such reports are used to determine future budgets and investment.

3 Comentários
Colaborador de Alto Nível | Parceiro Ouro
Colaborador de Alto Nível | Parceiro Ouro

Totally agree, there is so much that is wrong with the HubSpot 'out of the box' cookie banner tool that it is essentially useless, and that's before considering the fact that it is also non-compliant.

Using the tool renders the HubSpot analytics tool pretty wildly inaccurate, as mentioned above the majority of sources will be listed as direct traffic.

Where cookies are not accepted, but a contact moves to a new page and submits a form, the contact's source is captured from that page, rather than social, paid, organic etc as it would have been on the page they landed on. 

The guidance states that if a contact receives the cookie banner and clicks through to a new page, or views the page for a long enough period of time, the cookie can be lawfully dropped without a contact clicking 'accept'. The HubSpot tool does not do this.

From a compliance standpoint, the tool only allows a user to accept all cookies, or none at all. This is non-compliant, as it does not provide users the ability to select which non-essential cookies they are happy with, or provide implied consent through continuing to use the site. 

It also does not take into consideration the potential use of other services that use cookies, and does not drop or block them as required - as if no other tools than HubSpot are useful/necessary for a digital marketer. As a result of the reporting impact, Google Analytics is one that is absolutely required, but when using the HS cookie banner, it's cookies are dropped unlawfully.

This has resulted in us having to deploy not insignificant dev time to developing a custom cookie banner solution for our clients, which is not only compliant, but also optimised for consent conversion and without the impact on source reporting in HubSpot Analytics, as the HubSpot out of the box tool is currently (still) not fit for purpose. 

Colaborador Frequente

Thanks for the support @JoeDavies.


As you have alluded to, we have also created a custom solution for our cookie notice and do not use the default setup as we have to apply a consistent approach to the landing pages we host from HubSpot and our main website that is external from HubSpot. The issue is never the less that same regardless of using the out of the box solution or a custom one as it is the __hstc cookie that appears to facilitate the tracking of the First Page View, from which the Original Source is sometimes determined.


You are right in that this results in an all or nothing approach.


Let's hope that our voices are heard.

Funcionário da Hubspot
Funcionário da Hubspot

I figured out a solution to those contacts of yours who do not accept cookies and are bucketed as direct traffic.  You will need to check with your legal team whether this is GDPR compliant.

The journey of a contact that comes to a HubSpot website with a URL containing UTM parameters:  

  • A HubSpot banner is shown and when they don't accept or decline the cookies until they navigate away from the first page,  it is expected behaviour that the UTM parameters would not follow the user throughout the website
  • When the customer converts on a form they are bucketed as direct traffic/the hidden form fields would not capture the UTM parameters as they would not be on the page.

However, in the 'First Referring Site' property, the first URL that the customer comes from can be captured.  This is the metadata of all web pages and it is how the internet works with regards to SEO, backlinks etc.  This is not always captured due to certain referrer information rules eg. coming from an HTTP site to an HTTPS site.

This first referring site can include UTM parameters so in theory, if you create a workflow capturing all contacts with 'direct traffic' as an original source and first referring site contains exactly 'utm_source=' you can update the original source to the correct source.  You can do this with the 'last referring site' property as well. 




This is not a property that we use for tracking purposes nor is there a way for us to 'grab' the UTM parameters from this property outside of having the options in a workflow.  This is because this is metadata rather than tracking information.