Free tools I wish existed when I started.

GTM audit checklist

The audit I run in week one of every engagement. Order matters — inventory before judgment.

1. Inventory (find everything that fires)

• Export container JSON; list every tag, trigger, and variable
• Crawl key templates with the Network tab open — find tags injected outside GTM (hardcoded, CMS plugins, third-party embeds)
• Check for a second GTM container or legacy analytics snippets (UA, old pixels)
• Map every tag to an owner and a business purpose; no owner = removal candidate

2. Data layer

• Is there a documented data layer spec? (Usually: no. That's finding #1.)
• Are values pushed before GTM loads on every template?
• Consistent types? ("12.99" vs 12.99 breaks downstream)
• Ecommerce objects match GA4's schema, not UA's leftover format

3. Triggers & tags

• Duplicate firing: same event, two tags, or one tag on two overlapping triggers
• All-pages triggers on tags that should be scoped
• Paused tags older than 6 months — delete, don't hoard
• Naming convention exists and is followed (see the GA4 naming guide below)

4. Consent & privacy

• Do non-essential tags wait for consent state? Prove it with network logs (see consent checklist)
• Consent initialization fires before any tag decision
• PII in URLs, data layer, or custom dimensions (emails in query strings are everywhere)

5. QA & governance

• Who can publish? (More than 3 people = incidents waiting)
• Are versions named and described, or all "Untitled change"?
• Test plan for releases, or does everyone test in production?

GA4 event naming guide

Conventions that keep a property queryable two years and three teams later.

Rules

• snake_case, always. GA4 is case-sensitive: sign_up and Sign_Up are different events forever.
• object_action pattern: form_submit, video_play, search_results_view — sorts related events together in every report.
• Use GA4's recommended events where they exist (purchase, login, sign_up) — they unlock built-in reporting. Invent only when nothing fits.
• Never encode values in names. click_red_button_homepage is wrong; use cta_click + parameters cta_id, page_type.
• Parameters carry detail, events carry behavior. Ask: "will someone filter by this?" → parameter. "Is this a different user behavior?" → event.
• Registry doc first. No event ships until it's in a shared sheet: name, parameters, trigger condition, owner, example payload.

Why it matters downstream

Every event name becomes a value in BigQuery's event_name column. Inconsistent naming means every SQL query starts with a CASE WHEN cleanup block — forever. Naming is a data engineering decision disguised as a marketing one.

BigQuery SQL library for GA4

Copy-paste starting points for the GA4 export. Test on bigquery-public-data.ga4_obfuscated_sample_ecommerce.

Event deduplication

-- GA4 export can contain duplicate events; dedup on a composite key
SELECT * EXCEPT(rn) FROM (
  SELECT *, ROW_NUMBER() OVER (
    PARTITION BY user_pseudo_id, event_name, event_timestamp,
      (SELECT value.int_value FROM UNNEST(event_params)
       WHERE key = 'ga_session_id')
    ORDER BY event_timestamp
  ) AS rn
  FROM `project.dataset.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260101' AND '20260131'
) WHERE rn = 1;

Session table (the export doesn't have one)

SELECT
  user_pseudo_id,
  (SELECT value.int_value FROM UNNEST(event_params)
   WHERE key = 'ga_session_id') AS session_id,
  MIN(event_timestamp) AS session_start,
  MAX(event_timestamp) AS session_end,
  COUNTIF(event_name = 'page_view') AS pageviews,
  COUNTIF(event_name = 'purchase') AS purchases
FROM `project.dataset.events_*`
GROUP BY 1, 2;

Reconciliation vs the GA4 UI

-- When stakeholders say "BigQuery doesn't match GA4":
-- 1. Same date range in the property timezone, not UTC
-- 2. UI counts sessions via approximation (HLL); export is exact
-- 3. Consent Mode modeled data exists ONLY in the UI, never in export
SELECT COUNT(DISTINCT CONCAT(user_pseudo_id,
  (SELECT value.int_value FROM UNNEST(event_params)
   WHERE key = 'ga_session_id'))) AS sessions_exact
FROM `project.dataset.events_*`
WHERE _TABLE_SUFFIX = '20260115';

Power BI performance guide

Why your dashboard is slow — in the order you should check.

1. Model (80% of problems)

• Star schema, not one wide table and not snowflaked chains
• Remove columns you don't use — column count hurts more than row count in VertiPaq
• Avoid bi-directional relationships; they're a last resort, not a default
• Integer keys, not text; no high-cardinality columns (timestamps to the second, GUIDs) unless required

2. DAX

• Measures over calculated columns wherever possible
• Beware iterators (SUMX, FILTER) over large tables inside visuals
• Use variables (VAR) to stop recomputing the same expression
• Performance Analyzer → copy the slow query → optimize in DAX Studio

3. Visuals

• Every visual = at least one query. 30 visuals on a page = 30+ queries per interaction
• Top N + drill beats rendering 10,000 points nobody reads
• Slicers with high-cardinality fields re-query everything; use filter pane instead

4. Refresh & storage

• Incremental refresh for anything over ~5M rows
• Push transformations upstream to the warehouse (Dataform/dbt) — Power Query is the wrong place for heavy lifting
• Paginated reports for pixel-perfect operational output; don't force interactive visuals into that job

Consent mode checklist

Compliance you can prove with network logs — not promises.

Setup

• Consent initialization (default state: denied) fires before GTM tag decisions on every template
• CMP (Termly/OneTrust) is the only source of consent truth — one gate, not per-tag hacks
• All non-essential tags (GA4, Ads, Meta, LinkedIn) gated on consent state via blocking triggers or built-in consent checks
• Google tags use Consent Mode signals so denied states degrade gracefully
• Hardcoded tags outside GTM found and migrated or wrapped (they will exist — check)

Verification (the part everyone skips)

1. Fresh incognito session, EU geo (VPN) → open DevTools Network tab before loading the page
2. Filter requests by vendor domains: google-analytics.com, doubleclick.net, facebook.com, linkedin.com
3. Pre-consent: zero requests from gated vendors (Consent Mode pings to Google are cookieless and expected — know the difference)
4. Decline consent → still zero. Accept → tags fire once, with consent state attached
5. Repeat across templates (home, product, checkout, blog) and browsers; slow connections expose race conditions
6. Re-test after every GTM publish — compliance regresses silently

Evidence for legal

• Screenshot/HAR file of pre-consent network state per template
• Tag inventory with consent classification and owner
• Change log: what was gated, when, by whom