agentleFS
CaduS0uzaCaduS0uza/qa-supreme/skills/tracking-testing/SKILL.md

tracking-testing

Skill1 starsChanged 2 months agoMITView on GitHub

Test analytics and conversion tracking as a product feature — pixel fires, event payloads, consent gating, deduplication and server-side events. Use when the change touches GA4, Meta Pixel, GTM, conversion events, attribution, or when marketing reports numbers that do not match the product.

The file

We split this skill into the rules it gives an agent

5 rules. About 0 are common, 3 are distinctive, and 2 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈3

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Write the contract once, generate the tests from it (state-machine-testing style), and keep it next to the code:

    line 40
  2. Very specific:

    When the same conversion is sent from browser and server (Meta CAPI, GA4 Measurement Protocol), both must carry the same event_id — …

    line 57
  3. Distinctive:

    Before consent: no tracking request leaves at all.

    line 63
  4. Distinctive:

    After accept: events fire, with consent flags set.

    line 65
  5. Distinctive:

    After reject: still zero, and still zero after a reload — the classic bug is consent that resets.

    line 66

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Tracking Testing

Broken tracking does not throw. Nothing turns red. The product works perfectly and the business spends a month optimising against numbers that were never real — and by the time someone notices, the data for that month cannot be recovered.

For a company that buys traffic, this is not a nice-to-have: a conversion event that stops firing silently teaches the ad platform to optimise for the wrong people.

Assert on the request, not on the console

The only trustworthy oracle is the network call that leaves the browser:

const hits = []
await page.route('**/*', route => {
  const u = route.request().url()
  if (/google-analytics|analytics\.google|facebook\.com\/tr|googletagmanager/.test(u)) {
    hits.push({ url: u, body: route.request().postData(), method: route.request().method() })
  }
  route.continue()
})

await checkout(page)
const purchase = hits.find(h => /(\ben=purchase\b|"event":"purchase"|ev=Purchase)/.test(h.url + h.body))
expect(purchase, 'purchase event never left the browser').toBeTruthy()

Then assert the payload, not just that something fired: value, currency, transaction id, items, and the user/consent identifiers. A purchase with no value is worse than no event — it looks correct in the tag debugger and reports zero revenue.

The event contract

Write the contract once, generate the tests from it (state-machine-testing style), and keep it next to the code:

EventFires whenRequired fieldsMust not
view_itemproduct page rendereditem_id, value, currencyfire on a 404 page
add_to_cartitem addeditem_id, quantity, valuefire on quantity change to 0
begin_checkoutcheckout openedvalue, currency, itemsfire twice on a refresh
purchaseorder confirmedtransaction_id, value, currency, itemsfire on a declined payment
generate_leadform submitted successfullyform_id, valuefire on a validation error

The two rows that cost the most money: purchase on a declined payment (inflates conversions, poisons the ad platform's model) and duplicate purchase on refresh (same, doubled). Test both by name.

Deduplication and server-side

When the same conversion is sent from browser and server (Meta CAPI, GA4 Measurement Protocol), both must carry the same event_id — otherwise every conversion is counted twice. Assert the id matches across the two payloads in one test; nothing else catches this.

Consent

  • Before consent: no tracking request leaves at all. Assert zero matching hits, not "a hit with anonymised data".
  • After accept: events fire, with consent flags set.
  • After reject: still zero, and still zero after a reload — the classic bug is consent that resets.

This is also compliance: LGPD and GDPR make an ungated pixel a legal exposure, not just a data quality problem.

Guard against silent death

Tracking breaks by disappearing. Add a synthetic check that runs the money journey daily against production and fails when the purchase request stops arriving. A test that only runs in CI cannot catch a tag manager change someone made in a web console at 4pm on a Friday.

Done means

Per event: fired / not fired, payload asserted field by field, consent states covered, and the dedup id proven identical across browser and server.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.