GTM destination: configurable data layer reset (resetDataLayer + per-key clear for self-loaded GTM) - #1363
Conversation
When `loadGtm` is enabled (default), Jitsu owns the data layer and keeps resetting the whole GTM data model between events via `this.reset()`. When `loadGtm === false` the client loads GTM itself and may keep its own persistent data-layer values that `reset()` would clobber. In that case, instead of resetting the entire model, push back only the keys Jitsu set this event with `null` values. This still prevents Jitsu event data from accumulating across events, but leaves data set outside Jitsu untouched. `event` is excluded from the clear (already consumed by the trigger), keeping the clearing push data-only so it doesn't fire event-based triggers. Builds on #1362 (the loadGtm option). Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
![jitsu-code-review[bot]](https://avatars.githubusercontent.com/in/3391383?s=60&v=4){kind=small}
There was a problem hiding this comment.
Reviewed libs/jitsu-js/src/destination-plugins/gtm.ts for correctness/regression risk around loadGtm behavior and dataLayer state handling.
I did not find actionable bugs or security issues in this change set. The branch between full reset() (Jitsu-managed GTM) and per-key null clearing (client-managed GTM) is coherent with the intended behavior, and key tracking is scoped to the event payload push.
Add an explicit `resetDataLayer` credential (default true) that controls whether Jitsu clears the data it pushed after each event. GTM merges every push into a single persistent data model, so without clearing, properties from one event leak into subsequent, unrelated events. When enabled (default), clearing behaves as before: a full `this.reset()` when Jitsu loads GTM, or a per-key null-clear of just Jitsu's keys when the client loads GTM (loadGtm === false). When disabled, Jitsu does no clearing and values persist across events — for integrators who rely on that or manage clearing themselves. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
absorbb
changed the title
There was a problem hiding this comment.
Reviewed the GTM destination plugin changes and the matching console schema update for resetDataLayer. The overall direction looks good; I left two inline questions on behavior changes in the loadGtm=false cleanup path (null-clearing semantics and leaving event uncleared) to make sure they are intentional and won’t cause downstream tag regressions.
There was a problem hiding this comment.
Reviewed the GTM destination changes in and the corresponding console schema update in .
I focused on behavior around and defaulting/branching, plus the user-facing config wiring. I did not find additional correctness, security, or regression issues beyond the existing open inline threads already on this PR.
There was a problem hiding this comment.
Reviewed the GTM destination plugin changes in libs/jitsu-js/src/destination-plugins/gtm.ts and the matching schema changes in webapps/console/lib/schema/destinations.tsx.
Focus areas: correctness and regressions in loadGtm=false behavior, resetDataLayer default/branching, and user-facing config wiring. No additional actionable bugs or security issues were found beyond the existing open inline threads already on this PR.
Address review feedback on the loadGtm=false clear path: - Clear keys to `undefined` instead of `null`, so data-layer variables read them as "missing" — matching the reset() path the previous behavior used (avoids a visible missing-vs-null difference for tags/variables). - Also clear `event` (previously skipped) so a stale event name doesn't linger in the model until the next push. Since the value becomes undefined, GTM still treats this as a data-only push and won't re-fire event-based triggers. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
There was a problem hiding this comment.
Reviewed libs/jitsu-js/src/destination-plugins/gtm.ts and webapps/console/lib/schema/destinations.tsx, with focus on the new GTM data-layer reset behavior for self-loaded GTM and the added destination credential surface.
I didn’t find additional actionable bugs, security issues, or correctness regressions in this range.
1 participant
Summary
Makes the GTM destination's between-event data-layer clearing configurable, and makes it safer when the client loads GTM itself.
GTM keeps a single merged data model for the page; every push deep-merges its keys in and they persist until overwritten or cleared. The plugin previously always cleared this with
this.reset()(wiping the entire model). This PR adds control over that.New option:
resetDataLayer(defaulttrue)true(default): Jitsu clears the data it pushed after each event so values don't leak into later, unrelated events. Backward-compatible.false: Jitsu does no clearing — values persist across events. For integrators who rely on persistence or manage clearing themselves.How clearing happens when enabled
loadGtmdefault): unchanged —this.reset()(Jitsu owns the data layer).loadGtm === false): instead of resetting everything, push back only the keys Jitsu set this event withnullvalues (Google's documented per-key clearing pattern). Jitsu event data still doesn't accumulate, but data the client set outside Jitsu is left intact.eventis excluded (already consumed by the trigger), keeping the push data-only so it won't fire event-based triggers.Changes
libs/jitsu-js/src/destination-plugins/gtm.ts— addresetDataLayerto credentials; gate clearing on it; per-key null-clear vs fullreset()based onloadGtm.webapps/console/lib/schema/destinations.tsx— expose theresetDataLayertoggle in the GTM destination config with a description of when to disable it.Testing notes
🤖 Generated with Claude Code