Is it valid to load Google Analytics or Hotjar before obtaining user consent?

No, unless the tool is configured in a strictly necessary mode and using first-party cookies that do not entail personalised tracking, a scenario that in practice is very limited. The operational rule of art. 22.2 LSSICE and the AEPD's cookie guidance is that cookies and similar technologies that are not strictly necessary to deliver the service expressly requested by the user can only be activated after informed, granular and revocable consent. Google Analytics and Hotjar are traditionally analytics and behavioural tools that process personal data (IPs, identifiers, recorded sessions), so loading them must be conditional on consent. Configurations such as Consent Mode v2 without prior consent still require careful analysis: sending consent pings or signals can still constitute processing. The developer must be able to demonstrate that without clicking 'accept' no third-party SDKs are downloaded and no persistent identifiers are set.

How is a consent management platform (CMP) configured in line with the AEPD?

A CMP compliant with the AEPD guidance must observe several principles. First, no cookie walls without an equivalent alternative: the user must be able to navigate without accepting, save in very specific justified scenarios. Second, no asymmetric design: the 'reject' button must be as visible and accessible as 'accept', with no muted colours, tiny text or additional layers. Third, real granularity by categories (strictly necessary, functional, analytics, marketing, personalisation) with the ability to accept and reject per category. Fourth, evidence logging of consent: date, banner version, accepted categories, anonymous identifier. Fifth, no activation of third-party cookies before user interaction. Sixth, clear path to review and revoke consent at any time from a permanent link in the website footer. Seventh, periodic refresh of consent (the AEPD has been considering an indicative period of 24 months reasonable, without prejudice to updated criteria).

Who is liable if a website loads pixels without consent: the client or the developer?

Before the AEPD and the users, the site owner (controller) is liable, because they decide the purposes of the processing. But the developer or agency that technically implemented the tool is liable to the client under the services contract and the art. 28 GDPR contract: if they delivered the website loading pixels before consent, configured the CMP in a misleading way or ignored reasonable client instructions on cookies, they assume contractual liability and, depending on the case, also liability before authorities as a joint controller or non-compliant processor. The reasonable approach in any professional project is: the client decides what tools to use and for what; the developer documents how they are implemented; the banner faithfully reflects what the site does; and an updated cookie inventory is delivered to the client (name, purpose, duration, provider, legal basis).

Cookies, analytics and tracking: developer obligations (GDPR and LSSICE)

Q: What obligations does a developer have when implementing cookies and analytics tools on a client's website?

The controller is the client owning the site, but the developer who implements cookies, analytics, marketing pixels or heatmap tools technically configures the client's legal decisions and usually acts as a processor (art. 28 GDPR) over what they touch. Their main technical obligations are: load all scripts that are not strictly necessary only after consent, never before or in parallel with the opening of the banner; configure the consent management platform (CMP) to obtain granular consent per category and record the evidence; respect the user's signal to reject (the reject button must work technically, not just visually); avoid undue pre-loading of SDKs, external fonts, maps or embedded videos; minimise and, where appropriate, configure the tool to reduce unnecessary transfers of personal data outside the EEA; document for the client which cookies are set, their purpose, duration and provider. All of this within the framework of art. 22.2 LSSICE and the AEPD's current cookie guidance.

Most visible non-compliance on websites does not stem from a bad client decision but from an imprecise technical implementation: scripts loaded before consent, banners with a hidden "reject", pixels injected directly in the head, analytics tools active without granularity. The developer who builds those elements is the first technical guardian of compliance.

This article goes through what any technical profile touching websites should have resolved under the GDPR (Regulation (EU) 2016/679), the LOPDGDD (Spain's Organic Law 3/2018), art. 22.2 of LSSICE (Spain's Law 34/2002) and the AEPD's guidance on the use of cookies in its current version.

The legal framework applied to the code you write

Three rules operate at the same time over a website with cookies and tracking:

Rule	What it requires	Practical application
Art. 22.2 LSSICE	Prior informed consent for cookies and similar technologies that are not strictly necessary.	Banner with prior blocking of non-necessary scripts
GDPR (arts. 6, 7, 13)	Valid, transparent, granular, revocable consent; duty to inform.	CMP with categories and evidence logging
GDPR (arts. 44 et seq.)	International transfer regime if tools operate outside the EEA.	Verify DPF, SCCs, regional configuration
LOPDGDD + AEPD guidance	Sets requirements for banner design, symmetry of options, consent refresh.	No cookie walls without alternative; reject as accessible as accept

Conditional loading: the operational principle

The essential technical rule is easy to state and demanding to apply: no cookie or third-party script that is not strictly necessary can be downloaded, initialised or executed before the user has given consent. This means:

Tags for Google Analytics, Google Tag Manager (when launching third-party tags), Hotjar, Meta Pixel, LinkedIn Insight, TikTok Pixel, heatmap tools and similar do not go in the head as direct scripts.
They are loaded under the control of the consent management platform, which activates them only if the corresponding category has been accepted.
External web fonts (Google Fonts loaded from Google's CDN), embedded maps (Google Maps), videos (YouTube, Vimeo) that set cookies or transfer data: they are either loaded as a static facade until consent, or replaced by local / privacy-friendly alternatives.
"Reject" must actually prevent the loading of scripts, not merely close the banner.
Subsequent revocation must stop the activity and, where possible, delete cookies already installed.

The consent management platform (CMP): what the AEPD requires

The AEPD's guidance on the use of cookies has consolidated several criteria that the developer must translate into the configuration of the chosen CMP (Cookiebot, OneTrust, Iubenda, Didomi, Complianz, an in-house solution…):

No cookie walls without an equivalent alternative: the user must be able to use the site reasonably without accepting non-necessary cookies, save in very specific justified scenarios.
Visual symmetry between accept and reject: same size, same level of visibility, same number of clicks. None of "accept" in orange with "configure" in small grey.
Real granularity by category: strictly necessary, functional, analytics, marketing, personalisation. The user must be able to accept some and reject others.
Evidence logging: date, banner version, accepted categories, anonymous identifier, retention sufficient to demonstrate consent during an inspection.
Accessible revocation at all times from a permanent link in the website footer.
Periodic refresh of consent: the indicative period considered by the AEPD has been 24 months, without prejudice to criterion updates.
Clear information on each cookie: name, purpose, duration, provider, international transfers where applicable.

Patterns the AEPD has considered problematic

Banner with a single "accept" button and a tiny "configure" link.
Loading Analytics or pixels in parallel with banner opening.
Pre-ticking optional categories as accepted by default.
"If you continue browsing, we take it that you accept" without affirmative action.
Reject button hidden behind two layers or with discouraging text.
Banner that closes by itself on scroll and is interpreted as acceptance.
Outdated cookie policy that does not reflect the real tools.
Persistent cookies created on the first visit even when the user rejects.

"A professional developer delivers three things with any website: code that works, the inventory of cookies that get installed and the evidence that reject means reject. If the client only receives the first, the site is not finished. It is pending."

Mario P. Talamillo · Managing Partner, Certix®

Google Analytics, Hotjar, Meta Pixel and similar: how to handle them

The most widespread analytics and tracking tools process personal data (IPs, device identifiers, recorded sessions, events linked to a visitor). Technical recommendations:

Google Analytics 4: load after consent of the "analytics" category. Review retention, IP, signals and advertising configuration. If Consent Mode v2 is used, understand what is sent and what is not before consent; document it and reflect it in the cookie policy.
Hotjar and heatmaps: load after consent. Filter sensitive fields (forms, personal inputs). Configure exclusion of pages with sensitive data.
Meta Pixel, LinkedIn, TikTok: load after consent of the "marketing" category. Document advertising purposes.
Embedded videos: use privacy mode where available (YouTube no-cookie), or a static facade with click-to-load for the real iframe only after consent.
External fonts and libraries: prioritise local loading (Google Fonts served from your own domain, self-hosted libraries) to avoid automatic transfers.
International transfers: most tools entail transfer to the US. Verify the provider's adherence to the Data Privacy Framework (DPF) or the existence of current Standard Contractual Clauses (SCCs), and inform the user.

What the developer should deliver to the client

Beyond the code, a professional delivery includes:

Cookie inventory: table with name, purpose, duration, provider, legal basis, transfers.
Draft cookie policy aligned with the actual implementation (the controller or their adviser will draft it, but the dev provides the inventory).
Technical demonstration: screenshots or video showing that with "reject" the marked scripts do not load.
CMP documentation: version, configuration, how to refresh consent, how to review logs.
Update procedure: how to add or remove a tool without breaking compliance.

Developer technical checklist

No non-necessary third-party scripts in the initial HTML.
CMP correctly integrated and tested with "accept all", "reject all" and granular configuration.
Accept and reject buttons symmetric (style, size, number of clicks).
Real categories (not just "accept" / "reject all").
Operational consent evidence logging.
Accessible revocation from the website footer at all times.
Fonts, maps and videos with no direct third-party loading before consent.
Cookie inventory delivered to the client and linked in the policy.
Periodic verification when adding plugins, integrations or new pixels.
Review whenever the AEPD criterion or the version of the guidance changes.

Frequently asked questions

What obligations does a developer have when implementing cookies and analytics?

Load non-necessary scripts only after consent, configure the CMP with real granularity and symmetry between accept and reject, log consent evidence, avoid undue pre-loading of fonts, maps and videos, document the cookie inventory and respect the criteria of art. 22.2 LSSICE and the AEPD cookie guidance.

Is it valid to load Google Analytics or Hotjar before consent?

As a general rule, no. Art. 22.2 LSSICE requires prior consent for cookies that are not strictly necessary. Analytics and Hotjar process personal data and must be loaded after consent of the corresponding category. Configurations like Consent Mode v2 require case-by-case analysis.

How is a CMP configured in line with the AEPD?

No cookie walls without alternative, visual symmetry accept/reject, real granularity by category, evidence logging, accessible revocation at all times, periodic consent refresh (indicatively 24 months) and clear information on each cookie.

Who is liable if a site loads pixels without consent: the client or the developer?

Before the AEPD, the site owner (controller). Towards the client, the developer is liable under the services contract and the art. 28 GDPR contract: if they implemented the tool in a non-compliant way, they assume contractual liability and, depending on the case, also liability before authorities.

This content is informational and educational in nature and does not constitute specialised legal advice. Applying the regulation to a specific case requires individual analysis. Spanish regional and sector-specific rules may extend or modify timeframes and requirements.

Building websites and want to deliver the cookie module done properly?

At Certix we help developers and agencies configure the CMP, draft the cookie inventory and leave compliance ready for the client.

Talk to an expert

Developers, cookies and analytics: how to implement tracking without skipping GDPR