| name | launch-analytics |
| version | 1.0.0 |
| description | Instrument a launch so the traffic spike is ATTRIBUTABLE, not a vanity number — one consistent UTM scheme
on every launch link, the conversion funnel (visit → signup → activation) wired into GA4 or the project's
existing analytics, and a validate + read-out step. Writes the UTM map + event plan to
`.ulpi/launch/<channel>/analytics.md`, parameterized by launch source (e.g. producthunt, hackernews) so
each link and report is correctly attributed. Shared measurement block of the launch-* family — invoked by
the per-platform runners (`launch-product-hunt`, `launch-hacker-news`, `launch-x`, `launch-linkedin`) to
close the loop, or run standalone. Measures durable outcomes (signups, activation), extends the real stack,
and NEVER puts PII in links or events. Use when a launch needs UTMs on every link and signup tracking, not
just an upvote count.
|
| allowed-tools | ["AskUserQuestion","Read","Write","Glob","Grep","Skill"] |
| argument-hint | [launch source + site, e.g. 'Product Hunt, our Next.js app with GA4'] |
| arguments | ["request"] |
| when_to_use | Use when a launch needs attribution — a UTM scheme for the links plus signup/activation tracking and a way
to read the spike. Examples: "add UTMs and tracking for my Product Hunt launch", "measure launch-day
signups", "wire GA4 events for the launch". Also invoked by the platform runners to tag links and
instrument conversions. Do NOT use for full product-analytics architecture or BI dashboards, and do NOT
write channel copy or outreach (redirect to `launch-copy` / `launch-outreach`) — this is launch-scoped
attribution only.
|
| effort | medium |
This skill instruments a launch for attribution. Non-negotiable rules:
- NO PII IN LINKS OR EVENTS. Never put emails, names, or identifiers in UTM parameters or event params.
Honor the project's consent/cookie/GDPR setup; if consent gating exists, don't bypass it.
- ONE CONSISTENT SCHEME. Define the UTM convention once (lowercase, documented), and use it for every
launch link across listing, outreach, and social — inconsistent tags fragment the report.
- DON'T BREAK EXISTING ANALYTICS. Detect the project's current stack first; extend it, never duplicate a
tag manager or double-fire
page_view. If GA4 isn't present, propose adding it — don't assume it.
- MEASURE DURABLE OUTCOMES. Track the funnel to signup and activation, not just visits/upvotes — the
launch's value is the emails and activated users it produces, not the vanity spike.
- VERIFY THE SNIPPET AGAINST CURRENT DOCS. GA4/gtag specifics change; confirm event syntax against the
current Google docs (use a docs/
find-docs skill) before pasting code, and adapt to the real stack.
- NEVER FABRICATE NUMBERS. Set up the measurement; report only what the tools actually show.
- WRITE THE KIT TO DISK at
.ulpi/launch/<channel>/analytics.md (create the directory if needed) — a
durable, paste-ready artifact, not advice that scrolls away.
launch-analytics
Inputs
$request: the launch source and the site/stack. When invoked by a launch skill, the caller passes the
channel (the hyphenated on-disk launch slug, e.g. product-hunt — this is the output dir), the
utm_source GA value (e.g. producthunt, no hyphen), and the target links. Standalone, ask for the
source, the site URL, and the current analytics stack (default the channel slug from the source).
Goal
A launch attribution kit written to .ulpi/launch/<channel>/analytics.md: a consistent UTM scheme, a
per-link UTM map, the GA4 (or existing-stack) event plan for the conversion funnel, the wiring snippets,
and a validation + read-out plan.
Step 0: Resolve source & stack
Determine the channel (output dir slug, e.g. product-hunt) and the utm_source GA value (e.g.
producthunt) — keep them distinct — and detect the current analytics: look for GA4/gtag.js, Google Tag
Manager, Plausible/Fathom/PostHog, or none. Success criteria: the channel, the utm_source, and the
real analytics stack are known.
Step 1: Define the UTM scheme & link map
Load references/utm-and-events.md. Set a single convention (lowercase, hyphenated) and produce the UTM
map — every launch link tagged by where it appears:
utm_source = the platform (e.g. producthunt)utm_medium = the placement (e.g. launch, maker-comment, email, social)utm_campaign = the launch (e.g. ph-launch-2026-06)utm_content = the specific link (e.g. x-thread, wave1-email, gallery-cta)
When invoked by a launch skill, hand the tagged links back to the caller (listing/outreach) so every link
is attributable; standalone, the tagged-link map in the written artifact is the deliverable for the user
to apply. Success criteria: one scheme, and a tagged link for every place a link appears.
Step 2: Map the funnel & events
Define the conversion funnel and the events that mark each step — typically page_view (automatic) →
sign_up → a key activation event (the first real value moment). Mark sign_up and activation as
conversions/key events in GA4. Success criteria: each funnel step has a named event and the
key ones are flagged as conversions.
Step 3: Wire it
Provide the tracking snippets for the real stack (GA4 gtag('event', …) or the equivalent), verified
against current docs, plus where to add them. Keep it minimal and consent-aware.
Success criteria: copy-paste wiring that fits the stack and doesn't double-fire.
Step 4: Validate & read out
Give a validation step (GA4 DebugView / Realtime to confirm events fire with the right params) and
a simple read-out plan: where to see launch-day traffic by utm_source, signups by source, and the
funnel conversion. Success criteria: the user can confirm tracking works before launch and read the
result after.
Step 5: Persist the kit
Write everything above to .ulpi/launch/<channel>/analytics.md (creating the directory if needed): the UTM
scheme + tagged-link map, the funnel/events plan, the wiring snippets, and the validate/read-out steps. The
<channel> is the hyphenated launch slug the caller passes (e.g. product-hunt), distinct from
utm_source. Success criteria: a durable, paste-ready analytics.md exists on disk.
Guardrails
- No PII in UTMs or event params; honor consent/GDPR.
- One documented scheme; lowercase; reused across every link.
- Extend the existing stack; don't double-instrument or break consent gating.
- Track signups/activation, not just visits; durable outcomes over vanity.
- Verify GA4/gtag syntax against current docs; adapt to the real stack.
- Report only real numbers; never fabricate.
When To Load References
references/utm-and-events.md — the UTM convention + per-link map, the GA4 event taxonomy and
conversion setup, the wiring snippet pattern, and validation (Steps 1–4).
Output Contract
Write / return .ulpi/launch/<channel>/analytics.md:
- the UTM scheme + a tagged-link map for every launch link
- the funnel and its events, with
sign_up/activation flagged as conversions
- the wiring snippet(s) for the real stack (verified against current docs)
- a validation step (DebugView/Realtime) and a read-out plan (traffic/signups by source)
