How to Keep UTM and gclid Attribution Through Varnish and Full Page Cache on Magento 2

TL;DR

A tagged click lands on a cached page. The browser keeps the full URL, so the Google tag and the pixels see the campaign; Magento's server does not, because stock Varnish rewrites the URL before lookup, the built-in cache ignores the same parameters from 2.4.8 on, and cacheable responses carry no cookies back. Since v1.17.4 the capture happens in the browser and the values travel to the order. GA4 applies them to the purchase as event-scoped campaign values; session reports rest on a separate join. Google's caution about UTMs next to a GCLID becomes a tagging rule.

Key Takeaways

• Stock Varnish strips utm_*, gclid, fbclid and other marketing parameters before cache lookup; the 2.4.8 and 2.4.9 VCL adds gbraid, wbraid, msclkid and more [2].
• Since Magento 2.4.8 the built-in Full Page Cache removes marketing parameters too, "mirroring the logic used when Varnish is in use" [3]. Running without Varnish no longer keeps them.
• The VCL your Varnish host runs is the file somebody exported [4], so its parameter list is the one from that export's Magento version.
• The v1.17.4 fallback (September 1, 2026) captures utm values and the gclid, not gbraid or wbraid [1].
• GA4 receives the values as event-scoped campaign data for the purchase [7][8]. Session-scoped reports rest on a separate join.
• With Google Ads auto-tagging on, keep UTMs off your Google Ads final URLs [10][11].

What happens to a tagged click on a cached page

Follow one visit. A shopper arrives on /jackets.html?utm_source=newsletter&utm_medium=email&utm_campaign=fall-sale, and the page is already warm in the cache.

Behind stock Varnish, the shipped varnish6.vcl handles the request in vcl_recv under the comment "Remove all marketing get parameters to minimize the cache objects" [2]. It deletes those parameters from the request URL, then looks up /jackets.html; on a miss the backend is asked for /jackets.html and never receives the campaign. Varnish rewrites internally and sends no redirect, so the address bar keeps the tagged URL and the browser-side tags read it normally.

Both layers also keep cookies off cacheable responses. The VCL runs unset beresp.http.set-cookie on cacheable GET and HEAD responses [2], and the built-in cache clears the Set-Cookie header on responses it caches [6].

Behind Varnish, and with the built-in cache from 2.4.8, a tagged click on a warm page gets the stored copy of the untagged page: Varnish never passes the request to Magento, and the built-in cache answers from storage without rendering the page. Either way the cached response carries no cookie that would remember the campaign.

The one place the campaign survives is the address bar.

If your store runs on Adobe Commerce on cloud infrastructure, the cache in front of it is Fastly [4], which this article does not cover.

Which parameter list is your Varnish actually running?

Adobe's setup procedure is a manual export and copy: rename the exported varnish.vcl "to default.vcl. Then copy the file to the /etc/varnish/ directory" [4]. A Magento upgrade does not reach that file. A store upgraded to 2.4.8 with a VCL exported on 2.4.6 still passes msclkid and gbraid through to the backend while stripping gclid and every utm_*.

If you inherited the Varnish box from a previous agency, run this check first. Compare the file on the host with what your current version would generate:

# the list the Varnish host is running
grep -A1 "Remove all marketing get parameters" /etc/varnish/default.vcl

# the list your current Magento version generates (on 2.4.8 or later, use 7 for a Varnish 7 host)
bin/magento varnish:vcl:generate --export-version=6 | grep -A1 "Remove all marketing get parameters"

The command "Generates Varnish VCL and echos it to the command line" [5], and 2.4.8 added an "Export VCL for Varnish 7" admin button [3]. If the outputs differ, you know which click IDs reach your backend.

Why capture moved into the browser

The extension's change log records three attempts at the same problem [1]:

• v1.15.3, June 20, 2025: Measurement Protocol events include a "gclid" parameter "if one is available in the frontend cookie".
• v1.16.1, March 6, 2026: UTM parameters found in the URL are persisted for server-side purchase events, "mostly a precaution" that "will likely not result in major data differences".
• v1.17.4, September 1, 2026: a campaign-capture fallback "that stores utm and gclid values from the landing URL in a first-party cookie and reads them back server-side, so attribution survives Varnish stripping the parameters and Full Page Cache dropping cookies on cacheable responses."

The 1.16.1 wording makes sense once you know the cache layer. A server reading campaign parameters reads a request Varnish already rewrote, or one the built-in cache answered from storage, and remembering values between requests needs a cookie that cacheable responses do not carry. The browser sees the tagged URL on every stack, so v1.17.4 captures there.

What the fallback does, at the level you need to operate it:

• Coverage is the five utm values and the gclid. gbraid and wbraid are not in it.
• Capture keys on utm_source. A link carrying only utm_medium and utm_campaign is not captured.
• The stored set is last-touch: a newer visit with utm_source replaces it.
• Campaign values the server captured itself in the session take precedence; the cookie fills in only when those are missing.
• Values are stored on the order, so a purchase pushed later by cron still carries them.

One limit sits outside the extension. The cookie is written by script, and WebKit's February 2019 announcement caps "persistent cookies created through document.cookie" at "a seven day expiry" [12]. A Safari shopper who buys days after the click may reach checkout without it.

What does GA4 actually do with the captured values?

When the purchase is sent, the stored UTM values go with it as a Measurement Protocol event Google defines like this: "Use this event to send campaign details that will be applied to events with a timestamp greater than or equal to the timestamp of the campaign_details event" [7]. So the purchase reaches GA4 carrying campaign values. Google notes that this event won't be visible in Google Analytics reports or DebugView [7], so step 4 below reads the log.

Google is precise about what that buys. Values sent in the middle of an existing session "are associated with the events for which they were collected and the data is used for event-based attribution, but the campaign and traffic-source values are not associated with the existing session of the user" [8]. That is event-scoped attribution for the purchase. Session source and medium depend on a separate join with the browser session, which our article on GA4 purchases landing as Unassigned covers with the other causes.

The gclid travels as the parameter v1.15.3 added, which our change log says "may help" attribution [1]. Google's documented route for click identifiers is different: it says identifiers such as GBRAID and WBRAID collected during online interactions "are automatically joined with Measurement Protocol events using client_id" [9]. Treat the parameter as a hedge. The Google Ads side of the click is in our guide to Google Ads conversion tracking on Magento 2.

Tag your links so the fallback never contradicts Google Ads

Google's Analytics Help, on Measurement Protocol purchase events: "Avoid including manual campaign details (for example, utm_source, utm_medium, and utm_campaign) unless these details reflect new campaign interactions. Including manual campaign values alongside existing Google Click ID (GCLID) values can lead to misattribution, incorrectly attributing events to UTM instead of the expected Google Ads (google/cpc) source" [10].

Google Ads Help supplies the other half: "in Google Analytics 4 (GA4), auto-tagging is prioritized over manual tagging due to the absence of an override option" [11]. The rule that follows: with auto-tagging on, do not add UTMs to your Google Ads final URLs. A Google Ads click then lands with a gclid and no UTMs, so the Google Ads landing itself never carries both. The rule does not clear a set stored earlier: the stored utm values change only when a link with utm_source arrives, and the gclid is kept separately, so a shopper who reached you from a tagged link before clicking an ad can still reach checkout with both.

Put utm_source on every hand-built link, because without it nothing is stored. Also check your redirects: Google Ads Help says the GCLID has to be passed to the final landing page [11], and the capture can only read what is in the address bar when that page loads.

How to check it on your own stack

1. Confirm you are on v1.17.4 or later, with Admin → WeltPixel → GA4 PRO → Enable Measurement Protocol Tracking Configuration set to Yes and Enable File Log set to Yes [1].
2. Load a product page once without parameters so it is cached, then open it in a private window with ?utm_source=cachetest&utm_medium=email&utm_campaign=varnishcheck.
3. In the browser's developer tools, under Application → Storage → Cookies, find the campaign cookie the extension sets and confirm it holds your test values.
4. Place a test order in that session, then read its purchase entry in var/log/ga4.log and look for the campaign values in the logged request [1]. Our guide to verifying GA4 events on Magento 2 covers the log and DebugView in detail.
5. Repeat with a link that has utm_campaign but no utm_source, and confirm nothing new is stored.

Since v1.17.4, with Require Visitor Consent for Server-Side Events switched on, a purchase from a shopper who declined is not sent to GA4, so its campaign values are not sent either, as our guide to server-side events and consent explains.

Why not keep the parameters in the VCL instead?

The alternative is to take the marketing parameters out of the strip list and let the backend see them. The cost is the reason the list exists. The VCL's own comment describes stripping as a way "to minimize the cache objects" [2], and Adobe's 2.4.8 notes say that before the built-in cache did the same, these parameters "could lead to cache bloating and reduced performance" [3]. Every distinct tagged URL becomes its own cache object, and click IDs change from click to click, so pages reached from ads would seldom find a warm copy.

The browser-side capture leaves the cache as it is, and the owner of the hit ratio picks the cost.

The same release also fixed a smaller cache problem on the extension's side: v1.17.4 stopped a PHP session from being started on anonymous Full Page Cache hits, which had been "issuing a session cookie to visitors who should never have received one" [1].

FAQ

Does the fallback fix purchases landing as Unassigned?

Not in session-scoped reports: Google applies these values to the purchase event and does not associate them with the session [8]. Unassigned has its own causes, covered in the article linked above.

I run Magento 2.4.8 without Varnish. Am I affected?

Yes. Since 2.4.8 the built-in cache removes marketing parameters from its cache key, "mirroring the logic used when Varnish is in use" [3], and it clears Set-Cookie on the responses it caches [6].

Do the Conversions API addons use the captured values?

The fallback feeds GA4, and the change log does not describe it for any Conversions API addon [1]. OpenAI Ads has a separate click-ID fallback from the same release that captures the ChatGPT click identifier from the landing URL [1].

The campaign-capture fallback is part of the PRO edition of the Magento 2 Google Analytics 4 extension from v1.17.4 and needs Measurement Protocol tracking enabled [1]. The current release is v1.17.5, September 16, 2026; edition differences are in GA4 Standard vs PRO on Magento 2.

Sources

1. WeltPixel Google Analytics 4 User Guide and Change Log, v1.17.5, September 16, 2026, retrieved September 29, 2026, https://docs.weltpixel.com/GA4/User-Guide-WeltPixel-Google-Analytics-4.html
2. magento/magento2, app/code/Magento/PageCache/etc/varnish6.vcl at release tags 2.4.6, 2.4.7, 2.4.8 and 2.4.9, GitHub, retrieved September 28-29, 2026, https://github.com/magento/magento2/blob/2.4.9/app/code/Magento/PageCache/etc/varnish6.vcl
3. Magento Open Source 2.4.8 release notes (AC-13279, AC-10738, ACP2E-2102), Adobe Experience League, page last updated March 30, 2026, retrieved September 29, 2026, https://experienceleague.adobe.com/en/docs/commerce-operations/release/notes/magento-open-source/2-4-8
4. Configure Commerce to use Varnish, Adobe Commerce Configuration Guide, retrieved September 28, 2026, https://experienceleague.adobe.com/en/docs/commerce-operations/configuration-guide/cache/varnish/configure-varnish-commerce
5. magento/magento2, GenerateVclCommand.php at release tag 2.4.9, GitHub, retrieved September 29, 2026, https://github.com/magento/magento2/blob/2.4.9/app/code/Magento/PageCache/Console/Command/GenerateVclCommand.php
6. magento/magento2, lib/internal/Magento/Framework/App/PageCache/Identifier.php and Kernel.php, compared at release tags 2.4.6, 2.4.7, 2.4.8 and 2.4.9, GitHub, retrieved September 28-29, 2026, https://github.com/magento/magento2/blob/2.4.9/lib/internal/Magento/Framework/App/PageCache/Identifier.php
7. Measurement Protocol events reference, Google Analytics developer documentation, page last updated September 16, 2026, retrieved September 28, 2026, https://developers.google.com/analytics/devguides/collection/protocol/ga4/reference/events#campaign_details
8. Campaigns and traffic sources, Google Analytics Help, retrieved September 28, 2026, https://support.google.com/analytics/answer/11242841?hl=en
9. Measurement Protocol overview, Google Analytics developer documentation, page last updated June 8, 2026, retrieved September 28, 2026, https://developers.google.com/analytics/devguides/collection/protocol/ga4
10. Scopes of traffic-source dimensions, Google Analytics Help, retrieved September 28, 2026, https://support.google.com/analytics/answer/11080067?hl=en
11. Auto-tagging, Google Ads Help, retrieved September 28, 2026, https://support.google.com/google-ads/answer/3095550?hl=en
12. Intelligent Tracking Prevention 2.1, WebKit blog, February 2019, retrieved September 28, 2026, https://webkit.org/blog/8613/intelligent-tracking-prevention-2-1/