7. The Standard Setups

GA4, Google Ads, Meta, LinkedIn, and TikTok via web GTM — the implementation patterns that hold up, the parameter mapping across platforms, and the pre-launch QA checklist.

Five platforms cover the overwhelming majority of commercial tracking work: GA4, Google Ads, Meta, LinkedIn, TikTok. This chapter is the implementation playbook — not screenshot-by-screenshot (UIs churn yearly; the platforms' own docs have screenshots) but the patterns that survive UI churn, plus the traps on each platform.

Four principles apply to every platform below; they're the previous three chapters condensed:

  1. Events come from the application as data layer pushes in one schema (Chapter 5). Tags translate; they don't invent.
  2. Every ID lives in a Constant or Lookup Table variable — never pasted into tags directly.
  3. Every tag gets consent settings matching its purpose — analytics vs advertising storage (Chapter 17).
  4. Every conversion carries a unique transaction/event ID — it dedupes platform-side today and becomes the browser/server dedup key in Part 3.

GA4

Two tag types, one division of labor:

  • The Google tag (config) — fires on Initialization, all pages, carries the Measurement ID and shared settings. It establishes the GA4 client (_ga cookie, session) and by default sends the automatic page_view. On SPAs, disable that automatic pageview and send your own from the virtual_page_view event instead (Chapter 5) — one source of truth.
  • GA4 Event tags — one per meaningful event (purchase, generate_lead…), fired by Custom Event triggers, parameters from Data Layer Variables. For ecommerce events, enable the send ecommerce data from the data layer option instead of mapping item fields by hand — it reads the standard ecommerce object as-is.

Use Google tag settings variables (Configuration Settings / Event Settings) for parameters shared across many tags — user_id, environment flags — so they're defined once. Two platform-side facts that confuse newcomers: "conversions" are key events flagged in GA4 Admin (GTM has no say), and standard reports lag a day — verify in DebugView and Realtime (Chapter 8), never in tomorrow's reports.

Order matters here:

  1. Conversion Linker — first tag in any container that touches Google Ads. All pages, Initialization. It captures click IDs (gclid and friends) from landing URLs into first-party cookies (_gcl_* family) so a conversion days later can still be joined to the click — Chapter 2's attribution loop, implemented by one checkbox of a tag. No Linker, no reliable Ads attribution; it's the most consequential boring tag in GTM.
  2. Conversion Tracking tag per conversion action — Conversion ID + Label (both from Ads, both into Constants), value/currency from the data layer, and Transaction ID filled — it's the platform-side dedupe key against refreshes of the thank-you page.
  3. Remarketing tag (site-wide, optionally with dynamic remarketing parameters) if audiences are in play.

The strategic choice — native Ads conversion tags vs importing GA4 key events — is real: native tags fire faster (no GA4 processing delay), support enhanced conversions directly, and keep Ads independent of GA4 schema changes; imports are simpler to maintain. Our default: native tags for the revenue-critical actions, GA4 import for the long tail. Don't do both for the same action — double counting.

Enhanced conversions (hashed email/phone alongside the conversion — Chapter 2's PII matching) is a per-tag toggle plus a User-Provided Data variable. Wire it from day one if the data exists at conversion time; the server-side version is Chapter 14.

Meta Pixel

Meta ships no built-in GTM template; use the official gallery template (or the long-standing community ones) rather than raw Custom HTML where possible. Structure:

  • Base pixel — fbq('init', PIXEL_ID) + PageView, all pages, once per page, and set as the setup tag (Chapter 6 sequencing) for every Meta event tag. The base call is what creates/refreshes _fbp and captures fbclid → _fbc.
  • Event tags — Meta's standard events vocabulary (Purchase, Lead, AddToCart, InitiateCheckout…). Use standard names, not custom ones — optimization and reporting are built around them. Map value + currency from the ecommerce object.
  • event_id on every event — a unique ID per event instance. Today it dedupes pixel retries; in Chapter 13 it becomes the key that dedupes the browser pixel against the Conversions API. Generate it once in the data layer (e.g. order ID for purchases) so browser and server can share it. Retrofitting event_id later, mid-CAPI-migration, is miserable — wire it now.
  • Advanced matching — pass hashed email/phone in the base call when the user is identifiable. Directly moves Event Match Quality (Chapter 13).

LinkedIn Insight Tag

Two-piece setup, B2B staple:

  • Insight Tag — site-wide base (Partner ID), enables audiences and page-visit conversions.
  • Conversions — either URL-based (defined entirely in Campaign Manager: "thank-you page visited" — zero GTM work beyond the base tag) or event-specific conversions fired from GTM with a conversion ID. URL rules are fine for simple funnels; SPAs and modal-based forms need event conversions.

LinkedIn's matching leans on its logged-in member cookie plus the li_fat_id click ID — capture quality is largely out of your hands, which makes the CAPI variant (Chapter 14) more valuable than it first looks.

TikTok Pixel

Mirrors Meta almost one-to-one: base pixel (gallery template) creating _ttp and capturing ttclid, standard events (CompletePayment, SubmitForm…), value/currency mapping, advanced matching with hashed PII, and an event_id for future Events API dedup (Chapter 14). If you've internalized the Meta pattern, TikTok is a rename.

One push, five tags

The payoff of the single-schema discipline — one data layer purchase feeding every platform:

dataLayer fact            GA4              Google Ads        Meta              TikTok
─────────────────         ──────────────   ───────────────   ───────────────   ──────────────
event: "purchase"       → en=purchase    → conversion fire → ev=Purchase     → CompletePayment
ecommerce.value         → epn.value      → value           → cd[value]       → value
ecommerce.currency      → cu             → currency        → cd[currency]    → currency
ecommerce.transaction_id→ transaction_id → transaction ID  → event_id (+dedup)→ event_id
ecommerce.items[]       → items[]        → (dyn. remktg)   → contents[]      → contents[]

When a client asks "can we add platform X?", the honest answer in a setup like this is "one tag and three variable mappings" — because the data layer was built once, properly.

UTM discipline

Click IDs feed the ad platforms; UTMs feed GA4's attribution. The rules that keep both clean:

  • Tag every paid/owned campaign link with consistent, lowercase utm_source/medium/campaign (pick a convention; document it). GA4 groups channels by exact string matching — Facebook and facebook are two sources.
  • Never UTM internal links — an internal UTM restarts the session's attribution mid-visit, overwriting the real acquisition source.
  • Don't strip or rewrite query parameters in redirects between ad click and landing page — every marketing redirect is a place where gclid/fbclid go to die. Audit the redirect chain once per quarter.

Pre-launch QA checklist

Run this before publishing any meaningful change (the how of each step is Chapter 8):

  • Preview mode: every new/changed tag fires on its intended events — and doesn't fire anywhere else (spot-check 2–3 unrelated pages)
  • Variables resolve to real values on the firing event (no undefined)
  • Network tab: requests leave with the right payload (value, transaction_id/event_id, identifiers present)
  • Consent: tags behave correctly in both granted and denied states
  • Dedup keys present: GA4 transaction_id, Ads Transaction ID, Meta/TikTok event_id
  • SPA: no double pageview on initial load; events fire on repeat navigations
  • Safari spot-check (ITP is your biggest browser segment surprise)
  • Platform-side confirmation: GA4 DebugView, Meta Test Events, Ads diagnostics
  • Version published with a descriptive name — preview success on a draft workspace helps nobody in production

Now the skill that makes the checklist fast: Chapter 8 — Debugging GTM Web.