Install the "analytics-tracking-testing" agent skill from https://github.com/petrkindlmann/qa-skills/tree/main/skills/analytics-tracking-testing into .claude/skills/analytics-tracking-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "analytics-tracking-testing", then confirm the skill loads.
Claude Code copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Type this inside Codex. $skill-installer <name> installs a curated skill from openai/skills. The installer writes to $CODEX_HOME/skills (default ~/.codex/skills). Restart Codex if the skill does not show up.
skills CLI
$ npx skills add petrkindlmann/qa-skills --skill analytics-tracking-testing -a codex
Project install goes to .agents/skills/; add -g for ~/.codex/skills/.
Install the "analytics-tracking-testing" agent skill from https://github.com/petrkindlmann/qa-skills/tree/main/skills/analytics-tracking-testing into .agents/skills/analytics-tracking-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "analytics-tracking-testing", then confirm the skill loads.
Codex copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add petrkindlmann/qa-skills --skill analytics-tracking-testing -a cursor
Project install goes to .agents/skills/; add -g for ~/.cursor/skills/.
Install the "analytics-tracking-testing" agent skill from https://github.com/petrkindlmann/qa-skills/tree/main/skills/analytics-tracking-testing into .cursor/skills/analytics-tracking-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "analytics-tracking-testing", then confirm the skill loads.
Cursor copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
--scope user (default) or --scope workspace; --path is the subfolder of the repo that holds the skill; --consent skips the security confirmation prompt.
skills CLI
$ npx skills add petrkindlmann/qa-skills --skill analytics-tracking-testing -a gemini-cli
Project install goes to .agents/skills/; add -g for ~/.gemini/skills/.
Install the "analytics-tracking-testing" agent skill from https://github.com/petrkindlmann/qa-skills/tree/main/skills/analytics-tracking-testing into .gemini/skills/analytics-tracking-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "analytics-tracking-testing", then confirm the skill loads.
Gemini CLI copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Installs for Copilot at project scope by default; add --scope user for a personal install. Preview a skill first with gh skill preview. Needs GitHub CLI 2.90.0 or later (public preview).
skills CLI
$ npx skills add petrkindlmann/qa-skills --skill analytics-tracking-testing -a github-copilot
Project install goes to .agents/skills/; add -g for ~/.copilot/skills/.
Install the "analytics-tracking-testing" agent skill from https://github.com/petrkindlmann/qa-skills/tree/main/skills/analytics-tracking-testing into .github/skills/analytics-tracking-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "analytics-tracking-testing", then confirm the skill loads.
GitHub Copilot copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
skills CLI
$ npx skills add petrkindlmann/qa-skills --skill analytics-tracking-testing -a opencode
OpenCode documents no install command of its own. Project install goes to .agents/skills/; add -g for ~/.config/opencode/skills/.
Install the "analytics-tracking-testing" agent skill from https://github.com/petrkindlmann/qa-skills/tree/main/skills/analytics-tracking-testing into .opencode/skills/analytics-tracking-testing/ in this project. Copy the whole folder (SKILL.md and every file beside it), keep the folder name "analytics-tracking-testing", then confirm the skill loads.
OpenCode copies the folder itself, the same result as the manual copy. Check what it changed before you commit it.
Facts
Skill name
analytics-tracking-testing
GitHub stars
168
Token cost
~6.2k tokens
SKILL.md length
2,805 words
Files
9 (incl. references)
Skills in repo
45
Repo updated
First seen
Licence
MIT
At a glance
Validate that analytics and marketing tracking fire CORRECTLY: GA4/GTM dataLayer events, Meta/TikTok/LinkedIn pixels, and ad-tech tags.
Works in 8 steps: Asserting window.dataLayer (or the DOM)… → waitForTimeout to "wait for the event to… → Asserting only the event name → …
: test analytics tracking
SKILL.md covers Quick Route, Discovery Questions, Core Principles and Intercepting GA4 Beacons, plus 13 more sections
Calls npx; reaches google-analytics.com
What it does
Analytics Tracking Testing is an agent skill from petrkindlmann/qa-skills. Validate that analytics and marketing tracking fire CORRECTLY: GA4/GTM dataLayer events, Meta/TikTok/LinkedIn pixels, and ad-tech tags. Covers building a tracking plan as the contract, intercepting collect-endpoint beacons and dataLayer.push in Playwright, asserting event name + params + values + timing + de-duplication, Consent Mode v2 gating, CI regression gating, and news-media events (article-view, scroll-depth, paywall). Use when: "test analytics tracking," "GA4 event test," "verify the pixel fires,"…
Its SKILL.md is about 6.2k tokens, which your agent loads only when the skill is triggered. The skill folder holds 9 other files, including reference files (for example `references/capture-fixture.md`, `references/ci-gating.md` and `references/consent-mode.md`).
It sits in Testing & QA, covering Product analytics. It works with Google Analytics, LinkedIn, TikTok and Playwright. The repository describes itself as: 50 QA and test-automation skills for Claude Code, Codex, Cursor, and any Agent Skills Standard runtime. The licence is MIT.
When your agent uses it
: test analytics tracking
Verify the pixel fires
Meta Pixel dedup
Scroll-depth tracking test
Example prompts
“test analytics tracking,”
“GA4 event test,”
“verify the pixel fires,”
“/analytics-tracking-testing”
Workflow steps
8 steps, taken from the step headings in SKILL.md.
Read from SKILL.md and the folder at commit b3bb61b. It shows what the files ask for, not the result of running them.
Tool permissions
Pre-approves nothing: there is no allowed-tools line, so your agent's usual permission prompts apply.
From allowed-tools in the SKILL.md frontmatter.
Runs code
Shell commands in SKILL.md call:
npx
From the folder's file list and the shell code blocks in SKILL.md.
Network
Hosts in commands or code, which the agent is likely to contact:
google-analytics.com
From URLs in SKILL.md, links to its own repository left out.
Credentials
Names no API keys, tokens, secrets or passwords.
From names ending in _API_KEY, _TOKEN, _SECRET, _KEY or _PASSWORD in SKILL.md.
Context cost
Analytics Tracking Testing loads about 6.2k tokens when it runs, and up to ~12k if it reads all its reference files. Until then it costs about 230 tokens; SKILL.md has 2,805 words of instructions outside code blocks.
Always· name and description, kept in context so the agent knows when to use it
~230
When it runs· the whole SKILL.md, loaded when a task matches
~6.2k
With references· SKILL.md plus every file in references/, read only if the agent opens them
~12k
Estimates: characters ÷ 4, the usual rule of thumb; real counts depend on the model's tokenizer. Scripts and assets cost tokens only if the agent reads them.
Safety
Auto-check passed
The automated check found no risky patterns in SKILL.md.
Automated static check — not a guarantee. Review scripts before installing. It scans the text of SKILL.md for risky patterns (piping downloads into a shell, reading credential files, hidden Unicode, destructive commands); files beside SKILL.md are not scanned.
Download SKILL.mdSave it as .claude/skills/analytics-tracking-testing/SKILL.md (or your agent's skills folder). This skill also uses 8 other files; get the full folder from GitHub.
name
analytics-tracking-testing
description
Validate that analytics and marketing tracking fire CORRECTLY: GA4/GTM dataLayer events, Meta/TikTok/LinkedIn pixels, and ad-tech tags. Covers building a tracking plan as the contract, intercepting collect-endpoint beacons and dataLayer.push in Playwright, asserting event name + params + values + timing + de-duplication, Consent Mode v2 gating, CI regression gating, and news-media events (article-view, scroll-depth, paywall). Use when: "test analytics tracking," "GA4 event test," "verify the pixel fires," "dataLayer test," "tracking plan," "Meta Pixel dedup," "scroll-depth tracking test," "gate tracking in CI." Not for: whether tracking is ALLOWED to fire under consent law (GDPR/CMP) — that is compliance-testing; this skill checks the data is CORRECT. SEO meta tags / structured data — out of scope. Related: compliance-testing, playwright-automation, api-testing, qa-project-context.
license
MIT
metadata.author
kindlmann
metadata.version
1.0
metadata.category
specialized
<objective>
Tracking that "looks fine" in GA4 DebugView still drops events silently after a refactor, sends the wrong currency, or double-counts a purchase. Reading `window.dataLayer` or asserting the button is `toBeVisible()` proves nothing — the beacon may never leave the browser. This skill makes you intercept the real network beacon (`google-analytics.com/g/collect`, `facebook.com/tr`, `analytics.tiktok.com`, `px.ads.linkedin.com`), parse the event name and parameters out of the request, and assert them against a tracking plan that is a typed contract — then gate that contract in CI so a dropped event fails the build.
</objective>
First: check .agents/qa-project-context.md in the project root and skip anything it already answers (stack, tag manager, consent platform, target environments).
Which tracking destinations are live? GA4 (/g/collect), Meta Pixel (facebook.com/tr), TikTok (analytics.tiktok.com), LinkedIn (px.ads.linkedin.com), ad-tech tags — each has a different endpoint grammar, so the capture helper must know them all.
GTM or hardcoded gtag? GTM means the truth flows through window.dataLayer.push first, then GTM fires the beacon. You may assert at the push layer (input contract) AND the beacon (output contract); they are different tests.
Is there a tracking plan? If not, build one first — it is the contract everything else validates against. No plan means no objective pass/fail.
Consent platform and default consent state? Consent Mode v2 changes which beacons are even allowed to fire before consent. You need the CMP's accept/reject selectors to drive the test.
Client + server (CAPI) dedup in play? If purchases fire both client Pixel and server Conversions API, the event_id must match or you double-count. This is the correctness property, not "did fbq run."
News-media surface? Article pages add article-view, scroll-depth thresholds (25/50/75/100), and paywall-meter events that generic e-commerce plans miss.
Core Principles
Intercept the beacon, never trust the DOM or dataLayer alone. A button click that updates the DOM, or a dataLayer.push that GTM silently drops, leaves no GA4 hit. The only proof an event was sent is the outbound request to the collect endpoint. Assert on the network beacon's URL params; reading window.dataLayer via page.evaluate only proves the push happened, not that anything left the browser.
The tracking plan is a typed contract, not a comment. Every expected event lives in an external schema (JSON/YAML/TS interface) with required params and their types. Tests validate captured events against it and report missing params and type violations. Hardcoding one expected value inline asserts nothing about the other twenty params and rots on the first plan change.
De-duplication is the real correctness property for purchases. Checking that fbevents.js loaded or counting that fbq('track','Purchase') ran misses double-counting entirely. The property that matters: the browser Pixel and the server CAPI send the sameevent_id/eventID so Meta collapses them into one conversion.
Consent state is an input dimension, not a footnote. The same page produces different beacons before vs after consent. Test both: before consent → no beacon (or only a cookieless consent ping); after accept → full beacon. And the default must be denied for all four Consent Mode v2 signals — a granted default is a compliance bug AND makes the gating test meaningless.
Drive real user actions and wait on requests, never the clock. Scroll depth fires from actual scrolling (mouse.wheel, scrollIntoView, evaluate(scrollTo)), and you wait for the beacon with waitForRequest, not waitForTimeout. A fixed sleep is flaky and hides the very timing bug you should catch.
A tracking test that can't fail the build is theater. "Check it in GA4 DebugView" and "monitor production" never block a regression. The contract must run in CI and exit non-zero when an event drops or a required param goes missing.
Intercepting GA4 Beacons
GA4 (gtag.js / GTM) sends every event as an HTTP request to https://www.google-analytics.com/g/collect (region variants like region1.google-analytics.com/g/collect also occur). The event identity lives in the URL query string — you do not need the response.
GA4 /g/collect URL grammar you assert on:
Param
Meaning
Example
v=2
Measurement Protocol version (always 2 for GA4)
v=2
tid=G-XXXXXXX
Measurement ID
tid=G-ABC123
en=
Event name
en=add_to_cart
ep.<name>=
Event parameter, string type
ep.currency=USD
epn.<name>=
Event parameter, number type
epn.value=49.99
gcs= / gcd=
Consent state (see Consent Mode v2 section)
gcs=G111
The string/number split is load-bearing: GA4 types params automatically, so price arrives as epn.value (number) and currency as ep.currency (string). Asserting ep.value when it is really epn.value silently fails.
Intercept with page.waitForRequest (single expected event), page.on('request', ...) (collect many), or page.route (inspect then continue — never abort). Parse params from new URL(request.url()).searchParams. Then expect(...).toBe(...) / toEqual / toContain on the parsed values.
Minimal pattern (full version with helper in references/ga4-interception.md):
Never substitute page.evaluate(() => window.dataLayer) as the only assertion, toBeVisible() on the button, or waitForTimeout() to "let the beacon send." See references/ga4-interception.md for batched-event parsing (GA4 can pack multiple events into one POST body) and region-endpoint handling.
The Tracking Plan Is the Contract
A tracking plan is the source of truth: for every event, its name, required params, and each param's type. Keep it as a versioned file (tracking-plan.json / .yaml, or a TS interface/Zod schema) that both the app team and the tests import. Tests read the captured event and validate it against the plan — they do not hardcode expected values inline.
Validation produces a structured result, not a pass/fail boolean: list every missing required param and every type mismatch/violation. Example plan entry and validator:
Then expect(validateEvent(plan, 'add_to_cart', params)).toEqual([]). Asserting only the event name and ignoring params, or hardcoding expected values with no plan file, is the bare-agent shortcut this skill exists to replace. See references/tracking-plan.md for the YAML form, a Zod-typed plan, and a reusable assertAgainstPlan matcher.
Asserting dataLayer.push
When the question is specifically the GTM input — "is the right object pushed to dataLayer when the page loads?" — assert the push, not the GA4 beacon. This is the inverse of beacon interception: here the dataLayer push IS the target.
Capture pushes by wrapping window.dataLayer.push in addInitScriptbefore navigation so you record every push from page load, then read the recorded array via page.evaluate. Do notpage.route to mock the dataLayer (you would replace the thing under test), and do not read the GA4 network beacon instead (that is the output, a different contract).
For ecommerce, assert the nested shape, not just the event name — the ecommerce.items array and each item's item_id, price, currency:
Use find/filter/some to locate the event in the recorded pushes. Full helper in references/datalayer-capture.md.
Pixels and Server-Side Deduplication
Marketing pixels send their own beacons. Endpoints to intercept:
Destination
Endpoint
Event param
Dedup key
Meta Pixel
facebook.com/tr (also /tr?)
ev=PageView, ev=Purchase
eid / event_id
TikTok
analytics.tiktok.com
event in body/params
event_id
LinkedIn
px.ads.linkedin.com
conversion id
—
For Meta, asserting that connect.facebook.net/en_US/fbevents.js loaded, or that fbq('track','Purchase') ran, is a load/count check — it does not prove correctness. The correctness property for a Purchase that fires both client-side (Pixel) and server-side (Conversions API / CAPI) is deduplication: both must carry the sameevent_id so Meta merges them into one conversion instead of double-counting.
Test it: capture the browser facebook.com/tr beacon for ev=Purchase, read its event_id, and assert it equals the event_id your server sent to CAPI (from a mocked/captured server call or a known fixture value). Skeleton:
ts
const [pixel] = await Promise.all([
page.waitForRequest(r => r.url().includes('facebook.com/tr') && r.url().includes('ev=Purchase')),
completeCheckout(page),
]);
const clientEventId = new URL(pixel.url()).searchParams.get('eid'); // event_id on the wire
expect(clientEventId).toBe(serverCapiEventId); // deduplicates against the server CAPI event
See references/pixels-and-dedup.md for parsing TikTok/LinkedIn payloads and capturing the server CAPI call.
Consent Mode v2 Gating
Consent Mode v2 is the standard (mandatory four-signal model). As of the June 15 2026 change, Google acts only on the CMP-sent consent signal, so any two-signal answer is outdated. Test two states.
The four signals — all must default to denied:
Signal
Governs
ad_storage
Advertising cookies
analytics_storage
Analytics cookies
ad_user_data
Sending user data to Google for ads
ad_personalization
Personalized ads / remarketing
A granted default is a bug; omitting ad_user_data and ad_personalization (the v2 additions) is the outdated two-signal model and is wrong.
Before consent: no full beacon should fire — or only a cookieless consent ping. Use addInitScript to seed the gtag('consent', 'default', {...}) denied state before page scripts run, and assert no /g/collect request fires (or that the one that does carries a denied consent state).
After accept: click the CMP accept button; the full beacon now fires.
The consent state rides on the beacon URL:
gcs= — encodes ad_storage + analytics_storage only. G100 = both denied, G111 = both granted, G110/G101 = partial. Before consent you expect gcs=G100.
gcd= — encodes all four signals (string starting 11...); present on every hit to Google services.
Assert the denied default and the gcs=/gcd= value on the pre-consent beacon, then the granted state post-accept. Full test with addInitScript consent seeding and CMP click in references/consent-mode.md.
Whether the law permits a beacon under a given consent state is compliance-testing. This skill asserts that when a beacon fires, its data and consent params are correct.
News-Media Events
News and publisher sites have a tracking surface generic e-commerce plans miss. Cover all three:
article_view (or article-view) on article load — assert the beacon fires once with article metadata (id, section, author).
scroll-depth at the 25 / 50 / 75 / 100 percent thresholds — one event per bucket, driven by real scrolling.
paywall / meter — a paywall_hit (or meter) event when the free-article meter is exhausted.
Drive scroll with actual actions — mouse.wheel, element.scrollIntoView, or page.evaluate(() => window.scrollTo(...)) / scrollBy — and wait on the beacon (waitForRequest or your captured-events list), never waitForTimeout. Scrolling in fixed sleeps both flakes and masks threshold-timing bugs.
Full suite (article_view metadata, the four scroll buckets de-duplicated, and the paywall-meter event) in references/news-media.md.
Multi-Pixel Capture Fixture
Don't re-implement beacon capture in every test. Build one reusable Playwright fixture (test.extend) that listens with page.on('request', ...), matches all destination endpoints (GA4 /g/collect, facebook.com/tr, analytics.tiktok.com, px.ads.linkedin.com), parses each request's new URL(...).searchParams and postData(), and pushes a normalized { destination, eventName, params } onto a collected array tests assert against.
Critical trap: a capture helper must observe, so use page.on('request') (or page.route followed by route.continue()), neverpage.route(...).abort() — aborting blocks the very beacons you are trying to see. And it must capture pixels too, not GA4 only. Full fixture in references/capture-fixture.md.
Show full SKILL.md (1,092 more words)Show less
Regression-Gating in CI
The gate diffs captured events against the tracking-plan baseline and fails the build (non-zero exit) when a previously-firing event stops firing or a required param goes missing after a release. Structure it as a Playwright project that runs the journeys, captures every beacon via the fixture, and validates each against the plan; on any missing/dropped event the test expect fails, Playwright exits non-zero, and the GitHub Actions (or any CI) job goes red.
Do not make the gate "check GA4 DebugView manually," "only run against production traffic," or "warn but pass anyway" — none of those block a regression. The diff-against-baseline run belongs in PR CI, before merge. See references/ci-gating.md for the workflow YAML, the baseline-diff script, and how to surface missing-param failures in the job summary.
Buy vs Build
DIY Playwright interception is the right call for a bounded set of events on a few critical journeys gated in CI. It stops paying off at scale: hundreds of events across many domains, with a small team, and a need for continuous production / drift monitoring (catching a tag a marketer breaks in GTM at 2am, which a pre-merge CI gate never sees).
Dimension
Build (Playwright)
Buy
Few events, key journeys, pre-merge gate
Best fit
Overkill
Hundreds of events, many domains
Maintenance crushes you
Buy
Continuous 24/7 production drift monitoring
Out of scope for CI
Buy
Small team, high coverage demand
Build cost too high
Buy
Current live paid options worth naming:
Trackingplan — always-on/continuous monitoring of live traffic across web, mobile, and server-side; strongest when you need real-time drift detection rather than scheduled checks.
ObservePoint — scheduled scans/audits of journeys against a tracking plan; mature for periodic governance.
Don't recommend Segment Protocols as the only validation (it governs data flowing through Segment, not arbitrary client beacons), and never call Google Tag Assistant a CI gate — it is an interactive debug tool, not an automated pass/fail. Tie the decision to scale, many domains, maintenance burden, and continuous monitoring — the axes where DIY stops paying off.
Anti-Patterns
1. Asserting window.dataLayer (or the DOM) instead of the beacon
page.evaluate(() => window.dataLayer) proves a push happened, not that GA4 sent anything; toBeVisible() proves nothing about tracking. Intercept the /g/collect request and assert its en= and ep./epn. params. (The one exception: when the push itself is the contract — see dataLayer.push — but then never reach for the GA4 beacon instead.)
2. waitForTimeout to "wait for the event to fire"
A fixed sleep flakes and hides timing bugs. Wait on the request: page.waitForRequest(r => r.url().includes('/g/collect')).
3. Asserting only the event name
Name-only assertions pass while currency, value, and item_id are wrong. Validate every required param and its type against the tracking plan.
4. Hardcoding expected values inline with no plan file
There is no source of truth, so nothing catches a renamed param across the suite. Keep the plan external and validate against it.
5. Load/count checks for pixels (fbevents.js loaded, fbq ran)
Neither proves the conversion is correct or de-duplicated. For Purchase, assert the client and server event_id match.
6. Two-signal Consent Mode, or a granted default
Omitting ad_user_data and ad_personalization is the pre-2026 model. Default all four to denied and assert gcs=/gcd=.
7. page.route(...).abort() inside a capture helper
Aborting blocks the beacons you meant to observe. Use page.on('request') (or route.continue()).
8. A "gate" that can't fail the build
GA4 DebugView, production-only monitoring, or warn-but-pass do not stop a regression. Make CI exit non-zero on a dropped event or missing required param.
Verification
Smallest check first — prove the suite actually catches a regression, don't just trust a green run:
One event, one beacon:npx playwright test -g add_to_cart passes, and its trace (--trace on) shows the captured /g/collect request with en=add_to_cart. A green test with no matching request in the trace means you asserted on the wrong thing.
The gate can fail: rename a required param in a branch (e.g. value → amount in the app) and re-run the CI project — the build must exit non-zero with a missing/violation message. If it still passes, the gate is theater.
Consent default is denied: with the denied seed and no accept click, gcs=G100 (or no full beacon) on every captured hit; after accept, gcs=G111. A pre-consent G111 means the default is wrongly granted.
Dedup holds: the client eid from facebook.com/tr?ev=Purchase equals the server CAPI event_id for the same order. Different values mean Meta will double-count.
Done When
Each tracked event has a test that intercepts the real collect-endpoint beacon (/g/collect, facebook.com/tr, etc.) and parses en=/ev= plus params from searchParams/postData — no DOM-only or dataLayer-only assertions.
A versioned tracking plan file exists (JSON/YAML/TS) with required params and types; tests validate captured events against it and report missing/type violations, not just the event name.
Purchase (or any client+server event) has a deduplication assertion: client beacon event_id equals the server CAPI event_id.
A Consent Mode v2 test asserts all four signals default to denied, no full beacon fires before consent (or only a cookieless ping), the full beacon fires after accept, and gcs=/gcd= carry the expected consent state.
A reusable capture fixture (test.extend) collects GA4 + Meta + TikTok + LinkedIn beacons; no test re-implements capture and no capture helper calls route.abort().
News-media surfaces (if present) cover article_view, scroll-depth at 25/50/75/100 driven by real scroll actions, and a paywall/meter event — all using waitForRequest, no waitForTimeout.
A CI job runs the suite, diffs captured events against the tracking-plan baseline, and exits non-zero on a dropped event or missing required param — verified by a deliberately-broken tag turning the build red.
Related Skills
compliance-testing — Whether a beacon is allowed to fire under GDPR/CMP consent law, cookie-consent UI, and data-subject rights. This skill assumes the beacon is permitted and checks its data is correct; go there for the legality question.
playwright-automation — Page Object Model, fixtures, config, and the general E2E patterns this skill builds its interception on.
api-testing — Validating the server-side Conversions API / Measurement Protocol calls directly (request body, auth, response) when you need to assert the server half of deduplication.
qa-project-context — Stack, tag manager, consent platform, and target environments that this skill's discovery questions read first.
Reference Files (in references/)
ga4-interception.md — Full GA4 /g/collect interception helper, batched-event POST-body parsing, region-endpoint handling.
tracking-plan.md — JSON and YAML plan forms, a Zod-typed contract, and the reusable assertAgainstPlan matcher.
datalayer-capture.md — addInitScript dataLayer.push wrapper and ecommerce items[] shape assertions.
Analytics Tracking Testing next to the 5 skills that share the most tags, products or categories with it. Stars are the repository's; “used in” counts other GitHub owners with a copy.
Analytics Tracking Testing compared with similar skills
Skill
Stars
Used in
Tokens
Auto-check
Licence
Repo updated
Analytics Tracking Testing this skillpetrkindlmann/qa-skills
A skill your agent uses when raw data exists — Meta, Google, TikTok, GA4, Shopify, a CRM export, or a spreadsheet — and has to become insight and decisions: descriptive, diagnostic, predictive, and…
Dung khi co data tho tu Meta, TikTok, GA4, CRM hay Google Sheet va can bien thanh insight ra quyet dinh duoc — kem decision log ghi quyet dinh, can cu, tac dong ky vong va ngay review lai.
A skill your agent uses when the user wants to interact with TikTok or TikTok Studio — extract logged-in creator analytics for a post, list Studio posts, or download/extract the playable video from…
Scrapes public data from social, maps, search and review platforms by choosing from about a hundred Apify Actors and running them through the Apify CLI.
Goal-driven E2E testing where a browser agent (Playwright MCP / computer-use) reads a natural-language goal and explores the app via the accessibility tree to assert outcomes — no pre-written script.
Test for regulatory compliance: GDPR/CMP consent verification, Google Consent Mode v2, Global Privacy Control (GPC), CCPA/US state opt-out, EU AI Act Article 50 transparency, Better Ads Standards…
Validate that analytics and marketing tracking fire CORRECTLY: GA4/GTM dataLayer events, Meta/TikTok/LinkedIn pixels, and ad-tech tags. Analytics Tracking Testing is an agent skill from petrkindlmann/qa-skills. Validate that analytics and marketing tracking fire CORRECTLY: GA4/GTM dataLayer events, Meta/TikTok/LinkedIn pixels, and ad-tech tags.
When should I use Analytics Tracking Testing?
Analytics Tracking Testing fits situations like: : test analytics tracking; verify the pixel fires; meta Pixel dedup; scroll-depth tracking test.
How do I install Analytics Tracking Testing in Claude Code?
Run `npx skills add petrkindlmann/qa-skills --skill analytics-tracking-testing -a claude-code`. Or copy the skill folder (skills/analytics-tracking-testing in petrkindlmann/qa-skills) into .claude/skills/analytics-tracking-testing in your project. Claude Code loads it when a task matches its description.
How do I install Analytics Tracking Testing in Codex?
Run `npx skills add petrkindlmann/qa-skills --skill analytics-tracking-testing -a codex`. Or copy the skill folder (skills/analytics-tracking-testing in petrkindlmann/qa-skills) into .agents/skills/analytics-tracking-testing in your project. Codex loads it when a task matches its description.
Can I use Analytics Tracking Testing in Cursor, Gemini CLI or GitHub Copilot?
Cursor, Gemini CLI, GitHub Copilot and OpenCode also load SKILL.md folders. With the skills CLI, run `npx skills add petrkindlmann/qa-skills --skill analytics-tracking-testing -a cursor` (or -a gemini-cli, github-copilot or opencode for the others). To copy it by hand, put the folder in .cursor/skills/analytics-tracking-testing, .gemini/skills/analytics-tracking-testing, .github/skills/analytics-tracking-testing and .opencode/skills/analytics-tracking-testing in your project.
What does Analytics Tracking Testing need to run?
Going by SKILL.md and its folder, Analytics Tracking Testing needs the command-line tools its instructions call (npx).
Does Analytics Tracking Testing access the network?
SKILL.md names 1 domain. In commands or code: google-analytics.com; the agent is likely to contact it when it follows the instructions. This is read from the text; nothing was executed.
Is Analytics Tracking Testing safe to install?
Our automated static check of SKILL.md found no risky patterns, such as piping downloads into a shell, reading credential files or hidden Unicode. It is not a guarantee. Review the folder before installing.
What licence does Analytics Tracking Testing use?
Analytics Tracking Testing is published under the MIT licence (declared in SKILL.md). It allows redistribution, so the full SKILL.md is shown on this page.
How many tokens does Analytics Tracking Testing use?
About 6.2k tokens (SKILL.md is roughly 25k characters). Agents keep only the skill's name and description in context until a task matches; then they load SKILL.md in full. Its references folder adds about 6k tokens, read only when the agent opens those files.
What are the alternatives to Analytics Tracking Testing?
Skills that share tags, products or a category with Analytics Tracking Testing: 13 Data Analysis Global (minhnv0807/ai-business-skills, 610 stars), 13 Phan Tich Du Lieu (minhnv0807/ai-business-skills, 610 stars), Scrapecreators API (ScrapeCreators/social-media-research-skills, 3.4k stars) and Browsing Tiktok (browsing-skills/browsing-skills, 117 stars). The comparison table on this page puts their stars, adoption, token cost, safety result and licence side by side.
Who maintains Analytics Tracking Testing?
petrkindlmann (a GitHub user) maintains it in petrkindlmann/qa-skills, which has 168 GitHub stars. The repository holds 45 skills in this directory. The repository was last updated on June 10, 2026.
Source: petrkindlmann/qa-skills on GitHub. Facts on this page come from the repository at the commit we read; the author's words are quoted as theirs.