Measurement & Tracking Playbook

Analytics is not about collecting everything. It is about answering three questions for a business:

1. Where do good leads or sales come from?
2. Where do people fall out before they convert?
3. What do we fix next?

Everything we install serves those three questions. The method is the same for every client, only the "money action" changes:

A roofer's money action is a phone call. An ecommerce store's is a purchase. A B2B firm's is a demo request. Once we know the money action, the whole measurement plan follows.

Four tools, four distinct jobs. None of them replaces the others.

The data flow: the site pushes events into a dataLayer → GTM reads them → GTM routes them to GA4, Clarity, ad pixels, and anything else. So one install of GTM becomes the hub for all tracking, with no developer needed for each change.

site (dataLayer.push) → GTM → GA4 / Clarity / ad pixels / first-party storage

The loop in practice: GA4 tells you what (mobile conversion dropped). Clarity shows you why (you watch the mobile sessions). GTM is where you wire up whatever you need to measure next.

A repeatable checklist we apply to every site:

1. GTM installed in the site layout (the hub).
2. GA4 delivered through GTM (the Measurement ID lives in GTM's Google Tag, not hardcoded in the site).
3. Microsoft Clarity installed for heatmaps and session replay.
4. Cloudflare Web Analytics enabled (per-project toggle on Cloudflare Pages; it auto-injects on the next deploy).
5. Money action(s) defined and wired as a dataLayer event, then marked a key event in GA4.
6. First-party storage of leads in our own database, so the client owns the data, not just the ad platforms.
7. UTM discipline on every campaign link, so sources attribute correctly.
8. Search Console linked to GA4 for organic insight.
9. Consent + cookies handled (Section 6).
10. Service-account managed so PixelDrip runs GTM and GA4 as a service (Section 4).

We manage GTM and GA4 through their APIs using a Google service account that the client grants access to. This means tag changes, new pixels, conversions, and A/B tests happen programmatically, with no one clicking around in a dashboard.

• GTM can be fully driven by the Tag Manager API (create tags, triggers, variables, publish versions). Scopes: tagmanager.edit.containers, tagmanager.edit.containerversions, tagmanager.publish.
• GA4 config (key events, links) can be driven by the GA4 Admin API. Scope: analytics.edit.
• The service account is added as a user on the client's GTM container (Publish) and GA4 property (Editor).

Security (non-negotiable, per the Agentic Security Standard):

• Least privilege, one SA per capability. Do not pile Drive + GTM + GA4 onto one identity. The durable model is a dedicated analytics service account (e.g. lair-analytics) separate from other automation.
• Secrets stay in the execution layer. The SA key never enters an agent's context; it is read by the script at run time, never printed.
• Per-client isolation. Each client has their own GTM container and GA4 property; the SA's access is scoped per client and revocable.
• Approval-gate anything outbound or destructive. Publishing a container or changing a live tag is a privileged action: specialist builds, Rhea verifies, the owner approves.

• Define the money action(s) up front. One to a few actions that matter (lead form submit, call click, booking, purchase). Everything else measures the path to them.
• Fire an explicit event, do not rely on GA4's automatic form_submit (unreliable for fetch-submitted forms). Push a named event on success:

window.dataLayer = window.dataLayer || [];
window.dataLayer.push({ event: 'lead_submit', brand: 'client_name' });

• Catch it in GTM with a Custom Event trigger and a GA4 Event tag, then mark it a key event in GA4 so it counts as a conversion. Do not also mark form_submit (double-counting).
• Pass UTMs and referrer from the page into the event/storage so we can attribute by source.
• Store leads first-party. A small database table (we use Supabase) captures every lead with brand, UTM, timestamp, and user agent, so the client owns their pipeline data independent of any ad platform. The site's edge function inserts with a public anon key behind insert-only row-level security (no public read).

The landscape:

• EU (GDPR): opt-in. Consent required before setting analytics/ad cookies. This is where blocking banners come from.
• US states (Texas TDPSA, California CPRA, etc.): opt-out. You must disclose what you collect and offer a way to opt out, but you do not need a blocking wall before tracking.

Our default for US-local clients (lean, no bloated banner):

1. Google Consent Mode v2 set as the default before GTM loads. Analytics granted by default (US opt-out), ad signals denied until ads run.

<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('consent','default',{
    ad_storage:'denied', ad_user_data:'denied', ad_personalization:'denied',
    analytics_storage:'granted', functionality_storage:'granted', security_storage:'granted'
  });
</script>

2. A stored opt-out (localStorage flag) that flips analytics_storage to denied on load, gates non-Google tools (Clarity) directly, and is exposed via a footer "Your Privacy Choices" link.
3. A privacy policy that discloses the tools and data, with the opt-out and a contact for rights requests.
4. No blocking banner. Add a region-aware opt-in banner only if the client targets EU traffic.

Privacy policy sourcing. The legally durable answer is an attorney-maintained Termageddon policy per site (it auto-updates as laws change). For client rollout at scale, use Termageddon's agency/partner program, their policies are licensed per site, so one stretched subscription would void the legal backing on unlicensed sites. We keep clean, structurally-faithful interim policies until the licensed version is in place.

Reference implementation: Toledo Bend Living and Beds on the Bend (Consent Mode v2 + opt-out + scoped policy, all live and verified 2026-06-29).

When a client runs ads, the ad platform gives a pixel (a tag) that does two things: tracks conversions from ad clicks, and builds retargeting audiences (re-show ads to visitors who did not convert). Each pixel is just a GTM tag we add through the API.

• Google Ads: conversion tracking + remarketing. For local-service clients, call conversion tracking (which keywords drive calls) is the single highest-value pixel.
• Meta (Facebook/Instagram): the Meta pixel for conversions + retargeting; for ecommerce, the catalog feed enables dynamic product retargeting.
• Wire conversions through Consent Mode so ad cookies respect consent state.

The split is simple; the "who won" math is what needs rigor.

• The split: randomly bucket visitors (e.g. 50/50), keep them sticky with a cookie, fire an event tagging the variant. On Cloudflare we prefer an edge split (a Worker decides before render, no flicker) over client-side (which can flash the wrong version).
• The math: GA4 can show conversion rate by variant but does not compute statistical significance. For real experiments (auto-significance, sample size, concurrent tests) use an open-source, free-tier tool, PostHog or GrowthBook. Google Optimize is dead; do not use it.
• Prerequisite: real traffic. Low-traffic sites cannot reach significance, so A/B is a post-launch activity for sites with volume.

The unifying model from Section 1 applies to all. What changes is the money action and the funnel shape.

Local services (roofer, plumber, HVAC, fence, landscaping)

• Money action: phone call or quote request.
• Track: tel: call-clicks, form submits, "get a quote" clicks, directions/map clicks.
• Highest value: call tracking + knowing which source (Google Ads vs Google Business Profile vs organic) drove the call. Often worth a dynamic call-tracking number for true attribution.
• Watch: call-click rate, form completion rate, source-to-call attribution.
• This is most of PixelDrip's client base, a tight call + form + GBP/Ads-attribution model is the default.

Ecommerce (flagship example: Sherman Wildcat Cartridges, WooCommerce)

• Money action: purchase.
• Track the full GA4 ecommerce funnel: view_item → add_to_cart → begin_checkout → purchase, with item, value, and currency on each event.
• Watch: cart abandonment, product performance, revenue by source, average order value, return-customer rate.
• Pixels: Meta + Google Ads with the product catalog for dynamic retargeting of abandoned carts.
• WooCommerce specifics: use a GTM-WooCommerce data layer (a plugin like GTM4WP, or a custom dataLayer) so the ecommerce events fire with full product/order detail; route them through GTM to GA4 and the ad pixels. Server-side tagging is worth considering at high volume for data quality.
• The dashboard: a high-traffic store like SWC justifies a dedicated Looker Studio dashboard, revenue and orders by channel, funnel drop-off, top products, AOV trend, new vs returning, plus Search Console and Ads spend/ROAS side by side. This is the natural next build for Tyler Jacobs (Section 10).

Digital products / SaaS

• Money action: purchase or trial start.
• Track: landing → sales page → checkout → purchase, or free → paid activation; trial-to-paid rate.

Services / agencies / consultants

• Money action: lead form or consultation booking (e.g. Calendly).
• Longer cycle: lead quality over volume; gated content downloads, email signups; first-party CRM matters for lead-to-close attribution.

B2B

• Money action: demo request or qualified lead.
• Long, multi-touch journey: track pricing-page visits, whitepaper downloads, demo bookings; multi-session attribution matters; LinkedIn pixel + GA4 + CRM.

Sales funnel (coaching / info products)

• Money action: opt-in → nurture → sale → upsell.
• Every step is an event: opt-in rate, sales-page conversion, upsell take.

Measurement only matters if it drives decisions. What we deliver per client:

• GA4 explorations for funnels and path analysis.
• Looker Studio dashboards (free, connects GA4 + Search Console + Google Ads + Sheets) as the client-facing report, tailored to their money action: local-service = calls/forms by source; ecommerce = revenue/ROAS/funnel; B2B = leads/pipeline.
• The monthly strategy call is where the dashboard becomes action: review the numbers, watch the Clarity sessions behind them, decide the next fix. (Ties to the monthly strategy-call framework.)
• Honesty rule: report real numbers. Label benchmarks as benchmarks; never present an industry average as an achieved result.

1. Create GA4 (account → property per brand) and a GTM container; create a Clarity project.
2. Install GTM + Clarity in the site; enable Cloudflare Web Analytics.
3. Grant the analytics service account: GTM (Publish) + GA4 (Editor).
4. Via API: GA4 Google Tag + the money-action event tag + Custom Event trigger; publish. Mark the event a key event.
5. Define + wire the money action(s) as dataLayer events; add first-party storage.
6. Link GA4 ↔ Search Console; link GA4 ↔ Clarity.
7. Consent Mode v2 + opt-out + privacy policy.
8. UTM convention documented for the client's campaigns.
9. Build the Looker Studio dashboard for their money action.
10. Verify everything live (consent before GTM, beacon present, event fires, row stored, conversion registers in GA4 Realtime).

• Every conversion path is an event; every event has a source.
• The client owns their lead/sales data first-party.
• We can answer "where do good leads come from, where do they fall out, what to fix" on demand.
• Tag changes ship through the API in minutes, no client dashboard time.
• Privacy is handled lean and honestly.