VTC/EVC Support
What Is VTC/EVC Support?
"VTC/EVC Support" is a parent-level toggle on Google Tag Settings that controls whether gtag.js continues executing on every page load, or is suppressed after the initial identity sync.
By default, gtag.js is loaded once to write Google's first-party cookies, then suppressed on subsequent page loads, with measurement delivered server-to-server. That is fully sufficient for click-through conversions, because a click leaves a click identifier (GCLID, GBRAID, WBRAID) in the landing page URL that is captured and forwarded.
View-through and engaged-view conversions work differently. No click occurs, so no click identifier is ever present. Google attributes these by mapping the on-site conversion back to an earlier impression, which requires gtag.js running in the browser on each page load to refresh the conversion linker cookie and complete a real-time handshake with Google's ad-serving domains. A server-side pipeline operates outside the browser security context and cannot perform that handshake, so suppressing the tag degrades VTC and EVC attribution.
Turning VTC/EVC Support on keeps the tag active on every page, restoring that handshake at the cost of the performance benefit suppression provides.
Enabled vs. Not Enabled
| Capability | ON (gtag runs every page) | OFF (default — suppressed after sync) |
|---|---|---|
| Click-through conversions (CTC) | Fully supported | Fully supported — click IDs captured from the URL and forwarded server-to-server |
| View-through conversions (VTC) | Supported — browser-side handshake with Google ad domains intact | Degraded to unsupported — no click ID exists to capture and no per-page handshake occurs |
| Engaged-view conversions (EVC) | Supported — browser-level identity mapping available | Degraded to unsupported |
| Conversion linker cookie maintenance | Refreshed on every page load, countering browser cookie deletion policies | Written at initial sync and refreshed only when the sync runs again |
| Enhanced Conversions matching | Higher — hashed customer data matched against live browser-state identifiers | Functional but more limited — hashed data passed server-side without the live browser cookie graph |
| Smart Bidding signal quality | Complete conversion feedback across click and non-click paths | Non-click conversions absent from the feedback loop, which can cause bidding to under-value display and video campaigns |
| Client-side script execution | gtag.js executes on every page load | Minimised — one load per sync cycle |
| Page performance impact | Comparable to a standard site-wide Google tag deployment | Lower — the primary reason suppression exists |
| Duplicate conversion risk | Requires deliberate configuration — see below | None — suppression prevents repeat client-side conversion firing |
Duplicate Conversions
With the tag active on every page, both the client-side tag and server-side delivery can report the same conversion. Server-side delivery posture must be configured deliberately per destination so that exactly one path owns each conversion. Review this with your Customer Success Manager before enabling the toggle on a live pipeline.
Relationship to Google Tag Gateway
The two toggles are independent and address different problems. Gateway Mode changes where the script is served from; VTC/EVC Support changes whether it keeps running. Enabling Gateway Mode alone gives first-party script serving but leaves VTC and EVC degraded, because suppression still removes the per-page handshake. Both first-party serving and full non-click attribution require both toggles to be on.
Updated 2 days ago