Revenue leak auditor

Revenue Leak Auditor

Use this skill when the user needs a strict, evidence-backed review of a monetized funnel, especially one using Stripe Checkout, Stripe Payment Links, static landing pages, AI-generated sites, agent workflows, or community traffic.

Operating Rules

• Treat payment truth, checkout recovery, analytics, and attribution as separate evidence streams.
• Do not claim revenue, conversion rate, visitor intent, or drop-off cause unless the data proves it.
• Never expose secrets, API keys, cookies, customer PII, or private community content in reports.
• Prefer source-code evidence over guesses. Use file paths, route names, and short snippets.
• If live Stripe/API credentials are unavailable, label payment verification as unverified, not zero.
• If browser or production analytics are unavailable, label visitor behavior as unobserved, not none.

Fast Path

1. Identify the funnel:

   • landing pages
   • intake forms
   • checkout buttons
   • backend checkout/session handlers
   • webhook handlers
   • thank-you pages
   • analytics snippets

2. Run the bundled scanner when filesystem access is available:

python3 revenue-leak-auditor/scripts/audit_revenue_leaks.py . --out revenue-leak-report.md

3. Inspect scanner output and manually verify the highest-severity findings.

4. Produce a report with:

   • verdict
   • severe leaks
   • missing observability
   • checkout confusion risks
   • recovery plan
   • implementation checklist

Audit Checklist

Checkout Capture

Flag as high severity when:

• page links directly to buy.stripe.com without a preceding buyer-capture form
• checkout URL lacks client_reference_id
• checkout URL lacks a source/UTM parameter
• form submission does not store or notify buyer contact details before redirect
• abandoned checkout cannot be matched to a person, business, source, or campaign

Analytics

Look for explicit events around:

• page view
• CTA click
• intake form view
• intake form submit
• checkout start
• payment success
• thank-you page view
• failed or abandoned checkout recovery

If the site only has a generic analytics snippet but no funnel events, report observability as partial.

Stripe Webhooks

Check whether webhook handlers distinguish:

• checkout.session.completed
• checkout.session.expired
• payment_intent.succeeded
• refunds or chargebacks when relevant

Check whether webhook events join back to:

• client_reference_id
• email/customer id
• source/campaign
• offer/product

CTA Clarity

Flag confusing buyer paths when:

• one page presents multiple prices without a clear offer distinction
• copy says consultation/diagnostic but button says checkout or buy now
• checkout starts before the buyer knows what happens after payment
• links send buyers to a generic payment page without context
• the offer page promises instant delivery but no delivery mechanism is visible

Recovery

A recoverable checkout path should have:

• buyer name or business
• email
• offer
• source/campaign
• timestamp
• checkout/session id or deterministic reference id
• a clear follow-up message template

Report Template

Use this structure:

# Revenue Leak Audit

## Verdict

One paragraph. State whether the funnel is ready for traffic, partially ready, or leaking.

## Severe Findings

| Severity | Finding | Evidence | Fix |
| --- | --- | --- | --- |

## Observability

- Visitor identity:
- CTA clicks:
- Checkout starts:
- Payments:
- Abandonment recovery:

## Checkout Path

Describe the exact buyer path from first page to payment and where attribution or buyer context is lost.

## Fix Plan

1. Highest-impact fix.
2. Second fix.
3. Third fix.

## Data Still Needed

List missing analytics, Stripe, CRM, or webhook evidence.

Implementation Guidance

Prefer a two-step paid path:

1. Buyer-capture/intake endpoint saves or emails name, business, email, offer, source, and deterministic reference id.
2. Redirect to Stripe with client_reference_id, prefilled_email or equivalent, and UTM/source parameters.

For static sites, a minimal implementation can be:

• HTML intake page
• serverless /api/checkout-intent handler
• notification email or CRM insert
• Stripe Payment Link redirect with query parameters
• thank-you page event
• webhook event join by reference id

Done Criteria

The funnel is not considered fixed until:

• no critical direct Stripe links bypass buyer capture
• every payment CTA preserves source attribution
• checkout starts and payments can be counted separately
• abandoned checkout intent is recoverable
• the operator can answer: who visited, what CTA they clicked, what they submitted, whether they reached Stripe, whether they paid, and what follow-up is needed