Analytics without a permanent banner: Umami plus GTM

🇫🇷 Lire en français : Analytics sans bandeau permanent : Umami + GTM en campagne

Can you benefit from Google Ads without imposing Google Analytics, and its banner, on every visitor all year round? Yes. Our setup: Umami handles permanent measurement, with no cookie and no consent, and Google Tag Manager is only loaded during paid campaigns, wired to the same event triggers as Umami. The consent banner becomes seasonal: it appears only when the advertising runs.

Key points

• Umami handles permanent measurement, with no cookie and no consent; the GTM/GA4 layer loads only during Google Ads campaigns.
• One single instrumentation in the HTML: the same event attributes feed both Umami and GTM, whichever tool arrived first.
• Consent Mode v2 has been mandatory for Google advertising in the EEA since March 2024; the banner appears only while the Google layer is active.
• Campaign over: container off, cookies gone, banner removed. Umami, meanwhile, never stopped measuring.

To compare or correlate measurements between tools, you have to use the same event triggers. Two parallel instrumentations always end up diverging, and then nobody knows what is being compared.

— Olivier Watte, known as Oliver · founder of Kimoun

This article follows on from Is Google Analytics GDPR-compliant?, which sets out the problem; here, the implementation.

Why separate permanent measurement from advertising measurement  

  Tip

Day-to-day audience measurement does not need cookies; only advertising does. Separating the two layers avoids paying the price of consent all year for a few weeks of campaigning.

A professional site has two very different measurement needs. Day to day: knowing which pages are working, where visits come from, which buttons convert. Umami covers that need, exempt from consent in its cookie-free configuration. Occasionally: connecting conversions to a Google Ads campaign, which requires the Ads tag and often GA4, both consent-bound trackers.

The common reflex is to load GA4 and Google Tag Manager permanently, just in case. That is what we find on most Guadeloupean business sites we take over under a managed contract, including those that have never run a single campaign. The result: a consent banner 365 days a year, a heavy loss of navigation data, and 100 KB of scripts for campaigns that run for a few weeks. We do the opposite: the Google layer is off by default, and only switches on with the campaign.

How to wire a single instrumentation for both Umami and GTM  

The key to the setup: never instrument the site twice. Each event, a CTA click, a form submission, a WhatsApp click, is declared once in the HTML and read by both tools. It does not matter which one arrived first: both situations below run in production, on kimoun.com and on i-administration, the SPIP-based solution published by IPEOS.

Case 1: GTM came first, Umami hooks onto what exists (Hugo, kimoun.com)  

On kimoun.com, built with Hugo (the principle is identical under Astro), the Google Tag Manager integration predates the adoption of Umami. Buttons already carried a data-event attribute, read by GTM click triggers:

<!-- Existing button, instrumented for GTM from the start -->
<a class="btn btn-primary" href="/quote/"
   data-event="cta_devis_from_blog_umami">Request a quote</a>

Rather than rewriting every template, a bridge of a few lines feeds those same attributes to Umami:

// Bridge: existing data-event attributes (read by GTM) also feed Umami
document.addEventListener('click', function (e) {
  var el = e.target.closest('[data-event]');
  if (el && window.umami) umami.track(el.dataset.event);
});

No template modified, no event renamed: Umami inherits the historical GTM taxonomy, and the series stay comparable from one period to the next.

Case 2: Umami came first, GTM picks up its events (SPIP, i-administration)  

On i-administration, the SPIP solution published by IPEOS, it is the other way round: the templates are natively instrumented for Umami with the standard data-umami-event attribute:

[(#REM) SPIP template — button instrumented for Umami ]
<button type="submit" class="btn btn-primary"
        data-umami-event="form_demarche_envoi"
        data-umami-event-service="#TITRE">Send my request</button>

When a campaign requires GTM to be switched on, no code is added on the site side: in GTM, a click trigger filters elements carrying data-umami-event, and a click element variable reads the attribute value to pass it straight to GA4 as the event name. GTM aligns itself on the Umami taxonomy, not the other way round.

In both cases the rule is the same: one attribute in the HTML, one name per event, two consumers. A conversion is called the same thing on both sides, otherwise any correlation between Umami and GA4 turns into guesswork.

How to switch GA4 on only during a paid campaign  

  Tip

The Google layer is turned on by a single site configuration switch: GTM, Consent Mode and the banner appear together at campaign launch, and disappear together at the end.

Loading GTM is gated by a site configuration parameter: on a Hugo or Astro site, a boolean in the configuration file; on SPIP, a plugin configuration variable. Campaign launched, you flip the switch to on and deploy. The template then injects, in order: the Consent Mode v2 initialisation (default state “denied”), the consent banner, then the GTM container.

Inside GTM, the container holds the Google tag (GA4 configuration), the Google Ads conversion tag, and triggers aligned on the event attributes described above. Consent Mode v2 has been mandatory for Google advertising in the European Economic Area since March 2024, and Google now conditions Ads conversion tracking on its presence: the setup includes it by default.

Campaign over: switch to off, redeploy. No container, no cookie, no banner. Umami noticed nothing: it was measuring before, during and after.

  Note

On kimoun.com, the GTM container stayed loaded permanently for a handful of events, with a banner shown to every visitor. The switch described here removed the banner outside campaigns and lightened the load on every page, without losing a single measurement data point, now carried by Umami.

What to do with the consent banner  

  Important

As soon as the Google layer is active, prior consent becomes mandatory again: GA4 and the Ads tag set cookies that benefit from no exemption. A compliant banner is required, refusing must be as easy as accepting, and no tag may fire before the choice is made.

The banner follows the Google layer, in both directions. It appears with it, properly configured: “Accept” and “Reject” buttons at the same level, tags firing only after consent, Consent Mode v2 passing the state of that choice to Google. It disappears with it, since no consent-bound tracker is left on the site.

During the campaign, one reality has to be accepted: GA4 will only see consenting visitors, barely more than half the traffic. That is not a problem as long as the roles are clear: Umami gives real volumes, GA4 and Google Ads give advertising attribution on the consenting population. The two figures are not to be compared with each other; each answers its own question.

Which traps to avoid  

Three mistakes come up again and again in this kind of setup.

1. Double counting. If an event is sent to GA4 both by an attribute trigger and by an automatic click tag, conversions double. One sending path per event, no more.
2. Forgetting to switch off. A campaign ends, the container stays, and so does the banner. Write the deactivation into your end-of-campaign checklist, alongside stopping the Ads budget.
3. Naive comparison. Concluding that “traffic has collapsed” from reading GA4 during a campaign, when it only sees consenting visitors. The reference volume is Umami.

One last useful habit: test the setup in staging with GTM preview mode before every campaign. Five minutes of checking saves you from paying for clicks whose conversions never come back. On the campaigns we run for Guadeloupean businesses, it is the cheapest check there is.