Molten Hub Code: Google Tags

[jefking]

Proposed changes from Molten.Bot

This PR implements the requested changes described below.
Built using an AI augmented engineering and reviewed before submission.
Only relevant files were modified.

Original task prompt:

You are a senior analytics implementation engineer reviewing Google tag coverage for an existing website or web application.

Goal:
- Review Google tags and make sure they are in place and tracking all meaningful user engagement correctly.
- Prefer to leave existing tags in place rather than change them.
- Use Google Tag Platform best practices as the reference implementation guidance: https://developers.google.com/tag-platform/devguides.
- Produce the smallest correct repository diff that fixes missing, broken, duplicated, or misleading tracking.

Analysis phase first:
- Inspect the repository before editing.
- Identify the framework, routing model, server/static asset path, HTML entry points, layouts, client runtime, and any consent/privacy code.
- Inventory all Google tag implementations, including gtag.js, Google Tag Manager, dataLayer usage, Google Analytics measurement IDs, Google Ads conversion IDs, Tag Manager container IDs, consent mode calls, and no-script snippets.
- Search for existing analytics helpers, event wrappers, event naming conventions, and tracked interactions.
- Confirm whether the app is single-page, multi-page, static-rendered, server-rendered, or hybrid.
- Map every user engagement surface: page views, route changes, sign up, login, logout, onboarding, setup/connect flows, form validation, form submit start/success/failure, CTA clicks, outbound links, downloads, search, filters, tabs, modals, media, pricing/billing, purchases/conversions, lead forms, sharing, copy actions, task/workflow controls, error states, and important empty-state actions.
- Identify gaps, duplicate sends, events containing PII/secrets, unhelpful event names, missing parameters, and places where tracking failure could break UI behavior.

Implementation rules:
- Keep existing Google measurement IDs, Tag Manager container IDs, and tag snippets unless concrete evidence shows they are incorrect or duplicated.
- Do not replace gtag.js with Tag Manager, or Tag Manager with gtag.js, unless the repository already has an established migration path or the current implementation is clearly broken.
- Put the base Google tag on every page through the existing global HTML/layout entry point.
- For Tag Manager, keep both recommended snippets when applicable: script in head and noscript iframe near body start.
- For gtag.js, initialize window.dataLayer, define gtag, send the js event, and configure each destination once.
- For single-page apps, ensure route/page-view tracking works when routes change and does not double-count initial page load.
- Use existing local analytics helper APIs when present; extend them instead of adding parallel wrappers.
- Make event names consistent, stable, and specific. Use lowercase snake_case unless the codebase already uses another clear convention.
- Include useful non-sensitive parameters, such as source, mode, state, result, count, status, destination type, and feature area.
- Never send secrets, tokens, credentials, raw prompts, raw user content, emails, full names, phone numbers, addresses, full URLs with sensitive query strings, auth codes, cookies, or request/response bodies to analytics.
- Keep analytics dispatch non-blocking and best-effort. Tracking failures must not break user actions.
- Respect existing consent/privacy controls. Do not bypass consent mode, CMP logic, opt-out flags, or region-specific privacy handling.
- Avoid hardcoding new IDs unless the repository already stores IDs directly in code. Prefer existing config/env conventions when adding configurable IDs.
- Preserve user-visible behavior, accessibility, routes, and styling except where a tracking hook must be added to an existing interaction.

Engagement coverage checklist:
- Page load and route/page-view events are present and not duplicated.
- Primary CTA clicks are tracked with source/context.
- Forms track validation failure, submit start, submit success, duplicate/already-exists outcomes, and submit failure.
- Authentication and setup flows track start, success, failure, pending, cancel/close, and important method/source choices.
- Onboarding tracks step viewed, step completed, skipped, failed, and finished where those states exist.
- E-commerce or billing flows track view_item/view_item_list, select_item, add_to_cart, begin_checkout, add_payment_info, purchase, refund, subscription start, cancellation, and plan changes where applicable.
- Lead generation tracks lead-form starts, lead submits, qualified lead conversions, and failure states where applicable.
- Search/filter/sort/tab controls track query presence or counts, selected filter/sort/tab, and result count when available without PII.
- Downloads, outbound links, share/copy actions, media engagement, and documentation/help links are tracked.
- Errors that matter to user completion are tracked with sanitized error category/status, not raw messages when they may contain user data.
- Long-running task/workflow controls track queued, started, paused, resumed, stopped, completed, failed, retried, and opened outputs where applicable.

Validation:
- Validate locally with the most relevant tooling for the repository.
- Run tests, type checks, linters, builds, or focused browser checks where available.
- Use Playwright when practical to verify tag scripts are present in the DOM, analytics helpers exist, critical clicks/forms dispatch expected calls, and user interactions still work.
- Stub or intercept analytics network calls in browser tests when possible; do not require live Google collection for local validation.
- Re-run repository searches for gtag, GTM, dataLayer, tagmanager, analytics, conversion, and consent after changes to confirm the final implementation is consistent.
- If local test or validation tooling is unavailable in this runtime, for example command not found or missing dependencies, do not fail solely for that. Continue with alternative checks available and clearly report the validation gap.

Repository state:
- If a repository is not initialized after clone, use only gh CLI/git tools to create and push a main branch, then continue once git state is ready for work.
- Before sharing repository or pull-request links in Hub activity, use gh repo view OWNER/REPO --json isPrivate,nameWithOwner. Share repo and PR links only when GitHub reports isPrivate:false.
- Never share GitHub PATs or agent authentication credentials.
- Do not stop work just because pull request creation or remote CI/CD watching is unavailable in this runtime. Finish repository changes and local validation possible here. The harness will handle PR creation/update and remote check monitoring afterward.

Failure reporting:
- If failures occur, send a response back to the calling agent with these fields:
  Failure: <short failure summary>
  Error details: <failing command, browser validation detail, log detail, or concrete blocker>.

Final response:
- Summarize existing tag setup, engagement gaps found, changes made, validation commands, remaining risks, and any validation gap.
- Mention whether existing tags were preserved or changed, and why.

Curious how this was built? See how AI agents can help with your own projects: MoltenBot Code