Google Analytics 4 Skill

This one is brand new: a Google Analytics 4 skill created by howai, then cleaned up into an OpenClaw-ready skill so an agent can stop giving generic tracking advice and start behaving like a measurement architect.

The core opinion is simple: GA4 is not a tag snippet problem. GA4 is a data-contract problem.

A bad implementation asks: “Did the event fire?”
A useful implementation asks: “Does this event reliably answer the business question, survive reporting constraints, respect privacy, and reconcile with BigQuery?”

That is the difference this skill is designed to enforce.

What it does

The skill gives an agent a structured operating mode for GA4 work:

• measurement design
• event taxonomy
• ecommerce tracking
• consent and privacy checks
• custom dimensions and metrics
• DebugView / Realtime / BigQuery QA
• GA4 UI vs BigQuery reconciliation
• troubleshooting missing, duplicated, or misleading data

Instead of jumping straight to “add this event,” it starts with the analytical contract:

1. What business goal is this measuring?
2. Which funnel stage or user intent does it represent?
3. What exact event should fire, and under what condition?
4. Which parameters are required, optional, risky, or high-cardinality?
5. Where will the data be consumed: GA4 UI, Looker Studio, BigQuery, Ads, CRM, or warehouse?
6. How will the implementation be verified beyond DebugView?

That last point matters. DebugView is useful, but it is not the finish line. It confirms collection, not reporting availability, attribution correctness, consent behavior, deduplication, or BigQuery parity.

The stance

The skill is intentionally opinionated.

Use recommended GA4 events when they fit. Name custom events after user intent, not DOM mechanics. Use parameters for variants instead of exploding event names. Fire success events only after server-confirmed success. Keep PII out. Keep high-cardinality fields out of GA4 UI custom dimensions. Treat purchase deduplication, consent signals, and reporting identity as first-class checks, not edge cases.

In short: stop building analytics as vibes plus button clicks.

Why this exists

Most GA4 implementations fail quietly. The dashboard still loads. Events still appear. Someone can still screenshot a chart and declare victory.

But underneath, the measurement layer may be rotten:

• custom parameters were collected but never registered
• purchases double-fire on reload
• button-click events pretend to be confirmed outcomes
• payment gateways destroy attribution
• consent mode behavior is unverified
• BigQuery and the GA4 UI disagree for reasons nobody can explain
• high-cardinality dimensions turn useful reports into (other) soup

The skill exists to force the boring-but-important questions before those problems become executive dashboards, budget decisions, or fake certainty.

The useful mental model

Think of GA4 as three layers:

1. Collection layer

Did the browser, app, server, or GTM container send the right payload at the right moment?

2. Processing layer

Did GA4 accept, transform, filter, model, threshold, or suppress the data?

3. Consumption layer

Can the intended user actually query or report on it in GA4 UI, Looker Studio, BigQuery, Ads, or the warehouse?

A tracking plan that only handles layer one is half-built. Maybe less.

What makes the skill practical

The skill includes reusable workflows for:

• event taxonomy design
• ecommerce QA
• consent/privacy review
• troubleshooting ladders
• GA4 BigQuery export reminders
• tracking-spec generation
• reusable SQL cookbook patterns

The agent is pushed to produce outputs that look like real implementation artifacts: event names, trigger conditions, parameter specs, custom dimension registration notes, QA ladders, and BigQuery checks.

That is the whole point. Not “analytics advice.” Implementation-grade measurement thinking.

Example: the kind of answer it should produce

For a lead form, the skill should avoid lazy button_click tracking and separate the journey properly:

• lead_form_start — user begins the form
• lead_form_submit_attempt — user attempts submission
• generate_lead — backend confirms successful lead creation
• lead_form_error — submission fails with a classified reason

That separation makes the funnel diagnosable. You can tell the difference between interest, friction, success, and failure. One generic click event cannot do that.

Status

The GA4 skill is now a working OpenClaw workspace skill. It is designed for practical analytics work where the output needs to be precise enough for implementation, QA, and stakeholder explanation.

Good analytics is not “more events.”
Good analytics is fewer lies.