kestra-io / kestra-io/docs

gtm.trackEvent() never reaches the dataLayer: vue-gtm plugin is initialized disabled

Open
#5,567 0 comments 0 reactions 0 assignees View on GitHub
area/analytics kind/website
Dominant language
Astro
Stars
155
Forks
177
Avg merge
1d 20m
Merged PRs (30d)
192

Description

Split out of the review on [#5185](https://github.com/kestra-io/docs/pull/5185), where it was raised as out of scope. Pre-existing on `main`.

### Problem

`src/vue-setup.ts` initializes the vue-gtm plugin with `enabled: false`, and nothing ever calls `gtm.enable(true)`:

```
$ grep -rn '\.enable(' src/
(no matches)
```

`useGtm().trackEvent()` drops the event when the plugin is disabled, so every call site below is a no-op regardless of consent state:

| Call site | Event |
|---|---|
| `src/components/contact/Header.vue:213` | `contact_form_submission` |
| `src/components/cloud/Form.vue:181` | `cloud_form` |
| `src/components/preview-access/Features.vue:226` | `cloud_form` |
| `src/components/early-adopter-program/Form.vue:229` | `early_adopter_form` |
| `src/components/partners/BecomeAPartner.vue:358` | `partner_form_submission` |
| `src/components/airflow-2-eol-whitepaper/DownloadForm.vue:174` | whitepaper download |
| `src/components/resources/ResourceCtaPair.vue:145` | per-CTA event |
| `src/utils/newsletterSubmit.js:41` | `newsletter_form` |
| `src/utils/identify.js:6` | `identify` |
| `src/utils/hubspot.ts:50` | HubSpot form events |

`bookdemo_form` is the only one that lands, because `src/components/demo/Meeting.vue:150` pushes to `window.dataLayer` directly and documents the workaround in a comment.

The plugin is disabled deliberately: GTM is loaded by `src/scripts/cookieconsent.ts`, not by vue-gtm, so letting the plugin inject the container would load it twice. The `dataLayer` push side of the plugin was disabled along with the loading side.

### Effect

No form conversion except book-a-demo reaches GTM, so nothing downstream of GTM (Ads conversions, funnel reporting) can see them. This caps any GTM-side conversion work until it is fixed, and it is unrelated to consent: the events are dropped before consent is consulted.

### Options

1. `enable(true)` with `loadScript: false` once the container is loaded by `cookieconsent.ts`, so the plugin only feeds the `dataLayer`. Closest to the current intent, needs a check that vue-gtm does not re-inject and that ordering against the consent default is right.
2. Drop vue-gtm and push to `window.dataLayer` directly everywhere, following what `Meeting.vue` already does. Removes a dependency and the double-load question, and touches 10 call sites.
3. Small wrapper in `src/utils/` over `window.dataLayer.push`, with the call sites switched to it. Same as option 2 but keeps one place to change.

Verification for any of them is GTM Preview: submit each form and confirm the event appears in the Tag Assistant timeline. Note that previews cannot be used for this, since `deploy.yml` sets `PREVIEW=true` on every non-`main` branch and `layout.astro` omits the analytics scripts in that case. A local production build (`astro build` + `wrangler dev`) is the way to test, which also means it hits the real container.

Contributor guide

Open the contributing guide

Research direction

Start with src/vue-setup.ts and src/scripts/cookieconsent.ts to understand how vue-gtm and the consent-loaded container are initialized, then compare the listed call sites with the direct dataLayer push in src/components/demo/Meeting.vue. Evaluate the three options, preserving consent and avoiding duplicate loading; verify every form event in a local production build with GTM Preview and Tag Assistant.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, typescript
Domain
analytics, frontend
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.