How and who implements tracking scripts?
Website Tracking, GTM & Cookie Consent: Standards and Ownership
Everything that tracks a website visitor — GTM, pixels, embedded scripts, chat and calculator widgets, the consent banner and the cookie declaration — is owned by the Development Director and executed by the Technical Team. Front-End Dev handles changes on the page itself. If you're not sure whose job a tracking task is, it goes to the technical team, and they pull in help as needed.
Scope: this covers how we implement and maintain tracking and consent. For whether a client needs a banner at all (Tier 1/2/3) and contract language, see Who needs Privacy and Consent Management on their website? Vye does not give legal advice; the client's counsel approves policy wording and accepts any remaining risk.
Who owns whatThe Technical Team is accountable for every tracking and consent outcome on every Vye-managed site. Front-End Dev is responsible for anything that changes in page code, templates or modules.
Technical Team (back-end dev) owns:
- Every GTM container Vye manages (access, naming, publishing, version notes)
- The consent platform (HubSpot cookie banner or other CMP) and its link to GTM
- Consent settings on every GTM tag
- Approving every new pixel, script, widget or embed before it goes live
- Each client's cookie inventory
- The consent audit at launch, after any tracking change, and quarterly on Tier 2/3 sites
- Training the team and keeping this article current
- Removing hardcoded scripts and inline tracking from pages, templates, modules and site header/footer HTML
- Adding the IDs, classes or data attributes GTM triggers need, instead of inline tracking code
- The global footer "Cookie settings" link
- Loading widgets the way the Technical Team specifies
- No pixels, tracking scripts or onclick tracking calls in page HTML, headers, footers, templates, modules or HubSpot "Site header HTML".
- Why: the HubSpot consent banner only controls HubSpot's own tracking and what GTM is told to hold back. It cannot block a script pasted straight onto a page.
- The only scripts allowed outside GTM are GTM itself, the CMP/banner, and scripts the Technical Team has logged as strictly necessary.
- Set the tag's consent requirements in GTM (Advanced Settings → Consent Settings): analytics_storage for analytics, ad_storage + ad_user_data + ad_personalization for ad and remarketing pixels.
- Google tags: confirm Google Consent Mode v2 is on (HubSpot banner setting or CMP) so a consent default is set before tags load.
- Do this even if the current setup already blocks everything on decline — it's what keeps the site correct if the CMP changes or the client adds category choices.
- Chat, calculators, scheduling, video and review embeds often set their own tracking cookies.
- Default: load them through GTM behind the right consent type, or use the vendor's consent option. If a widget is truly needed for the page to work, the Technical Team can class it as functional and log why.
- If the client chooses to leave it ungated, the AM gets that in writing and logs it in the client's Teamwork project. "Everyone knows" is not sign-off.
- The Technical Team keeps a cookie inventory per client: name, provider, purpose, category, duration.
- The AM sends it to the client to add to their privacy/cookie policy. Vye supplies the facts; the client's counsel approves the wording.
- Any new tag means an inventory update in the same task.
- A "Cookie settings" link sits in the global footer on every page, not just the policy page.
- On HubSpot, the link reopens the banner with: <a href="#" onclick="(window._hsp = window._hsp || []).push(['showBanner']); return false;">Cookie settings</a>
- No tracking task is marked complete without the testing checklist below. Note the GTM version number in the task.
- ☐ Banner shows on first visit (for the regions the site is set to show it in)
- ☐ Before any choice: DevTools Network tab shows no ad or analytics hits beyond what Consent Mode allows (cookieless pings only); Application → Cookies shows no tracking cookies
- ☐ Decline: reload and click around 2–3 pages; still no tracking hits or cookies, including from chat/calculator widgets
- ☐ Accept: the new tag fires in GTM Preview / Tag Assistant and its cookies appear
- ☐ GTM Preview → Consent tab shows the right default and update states
- ☐ View page source on the changed page: no hardcoded vendor scripts
- ☐ Footer "Cookie settings" link reopens the banner, and changing the choice takes effect
- ☐ Cookie inventory updated; GTM version note references the Teamwork task
What not to do:
- Removing a hardcoded pixel without rebuilding it in GTM first, so the client loses conversion data
- Publishing GTM without a version note, so no one can tell what changed or roll it back
- Updating tracking but not the cookie inventory
- Testing in a browser that already has consent cookies set
Useful Resources:
- Who needs Privacy and Consent Management on their website? — tiers, decision tree, contract language
- How to Use Google Tag Manager
- How do I create a tag in Google Tag Manager (GTM)?
Who is accountable for what:
RACI (R = does it, A = accountable, C = consulted, I = informed)
|
Task |
Technical Team |
Front-End Dev |
Paid / Digital |
AM / PM |
Client |
|
Decide if the site needs a banner (Tier 1/2/3) |
C |
— |
C |
R |
A |
|
Set up / change the consent banner (CMP) |
A, R |
C |
— |
I |
I |
|
Add or change a tag in GTM |
A, R |
— |
C |
I |
— |
|
Set consent settings on each GTM tag |
A, R |
— |
— |
— |
— |
|
Remove hardcoded scripts from pages/templates |
A |
R |
C |
I |
— |
|
Gate third-party widgets (chat, calculators, embeds) |
A, R |
R |
— |
I |
C |
|
Footer "Cookie settings" link |
A |
R |
— |
— |
— |
|
Build the cookie inventory |
A, R |
— |
C |
I |
— |
|
Update the privacy / cookie policy text |
C |
— |
— |
R |
A |
|
Sign off on accepted risk (e.g., an ungated widget) |
C |
— |
— |
R |
A |
|
Test and audit |
A, R |
C |
C |
I |
I |
The six standards
Every Vye-managed site follows these six standards, whatever its tier. They apply whether or not the site shows a banner today, so a later CMP change or new law doesn't force a rebuild.
- All tracking goes through GTM. Nothing is hardcoded.
- Every tag in GTM has consent settings.
- Third-party widgets are gated or formally accepted.
- Every cookie is declared.
- Visitors can change their mind.
- Every change is tested before it's closed.
- AM/PM creates a Teamwork task assigned to the Technical Team with: client, what's being added, vendor snippet or install docs, pages it needs to run on, and the deadline.
- Technical Team checks the client's tier. If the new tool moves them up a tier (e.g., first ad pixel on a Tier 1 site), flag it to the AM before going further.
- Technical Team decides how it loads: a GTM tag (default), a vendor widget gated in GTM, or — rarely — strictly necessary and logged.
- Technical Team builds the tag in GTM with consent settings, triggers and a clear name (Vendor – Type – Purpose). Paid/Digital is consulted on conversion events.
- Front-End Dev handles anything that has to change on the page itself (e.g., adding a data attribute or button ID a GTM trigger can use instead of an inline script).
- Technical Team runs the testing checklist in GTM Preview, then publishes with a version note that references the Teamwork task.
- Technical Team updates the cookie inventory; AM sends the updated declaration to the client.
- Technical Team closes the task with the GTM version number and test result in the comments.
New tracking goes live only after the Technical approves it, it's in GTM with consent settings, and it's in the cookie inventory.
No one adds a vendor snippet directly to HubSpot, WordPress or a template — even "just to test."
Fixing an existing site after an auditAn audit isn't done until every finding has an owner, a fix and a date. Run the web-js-consent-audit skill (Claude) to get the findings, then the Technical Team turns each one into a subtask using this table.
|
Finding |
Fix |
Does it |
Client action? |
|
Hardcoded pixel or onclick tracking on a page (e.g., StackAdapt on buttons) |
Rebuild as a GTM tag with a click trigger and consent settings, confirm it fires, then remove the hardcoded version so tracking isn't lost |
Technical Team rebuilds, Front-End Dev removes |
No |
|
GTM tags with no consent settings |
Add consent types to each tag (standard 2) |
Technical Team |
No |
|
Chat, calculator or other widget not gated |
Move load into GTM behind consent, or use vendor consent option; otherwise get written risk acceptance |
Technical Team + Front-End Dev |
Only if they want it ungated |
|
Cookies live but not in the policy |
Update the cookie inventory and send to client |
Technical Team → AM |
Yes — update policy |
|
Cookies in the policy but no longer live |
Remove from inventory; tell client which lines to delete |
Technical Team → AM |
Yes |
|
No way to reopen the banner site-wide |
Add "Cookie settings" link to global footer |
Front-End Dev |
No |
|
Banner not rendering, or tags firing before consent |
Check CMP settings and GTM consent wiring; retest |
Technical Team |
No |
Once the fixes are live, the Technical Team reruns the audit and attaches the before/after to the parent task. The AM then sends the client a short summary: what we fixed, what they need to approve, and any risk they've chosen to accept.
FAQ
"The banner blocks everything on decline anyway — why set consent types on each tag?" Because that only holds for today's setup. If the client switches CMPs, adds category choices, or runs Google Ads in regions that require Consent Mode v2, untagged tags either fire when they shouldn't or stop measuring entirely.
"Do we write the client's privacy policy?" No. We provide the cookie inventory and plain-language descriptions. The client's counsel approves and publishes the policy text.
"Isn't this a front-end task? / Isn't this a digital task?" It's a Technical Team task. They split out Front-End Dev subtasks for anything on the page and consult Paid/Digital on conversion events.
"The client says the chat widget is fine ungated." That's their call to make, in writing. The AM logs the approval in Teamwork and the Technical Team notes it in the cookie inventory.
"Can I add the pixel directly to the page just to test it?" No. Use GTM Preview mode. It tests without publishing and without touching the site.