Event tracking and consent mode: measuring what you are allowed to see, and estimating the rest

The point: measure what you are allowed to see, and know what you cannot

A shop wants to know which campaigns sell, and it wants to stay within the law. The two pull apart the moment a visitor presses reject. In my experience most setups settle it by accident: the tags fire before anyone presses anything, or the shop reads a dashboard that quietly lost a third of its sales.

This article is the engineering in between, with the arithmetic shown. Shops selling into Germany and Austria meet national rules of their own, and those have their own article, on cookies and consent for shops selling into Germany and Austria. Here I stay with an Irish shop and Irish rules.

One invented business carries every example. Shandon Roasters is a coffee roaster in Cork run by Niamh, selling beans and brewing kit online at shandonroasters.example. Every number about it is made up. The law and the Google documentation are not, and they are footnoted.

An event is one thing a visitor did, written down

Analytics tools do not film a visit. They record small, named facts: viewed this product, added it to the basket, paid. Each fact is an event, with a name and a few parameters, such as which product and how much.

Google Analytics 4 (GA4) publishes recommended events for online shops, among them view_item, add_to_cart, begin_checkout, add_payment_info and purchase, and says that sending them with their prescribed parameters gives the most detail in reports.¹ Use those names rather than your own.

The purchase event is the one that pays for everything else, so it is worth getting exactly right. Google's reference lists transaction_id and items as required, and value and currency as required whenever you want revenue to be computed. The transaction id is what stops a refreshed confirmation page counting the same order twice.²

Worked example: Shandon's purchase event

A customer in Carrigaline buys one 1kg bag of house espresso at €24.00 and a hand grinder at €45.00. Shipping is €4.50. Google says value should be the sum of price times quantity for the items, without shipping and tax.² So:

$$\text{value} = \sum_{i} p_i \, q_i$$

Here $\text{value}$ is the number sent with the event, $p_i$ is the price of item $i$, $q_i$ is how many of item $i$ were bought, and $\sum_i$ means add the result up over every item in the basket. It is a plain sum of products, and the summation sign is introduced in Foundations: the mean.

Step by step: $24.00 \times 1 = 24.00$, then $45.00 \times 1 = 45.00$, then $24.00 + 45.00 = 69.00$. The shipping stays out. The event Shandon's checkout page sends is:

gtag('event', 'purchase', {
  transaction_id: 'SR-10482',
  value: 69.00,
  currency: 'EUR',
  shipping: 4.50,
  items: [
    { item_id: 'ESP-HOUSE-1KG', item_name: 'House espresso 1kg', price: 24.00, quantity: 1 },
    { item_id: 'GRD-HAND-01', item_name: 'Hand grinder', price: 45.00, quantity: 1 }
  ]
})

What Irish law asks of the code that sends it

The Irish rule is regulation 5 of the ePrivacy Regulations 2011, S.I. No. 336 of 2011, which brings the EU ePrivacy Directive into Irish law. Paragraph (3) says a person shall not use an electronic communications network to store information, or to gain access to information already stored, in the terminal equipment of a subscriber or user, unless the user has given consent and has been given clear and comprehensive information, prominently displayed and including the purposes.³ Terminal equipment is the visitor's phone or laptop.

The rule is not about cookies alone. The Data Protection Commission (DPC), which enforces it, says the law applies to pixel trackers, local storage, software development kits, social sharing tools and device fingerprinting, and that it does not matter whether the information stored or accessed is personal data.⁴ The European Data Protection Board (EDPB), where the EU's regulators sit together, goes further on the mechanics. In its guidelines on the technical scope of the rule it says that JavaScript instructing the browser to send information counts as gaining access, and that collecting information through HTTP headers such as the user agent can bring the rule into play.⁵

Regulation 5(5) holds the exceptions, and there are only two.³ Storage or access for the sole purpose of carrying out the transmission of a communication over the network, and storage or access that is strictly necessary to provide a service the visitor explicitly asked for. The DPC gives a shopping basket session cookie and a language preference as examples of the second.⁴ There is no exception for statistics, and none for the look and function of the site. That is where Ireland and the UK now part ways.

The DPC is direct about both kinds of tracking a shop cares about. Asked whether analytics cookies require consent, its answer is "Yes." And cookies related to advertising are not strictly necessary and must be consented to.⁴ Consent has the GDPR standard: freely given, specific, informed and unambiguous, by a statement or a clear affirmative action.⁶⁴

Once the data leaves the device the GDPR applies too. Online identifiers such as cookie ids and IP addresses are named in its definition of personal data, so what a tag sends onward needs a lawful basis and a record, not only a yes at the banner.⁶ The DPC's guidance note dates from April 2020 and the EDPB's guidelines were adopted on 7 October 2024.⁴⁵ Until the law changes, ad conversion tracking in Ireland needs a yes.

Worked example: sorting Shandon's tags into three piles

Niamh's site sets or reads seven things.

1. The basket cookie, once something is in the basket: strictly necessary, the DPC's own example.⁴
2. The login session: strictly necessary, it delivers the account the visitor asked to use.³
3. The cookie that remembers the consent choice: strictly necessary, since the site cannot honour a choice it forgets. The DPC adds that the visitor should be asked again no later than six months after the choice was stored.⁴
4. A self hosted page counter that keeps only daily totals per page, shares nothing, is named in the privacy notice and has an opt out link: in Ireland this needs consent too. Regulation 5(5) has no statistics exception.³ The DPC says first party analytics limited to aggregated statistics, with clear information and an easy opt out, are unlikely to be a priority for enforcement, which lowers the risk without changing the rule.⁴
5. GA4: needs consent. The DPC's answer on analytics cookies is a plain yes, and with Google Ads linked to the same property there is no argument left to make.⁴
6. The Google Ads conversion tag: needs consent. The DPC says cookies related to advertising are not strictly necessary.⁴
7. The Meta pixel: needs consent, for the same reason. The DPC names pixel trackers, and a shop that embeds one may be a joint controller for what it sends to Meta.⁴

So three things run before the banner is touched, and four wait for a yes. That is one more than a British shop holds back, because the UK added a statistics exception in 2026 and Ireland has none. Reject must have the same prominence as accept, pre checked boxes and sliders set to on are not allowed, and withdrawing consent must be as easy as giving it.⁴ Why nudging people into a yes is a liability is in the piece on dark patterns in consent design.

Consent mode is a messenger between the banner and the tags

The banner collects the answer. Consent mode is Google's interface for carrying it to every Google tag on the page, which then change their behaviour.⁷

There are four signals that matter for measurement and advertising.⁷

• ad_storage: may advertising cookies be stored.
• analytics_storage: may analytics cookies be stored.
• ad_user_data: may user data be sent to Google for advertising.
• ad_personalization: may that data be used for personalised advertising.

The last two are what people mean by consent mode v2. Google added them as part of enforcing its EU user consent policy.⁸ That policy applies to end users in the European Economic Area, which includes Ireland, and in the UK and Switzerland. It requires legally valid consent for cookies where the law requires it, consent for personalised ads, and records of the consent you collected.⁹ It is a contract condition from Google, not a statute, but an Irish shop running Google Ads is bound by it on top of the law.

Google also lists functionality_storage, personalization_storage and security_storage as consent types.⁷ The old version of this article put one of those among the core signals and left out the two v2 signals. That was wrong.

Every page needs two commands. A default, which sets the state before anything is measured, and an update, which the banner sends the moment the visitor chooses.¹⁰

Worked example: Shandon's default and update

On every page of shandonroasters.example, at the very top of the head, before the Google tag:

window.dataLayer = window.dataLayer || []
function gtag() { dataLayer.push(arguments) }
gtag('consent', 'default', {
  ad_storage: 'denied',
  ad_user_data: 'denied',
  ad_personalization: 'denied',
  analytics_storage: 'denied',
  wait_for_update: 500
})

Everything starts at denied, because in Ireland nothing outside the two exemptions may be set before the visitor consents.⁴ The wait_for_update value is in milliseconds. It tells the tags to hold for half a second in case the banner loads slowly and has a stored answer to pass on.¹⁰ Google also lets you set a different default per region with an ISO 3166 code, which is useful when one site serves several countries with different rules.¹⁰ Niamh sells in Ireland only, so one default covers everyone.

Then, when a visitor presses accept, the banner calls:

gtag('consent', 'update', {
  ad_storage: 'granted',
  ad_user_data: 'granted',
  ad_personalization: 'granted',
  analytics_storage: 'granted'
})

A visitor who accepts analytics but refuses advertising gets analytics_storage granted and the three advertising signals left at denied. The banner should send the update as soon as the visitor interacts with it, and on every later page it sends the stored answer again.¹⁰

Order is everything: the default must come first

Google's own documentation says it bluntly: the order of the code is vital, and if the consent code is called out of order, the consent defaults will not work. The default must run before any command that sends measurement data, such as config or event. For gtag.js the order is the default snippet, then the Google tag, then your consent tool.¹⁰

This is where I find most bugs. The GA4 tag fires on page view, the consent template a few milliseconds later, and in between the tag did what tags do. The banner looks grand and the law is already broken.

Read the flow from the top. The first two boxes happen before the visitor has seen anything, and they are the ones that decide whether the setup is lawful. The decision box is the banner. Only after it do the tags act on a real answer. The last box is the reminder that the order exists in the shop's own database whatever the visitor pressed.

Worked example: finding the bug on Shandon's product page

I open a product page in a private window with the network tab open, and do not touch the banner. Step one, I filter the requests for collect. One goes to GA4 at 140 milliseconds. Step two, I read its parameters. Consent mode encodes the storage state in a parameter called gcs, and the detailed state in gcd.⁷ If the first request shows analytics storage as granted, or if a _ga cookie appears in the storage tab before I press anything, the default came too late. Step three, I open Niamh's Google Tag Manager container and find the cause: a trigger exception left over from a test stops the consent template firing on product pages. Step four, I remove it, reload, and confirm the first request now carries denied and no _ga cookie exists until I press accept. Ten minutes, and in my experience the most common fault in an Irish shop's tracking.

Basic and advanced consent mode send different things on a no

Consent mode comes in two shapes, and they differ most when a visitor refuses.⁷

In basic consent mode, the Google tags are blocked until the visitor interacts with the banner. If the visitor refuses, no data is transferred to Google at all, not even the fact that they refused.

In advanced consent mode, the tags load straight away with consent defaulting to denied, and while it is denied they send what Google calls measurements without cookies, usually called cookieless pings. Google lists what those pings contain: functional information such as a timestamp, the user agent and the referrer, whether the current or an earlier page in the session had ad click information in its URL, the consent state, and a random number generated on each page load.⁷ Google uses the pings to model the conversions it cannot observe, and says advanced mode gives an advertiser specific model rather than a general one.⁷

Here is the honest part for an Irish shop. A cookieless ping is Google's script, loaded before any choice, telling the browser to send the user agent, the referrer and a timestamp to Google. The EDPB says JavaScript that instructs the browser to send information is gaining access, and names the user agent among the header data that can bring the rule into play.⁵ On that reading the pings fall under regulation 5(3). The EDPB is careful to add that being in scope does not by itself mean consent is needed, because an exemption may apply.⁵ But the only Irish exemptions are transmission and what is strictly necessary for a service the visitor asked for, and nobody asked for Google to model ad conversions. The DPC says cookies related to advertising are not strictly necessary.³⁴ I found no DPC statement on cookieless pings by name. So in Ireland I default to basic mode, and a shop that wants advanced mode should make that call with its own adviser, knowing the regulators' published reading runs against it. That is a firmer line than I take for a British shop, where the 2026 rewrite left the question more open.

Worked example: one visitor, two modes

A visitor from Mallow clicks a Shandon ad, lands on the grinder page, presses reject, browses two more pages and buys the grinder for €45.00.

In basic mode: the Google tag never loads on any of the four pages. Google receives nothing. The ad click shows in Google Ads, the sale does not. Niamh's database records the order.

In advanced mode: the tag sends a cookieless ping on each of the four pages, with the consent state, timestamp, user agent, referrer, an ad click flag and a fresh random number. No cookie is written, so no stored id joins the four. The sale is still not observed, though Google may model a share of sales like it if the account meets the thresholds below. Niamh's database records the order. Either way Google Ads observes zero conversions here. The only difference is whether Google gets material to estimate with, and in Ireland whether the shop has taken a legal risk to give it that material.

Server side tagging moves the tags, not the obligation

Server side tagging puts a tag server on your own domain between the browser and the vendors, and the server decides what to forward. Google recommends running the server on your first party domain, says you have full control over how the data is shaped and where it is routed, and says only you have access to the data in the server until you choose to send it elsewhere.¹¹

That control is real. You can drop the IP address, remove parameters a vendor has no business seeing, and keep a vendor's script out of the browser, so less runs on the visitor's device.

What it does not do is change the law. The browser still runs code that sends events to your tag server, and the EDPB says the entity that instructs the device to send information and the entity that receives it need not be the same for the rule to apply.⁵ So regulation 5(3) still covers what happens on the device.³ The DPC also expects the second layer of your banner to name the third parties who will process the information, and a shop that passes data to a vendor may be a joint controller for it.⁴ And the server must honour the same consent state the browser had. A tag server that forwards refused visitors to Meta because the pixel no longer runs in the browser has not solved a problem, it has hidden one.

It also costs money. Google's own Cloud Run guide prices each server at about 45 US dollars a month, recommends at least two instances so an outage does not lose data, and expects two to 10 servers to handle 35 to 350 requests per second.¹²

Worked example: what Shandon's tag server costs and does

Niamh's site gets about 1,000 sessions a day. At 20 events each that is 20,000 events a day, under one request per second, so two instances is simply Google's floor. Cost, from Google's figure: $2 \times 45 = 90$ dollars a month, before any traffic charges, billed by Google in dollars.

What Niamh gets for it: the tag server runs at tag.shandonroasters.example. When a consented purchase arrives, the server forwards it to GA4 and to Google Ads with the click id, and to Meta, with the IP address removed. When a purchase arrives with advertising refused, the server forwards nothing to Google Ads or Meta. For a shop this size, my view is that a correct consent setup in the browser comes first, and a tag server is the second project, not the fix for the first. The full build is in my technical guide to server side tracking.

Your own database sees every order, so let it

A visitor who refuses cookies still places an order. The order is a contract between them and the shop, and the shop records it in its own database to fulfil it. That record does not depend on any tag.

That is the most useful fact in the subject. The platforms see the consented share of sales, the shop sees all of them. If the order also carries the consent state at the time of purchase, which the shop knows because it stores the choice in the strictly necessary consent cookie, then the shop can count consented and refused orders separately.

What the shop sends onward from those records is where my own rule comes in, and I state it as my practice, not as a reading of the law. A consented order goes to the platforms as the standard event, purchase, with its identifiers. A refused order is renamed out of anything an ad platform optimises or builds audiences from. It becomes purchase_nc, with no click id, no cookie id, no hashed email. It is never mapped to a conversion action and never eligible for a remarketing audience. Its only job is to make the total in the shop's own report match the database.

Why a rename rather than a flag: the people who run ad accounts change, and a different name is much harder to misuse by accident than a forgotten setting.

Worked example: Shandon's October in the database

In October Niamh's database holds 470 web orders. Each one carries the consent state stored at checkout. The query is a simple count grouped by that state:

SELECT ads_consent, COUNT(*) AS orders, SUM(item_total) AS revenue
FROM orders
WHERE completed_at >= '2026-10-01' AND completed_at < '2026-11-01'
GROUP BY ads_consent

It returns 372 orders with advertising consent granted and 98 with it refused. The 98 stayed in Niamh's own reporting as purchase_nc. The total, 470, is October's truth, and it needs no model. If you want the data in a warehouse to join with campaign costs, the BigQuery setup for a Rails and Solidus shop shows the plumbing.

Estimating what the platforms cannot see

The database gives the total. The ad platform gives the consented part, tied to campaigns. Sharing the gap out between campaigns, or estimating it where orders carry no consent state, needs one honest assumption.

The old version of this article gave this formula, and it is a good one:

$$C_{\text{total}} \approx C_{\text{obs}} + S_{\text{ref}} \times CR_{\text{con}} \times \alpha$$

Here $C_{\text{total}}$ is the estimated total number of conversions, $C_{\text{obs}}$ is the number observed from visitors who consented, $S_{\text{ref}}$ is the number of sessions from visitors who refused, $CR_{\text{con}}$ is the conversion rate of consenting sessions, and $\alpha$ is how the refusers' conversion rate compares with the consenters', as a fraction. The term $S_{\text{ref}} \times CR_{\text{con}} \times \alpha$ is a rate applied to a count, which is Foundations: ratios and rates, and choosing $\alpha$ is a conditional probability question, which is Foundations: probability.

What the old version got wrong was the size of $\alpha$. It said $\alpha$ typically ranges from 0.7 to 0.9. Google's own modelling page says consented users are typically two to five times more likely to convert than unconsented users, varying by consent rate, industry and conversion type.¹³ Two to five times more likely means $\alpha$ between $1/5 = 0.2$ and $1/2 = 0.5$. Either way, 0.7 to 0.9 overstates the hidden sales, so I have corrected it.

Worked example: Shandon's October, estimated three ways

Niamh's banner logs only the choice, counted in aggregate, so she knows that of 30,000 October sessions, 18,600 had advertising consent and 11,400 did not. The share who consented is:

$$r = \frac{S_{\text{con}}}{S_{\text{con}} + S_{\text{ref}}}$$

$r$ is the consent rate, $S_{\text{con}}$ the consenting sessions and $S_{\text{ref}}$ the refusing sessions. So $r = 18{,}600 / 30{,}000 = 0.62$, or 62%. The groundwork is Foundations: ratios and rates.

The consenting sessions produced the 372 observed orders. Their conversion rate is $CR_{\text{con}} = 372 / 18{,}600 = 0.02$, or 2%.

If refusers bought at the same rate, $\alpha = 1$, they would have produced $11{,}400 \times 0.02 \times 1 = 228$ orders, and the total would be $372 + 228 = 600$.

At the top of Google's range, $\alpha = 0.5$: $11{,}400 \times 0.02 \times 0.5 = 114$, total $372 + 114 = 486$.

At the bottom, $\alpha = 0.2$: $11{,}400 \times 0.02 \times 0.2 = 45.6$, about 46, total $372 + 46 = 418$.

The database says 470.

The horizontal axis shows three estimates, each with a different $\alpha$, and the counted figure. The vertical axis is orders. From the same session counts the estimate moves from 418 to 600 on one assumption, and assuming refusers behave like consenters overstates the month by 130 orders. The database settles it.

It also lets Niamh measure $\alpha$ for her own shop instead of borrowing anyone's. Turn the formula round:

$$\alpha = \frac{O_{\text{ref}}}{S_{\text{ref}} \times CR_{\text{con}}}$$

$O_{\text{ref}}$ is the number of orders from refusing visitors, counted in the database, and $S_{\text{ref}}$ and $CR_{\text{con}}$ are as before. With October's numbers: $\alpha = 98 / (11{,}400 \times 0.02) = 98 / 228 \approx 0.43$. That sits inside Google's range of 0.2 to 0.5, which is reassuring, and it is Niamh's number, not an industry average. Measured monthly, it tells her how far to scale up what the ad platform reports. Foundations: ratios and rates covers the rearrangement.

Google's modelling has thresholds a small shop may never reach

Google does fill some of the gap itself, but not for everyone. For Google Ads conversion modelling, its help page states a threshold of 700 ad clicks over a seven day period, per country and domain grouping. It describes the modelling as analysing observable data and historical trends, aiming to minimise over prediction, and gives one illustration: an advertiser with a 50% consent rate that recovered an 18% uplift in conversions from modelling.¹³

For GA4, behavioural modelling of refusing visitors needs consent mode in the advanced shape on every page, at least 1,000 events a day with analytics storage denied for at least seven days, and at least 1,000 daily users with analytics storage granted on at least seven of the previous 28 days. Even then eligibility is not guaranteed, and the modelled data only shows when the property's reporting identity is set to Blended.¹⁴ For an Irish shop that follows my default of basic mode, GA4 modelling is off the table before any threshold is counted.

Worked example: is Shandon eligible?

Google Ads first. Niamh buys about 2,700 ad clicks a month, roughly 90 a day. Over seven days that is $90 \times 7 = 630$ clicks. Whether you read Google's wording as 700 a day or 700 over the week, 630 falls short. No Ads modelling.

GA4 next. About 1,000 sessions a day, and 38% of them refuse, so about 380 refusing sessions a day. At around 20 events each that is $380 \times 20 = 7{,}600$ denied events a day, comfortably over 1,000. But consenting users are about $1{,}000 \times 0.62 = 620$ a day at most, and fewer as users than as sessions. That is under the 1,000 daily users Google needs. No GA4 modelling either, even if Niamh took the risk of advanced mode.

So the modelled numbers agencies like to put in their decks will simply not appear for Niamh. The estimate anchored on her own database is the only one she has, and in my experience that is true of most independent Irish shops.

What I would build, in order

If Niamh came to me, I would do the work in this order.

1. The loading order: consent default first on every page, then the Google tag, then the banner, tested page type by page type.
2. The banner: accept and reject with equal prominence, nothing outside the two exemptions set in advance, a footer link to change the choice, the choice stored for the order and asked again within six months.⁴
3. The event plan: Google's recommended names and a correct purchase.¹²
4. Basic consent mode by default, with any wish for advanced mode and its cookieless pings put to the business's own adviser first.
5. The shop's own counting: consent state on every order, the renaming rule, and $\alpha$ measured monthly against the database.
6. Only if the shop needs the control, a tag server that honours the same consent state and names its third parties.⁴¹¹

None of this is exotic. It is careful plumbing, and it buys numbers Niamh can set budgets on and a setup she can explain to the DPC without sweating. The strategy on top of it is in my piece on privacy first growth.

Sources

Footnotes

1. Google, Recommended events, Google Analytics Help, https://support.google.com/analytics/answer/9267735

2. Google, Recommended events reference, purchase, Google for Developers, Google Analytics, https://developers.google.com/analytics/devguides/collection/ga4/reference/events

3. European Communities (Electronic Communications Networks and Services) (Privacy and Electronic Communications) Regulations 2011, S.I. No. 336 of 2011, regulation 5, Irish Statute Book, 2011, https://www.irishstatutebook.ie/eli/2011/si/336/made/en/print

4. Data Protection Commission, Guidance note on cookies and other tracking technologies, DPC, April 2020, https://www.dataprotection.ie/sites/default/files/uploads/2020-04/Guidance%20note%20on%20cookies%20and%20other%20tracking%20technologies.pdf

5. European Data Protection Board, Guidelines 2/2023 on Technical Scope of Art. 5(3) of ePrivacy Directive, version 2.0, EDPB, 7 October 2024, https://www.edpb.europa.eu/system/files/2024-10/edpb_guidelines_202302_technical_scope_art_53_eprivacydirective_v2_en_0.pdf

6. Regulation (EU) 2016/679, General Data Protection Regulation, Articles 4(1) and 4(11), EUR-Lex, 2016, https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:32016R0679

7. Google, Consent mode overview, Google for Developers, Tag Platform, https://developers.google.com/tag-platform/security/concepts/consent-mode

8. Google, Updates to consent mode for traffic in European Economic Area (EEA), Google Ads Help, https://support.google.com/google-ads/answer/13695607?hl=en

9. Google, EU user consent policy, Google, https://www.google.com/about/company/user-consent-policy/

10. Google, Set up consent mode on websites, Google for Developers, Tag Platform, https://developers.google.com/tag-platform/security/guides/consent

11. Google, An introduction to server side tagging, Google for Developers, Tag Platform, https://developers.google.com/tag-platform/tag-manager/server-side/intro

12. Google, Cloud Run setup guide for server side tagging, Google for Developers, Tag Platform, https://developers.google.com/tag-platform/tag-manager/server-side/cloud-run-setup-guide

13. Google, About consent mode modelling (the page title uses the American spelling), Google Ads Help, https://support.google.com/google-ads/answer/10548233

14. Google, Behavioural modelling for consent mode (the page title uses the American spelling), Google Analytics Help, https://support.google.com/analytics/answer/11161109