Public sector website tracking: How to measure campaign performance under GDPR

Quick summary: Public bodies can’t use legitimate interest for website analytics, which leaves consent as the lawful basis in most cases and consent rates on government sites run lower than on commercial ones. Server-side Tracking works on the part you are allowed to measure. Website events arrive at your own infrastructure first, so you decide which fields reach each tool, processing stays in the EU, and a consented visit can still be connected to an application submitted on a portal domain even after time has passed.

If your campaign reports show far fewer conversions than your own records do, the gap is likely not in your tag setup. Public sector journeys end somewhere a browser tag has limited reach: on a separate portal or booking domain, behind a login, in a case management system or weeks after the click that started it. On top of that, consent rates on government sites are lower than on commercial ones, so a share of your visitors is missing from the data before any tool receives it.

Public sector websites operate under a stricter version of the rules that apply to everyone else. The differences are specific enough that they significantly change what you can measure.

This guide covers what the data protection rules require, where the Google Analytics question stands today and what a server-side setup changes for public sector organizations that have to justify all their data flows. 

Is Google Analytics banned in the EU? 

Google Analytics hasn’t been banned in the EU and there is no EU-wide decision against it. What exists is a set of national decisions from 2022 and a transfer framework adopted in 2023 that is now under appeal. For a public body, that combination means the tool is usable today but you should have a written contingency plan.

Between 2022 and 2023, data protection authorities in Austria, France, Italy, Denmark, Norway and Sweden found specific uses of Google Analytics unlawful. The European Data Protection Supervisor (EDPS) reprimanded the European Parliament over its use of Google Analytics and Stripe on an internal COVID testing site which involved transfers to the US. Each decision applied only to the organization it was issued against, and all of them concerned transfers to the US.

In July 2023, the European Commission adopted an adequacy decision for the EU-US Data Privacy Framework, which created a legal route for transfers to certified US organizations. Using Google Analytics in the EU is lawful today, provided the receiving entity is certified and your own consent setup holds up. The risk you are carrying is a dependency on a single adequacy decision.

Is the EU-US Data Privacy Framework still valid?

Yes, for now. In September 2025, the General Court dismissed an action seeking annulment of the Data Privacy Framework (case T-553/23). The claimant, French parliamentarian Philippe Latombe, appealed to the Court of Justice at the end of October 2025 (case C-703/25 P), and that appeal has not been decided.

For a public body, this is a planning question. Safe Harbour was invalidated in 2015 and Privacy Shield in 2020, both after Commission approval. Both times, the organizations relying on them rebuilt under time pressure. If your campaign measurement depends on the current framework, write down now what you would do with six weeks’ notice and keep it with the DPIA.

Sovereignty is becoming a procurement rule, not just a preference

In June 2026, the European Commission proposed the Cloud and AI Development Act, which gives cloud sovereignty a four-level assurance framework that public bodies would apply based on their own risk assessments. It’s just a proposal and not law, so treat the levels as prospective procurement requirements.

The Commission has already applied the underlying framework to its own buying, awarding a sovereign cloud contract worth up to €180 million over six years to Post Telecom, StackIT, Scaleway and Proximus in April 2026.

For a measurement project, the consequence is that a stack chosen today is one you will be asked to justify against that framework later. If you are choosing a processing region this year anyway, choosing an EU one removes a migration that would otherwise be scheduled for you.

Why are the rules stricter for government websites?

There are three rules that apply to public bodies that give them fewer options and less flexibility than commercial organizations.

Legitimate interest is unavailable

The final line of GDPR Article 6(1) states that point (f) does not apply to processing carried out by public authorities in the performance of their tasks.

When a retailer’s visitor declines consent, the retailer can still rely on legitimate interest for basic analytics. You have no second option, so the quality of your consent decides how much of your audience you can measure.

Which organizations this applies to

The exclusion covers public authorities only when they are performing their public tasks. For central government departments, municipalities, agencies, schools, universities and public hospitals, that covers most of what the website is used for.

But it does not cover everything. A museum shop, a university’s commercial conference business, a public broadcaster’s advertising-funded arm and a municipal utility selling on the open market sit outside the public task, and legitimate interest may still be available for those parts of the site.

Where one domain carries both, treat the whole site as consent-based and document why.

Consent carries less weight when the relationship is unequal

Recital 43 names public authorities as a case where the imbalance between the organization and the visitor casts doubt on whether consent is freely given. Consent is still available to you, with two conditions. Refusing has to take one click and the service has to work the same way for someone who refuses.

Cookies need consent regardless of lawful basis

Article 5(3) of the ePrivacy Directive requires consent before storing information on someone's device or accessing information that is already being stored there. It applies separately from the GDPR question and concerns analytics cookies even where the data is not personal.

What should a public sector campaign measure?

When the data protection questions look hard, it’s tempting to just measure nothing at all to stay safe. That works until someone asks how many applications the campaign brought in, and the only numbers you have are impressions and clicks.

Public sector organizations buy a lot of paid media with defined objectives: 

• Recruitment for the armed forces, police, teaching and civil service roles
• Public health campaigns
• Benefits uptake and tax deadline reminders
• Grant-funded schemes
• Census and voter registration

Each of these ends in something countable, whether that is an application started, an appointment booked or a form submitted. Without that signal, your reporting is only able to tell you how much attention you bought rather than the tangible results that it led to.

The consent problem on public sector sites

Consent rates on government websites tend to be lower than on commercial ones, which creates a measurement gap that can’t be addressed by tag configuration. If a large share of your visitors declines tracking, your analytics only depicts the chunk of the people who agreed, which is not representative of your whole audience.

The skew runs in a predictable direction. Refusals concentrate among Safari and mobile users and among people who are already privacy-aware, which on a recruitment or public health campaign is frequently the audience you were targeting. There are two ways to prevent this from skewing your decisions:

• Show your consent rate next to every campaign figure, so the conversion count isn’t mistaken for the total.
• Break conversions down by browser before you determine that a channel is underperforming because a channel sending Safari traffic will look worse than it is.

It’s also important to know that where consent is missing, Google fills the reporting gap with modeled conversions, so part of what your dashboard shows is just an estimate. The lower your consent rate, the larger that share, which is worth understanding before you rely on modeled conversions to justify a budget.

A low consent rate pushes some organizations towards one of two options.

The first is designing the banner in a way that pushes people towards consenting, typically by using pre-ticked boxes, a buried reject option or a visually dominant “Accept” button. Regulators have issued decisions on pre-ticked boxes, reject options that are too difficult to find and uneven button styling, finding in each case that the collected consent was invalid.

The second is treating everything as exempt from consent. Strictly necessary cookies are exempt under ePrivacy and some national regulators accept narrow exemptions for aggregate audience measurement.

France is the clearest example of how that route works. CNIL used to publish a list of analytics tools it had assessed as exemption-eligible. It retired that list on 1 January 2026 in favor of providers assessing themselves against criteria that CNIL published in July 2025. The conditions are strict. Most tools fail on one condition: the provider must not reuse the data for its own purposes. Google Analytics doesn’t meet these requirements, because Google processes the data it collects for its own purposes, using it to improve its services and support its advertising products.

Germany applies §25 TDDDG, and DSK guidance takes a similarly narrow view of which analytics tools can run without consent. The Dutch AP sets its own conditions.

So, for most public bodies, the measurable audience consists of those who accept the banner, which is why it’s so important to get the data right. When someone consents to tracking, you should end up with the full journey: the click that brought them to the site, the form they submitted on the portal domain, the appointment they booked weeks later and so on. A lot of this data is lost to cookie lifetime limits, ad blockers and cross-domain tracking issues, before consent becomes the constraint.

What the browser loses before consent is even the question

Safari caps cookies written by JavaScript at roughly seven days, and shortens that to around 24 hours when the landing URL carries a known advertising parameter such as gclid or fbclid. Every paid click carries one and each Safari release has narrowed this further. 

Cookies set by your own server over HTTP avoid that cap, provided the endpoint is served from your own host rather than a separate tracking subdomain.

That gap hits public sector campaigns harder than most because the decision windows are long. A screening appointment gets booked months after the first ad. A candidate reads a vacancy page in March and applies in May. A resident checks a benefit in one session and applies in another. In each case, the browser has already forgotten which campaign started it, and the conversion lands in direct or organic.

What Server-side Tracking changes

Server-side Tracking moves the tagging work out of the visitor's browser and onto a server container running on your own domain. The website sends event data there and you decide what goes to each destination from that one place.

For a public sector organization, this has five key benefits.

You decide what data leaves your systems

With client-side tags, everything leaves the browser before you see it. That includes page URLs carrying case references, form field values captured by accident and search terms typed into a service finder. With a server container the data arrives at your infrastructure first, so data minimization under Article 5(1)(c) becomes a configuration you can export and attach to the DPIA as an annex.

The event stream stays in the region you chose, including the parts you filter out

Running the container on European infrastructure means the full event stream, including everything you filter out, stays in the EU. Your privacy notice describes a real data flow and the record of processing activities matches what the system does.

Consent is enforced in one place instead of in every tag

The server checks the consent state before forwarding and sends data only for the purposes the visitor agreed to. When someone withdraws consent, that decision is applied in one place rather than depending on every tag behaving correctly. We cover how this works alongside a CMP like Axeptio in our article Beyond the banner.

Fewer third-party scripts run on your website

Moving tags server-side reduces the number of external scripts loading in the visitor's browser. That means fewer third parties receiving data directly, as well as improved page performance, which matters for public sector sites that have to meet the accessibility and performance requirements set under the Web Accessibility Directive.

Your analytics choice stops being all or nothing

Organizations that move off Google Analytics often lose their campaign measurement at the same time because the conversion tags that fed Google Ads and Meta were built around the GA4 setup. With Server-side Tracking, your website sends one event stream to the container and you configure each destination independently, which means you can separate what you send to analytics and ad platforms. For example, if you are using an EU-hosted analytics platform, you can send the full data set there and limit what you share with Google Ads and Meta to only the conversion signals they need. We document how this can look in a Piwik PRO configuration. 

What Server-side Tracking does not solve

Server-side Tracking is a method for collecting and routing data. A few of the claims made about it will not hold up in a data protection review.

• It does not create a lawful basis. If legitimate interest is unavailable to you and a visitor hasn’t given their consent, moving the processing to a server does not make the processing lawful.
• Consent is still required for cookies. ePrivacy Article 5(3) applies to storing or reading information on a device – a first-party cookie set by your server is still information stored on a device.
• It does not convert a US processor into an EU one. Forwarding data to a US-based platform from a European server is still a data transfer governed by the same rules.
• Your privacy notice still has to describe what data you collect and who receives it. A server container changes which destinations appear in that list, so you need to update the notice whenever you add or remove one.

What Server-side Tracking gives you instead is control over what you send, a full record of what happened on your own infrastructure and a setup you can describe precisely in a DPIA. Each of those makes the pipeline easier to defend.

What your DPIA and procurement documents will need

DPIA questions for a website tracking project

Question	What to have ready
What personal data is processed?	The field list your server container forwards, per destination. See the field list below.
Where is it processed?	The hosting region of the container, plus the regions of each destination you forward to.
Who are the processors and subprocessors?	Your hosting provider and each platform receiving data. Ask your vendor for a current subprocessor list before you start.
What is the lawful basis?	Consent – document how it is obtained and how withdrawal is handled.
How is data minimization implemented?	The filtering rules in your container. See the field list below.
What are the retention periods?	Per destination, since your analytics platform and your ad platforms will differ.
What security measures apply?	Security certifications held by the hosting provider, access controls and who in your organization can change the configuration.

An example allowed-field list

Two of the questions above, what personal data is processed and how data minimization is implemented, are answered by the same document: the list of fields your container is allowed to forward to each destination. Below is a starting point for a public sector setup. Adjust it based on your own events.

Field	Analytics (EU-hosted)	Ad platforms	Reason
Page hostname	Forward	Forward	Needed to attribute the visit
Full page path	Forward	Strip to section	Paths name the scheme, condition or vacancy
Query string	Allow-list only	Strip	Carries case references, filters, quiz answers
Campaign parameters (utm, gclid)	Forward	Forward	The attribution signal itself
Event name	Forward	Rename to neutral	Names like housing_benefit_started describe the person
Conversion value	Forward	Forward	Needed for reporting and bidding
Form field values	Drop	Drop	Captured by accident more often than by design
Search terms on site	Forward	Drop	Useful internally, revealing externally
Email or phone	Drop	Hashed, only where a basis exists	Document the basis before enabling
IP address	Truncate	Drop	Full IP is rarely needed once the container has it
User agent	Forward	Forward	Device reporting
Referrer	Forward	Forward	Channel reporting
Logged-in user ID	Drop	Drop	Connects measurement to a case file
Consent state	Forward	Forward	The rule the server enforces

Three public sector tracking scenarios

The following scenarios describe situations where a browser tag stops working: the visitor moves to another domain, the conversion happens outside the website or too much time passes between the click and the outcome.

A municipality promoting a service that people apply for online

The campaign drives traffic to an application form hosted on a separate portal domain. The browser treats the portal as a new visit, so the completed application is recorded as direct traffic and the campaign shows almost no conversions. Meanwhile, the form's URL carries parameters describing which scheme the resident is applying for.

Click ID Recovery holds the identifier on the server and Multi Domain Tool keeps the session connected across the portal to ensure the application is credited to the campaign. The URL detail is stripped before the data is forwarded, and the ad platform receives a conversion with no indication of what the resident was applying for.

A public employer running a recruitment campaign

Applications are submitted through an applicant tracking system and the shortlisting or hiring decision follows weeks later. Your tracking only follows the click to the vacancy page, so that is the signal the ad platform optimizes on. It spends your budget finding people who open vacancy pages instead of people who apply.

Forwarding submitted applications as offline conversions from the applicant tracking system to the server gives the campaign a conversion tied to the actual objective. Later stages feed the same reporting, so you can report cost per hire from your own data. 

A public health campaign with a long decision window

Someone sees a screening campaign in March and books an appointment in June. The cookie set during the first visit is long gone, so the booking is attributed to direct traffic or organic search.

Cookie Recovery stores the identifier in an ITP-compliant first-party cookie and restores it on the user’s return, so the connection between the March visit and the June booking survives.

Implementing Server-side Tracking without rebuilding what you have

Your current setup keeps running while you add a server container alongside it. Before you switch to server-side, move events across one at a time and compare the results before switching anything off.

1. Start the DPIA before the technical work. In most public bodies, this takes longer than implementation, so it’s best to start early.
2. Audit what you currently send. Open a live event payload and read every field. Check your URLs, query strings, event names and form interactions for anything that identifies the person or names the service they were using.
3. Prepare the allowed field list with your Data Protection Officer. Decide what each destination should receive before you configure anything. 
4. Set up the server container on your own domain. Route one event through it first, starting with your most important conversion.
5. Apply the filtering rules. Strip URL detail beyond the domain, pass through only approved parameters and give events names that describe the action without describing the person.
6. Connect consent. The server should check consent state before forwarding anything. A withdrawal should then apply across every destination from that same place.
7. Add Consent Mode v2 if you run Google Ads. Google requires the four consent signals from EEA traffic. Without them, it stops building remarketing audiences and conversion modeling degrades. The container enforces consent across every destination, but Google will still expect the signals, so set up both.
8. Compare browser and server data before you switch anything off. The difference will be largest for Safari and mobile traffic, where browser limitations and ad blockers prevent the most events from being recorded. 
9. Bring in the systems the browser has no access to. Applications, bookings and later-stage outcomes are recorded in your own software, so send them to the container from there.
10. Document the rules and add them to your release process. A new parameter or a renamed event can undo the filtering you configured, so the rules need to be checked when the site changes. Our Server-side Tracking checklist is a good starting point.

How TAGGRS helps public sector organizations

TAGGRS hosts and maintains the server container, so your IT department does not have to set up or run cloud infrastructure for it. The setup runs on European servers and you know exactly where your data is processed and who has access to it. 

The setup extends your Google Tag Manager container. Your existing web container can keep running while you migrate tags and validate the results.

A few features are particularly important for a public sector implementation:

• Data Enricher filters and shapes event data on the server before anything is forwarded. This is where your allowed field list becomes an enforced rule. GTM transformations handle the stripping and renaming, and the configuration can be exported and used in your DPIA annex.
• Consent Approval Graph shows your consent rates over time, allowing you to see at a glance how much of your traffic you’re measuring.
• Multi Domain Tool handles the portal and booking domains, as we described in the scenarios above.
• The Piwik PRO configuration covers the EU-hosted analytics setup for organizations that have switched from Google Analytics. 

Conclusion

Measuring what the media budget achieved and keeping citizen data on infrastructure you can account for are usually treated as competing demands. By controlling the pipeline, you can clearly answer every question in the data protection assessment and maintain campaign reporting that holds up as tracking restrictions tighten.

Most of this comes down to knowing what your existing setup sends and where. Our free website tracking checker scans your domain and scores your tracking across pixels, server-side coverage, cookies and consent, with a recommended fix attached to every finding. It doesn’t need access to your tag manager or ad account, which also means you can run it before involving anyone internally.

If you are preparing an assessment, book a demo and we can walk through what a server-side setup would mean for your data flows, hosting region and subprocessor list.

FAQ