Events
Purpose
What gets tracked as a discrete event — the raw material every KPI, funnel, and dashboard in this section is built from.
Product Events
waitlist_joined(role: business/creator)offer_created,offer_published,offer_paused,offer_endedapplication_submitted,application_approved,application_rejectedaffiliate_link_generatedattribution_click,attribution_cart_add,attribution_purchase(per 03. Database → attribution_events, reused directly rather than duplicated)sale_reported,sale_accepted,sale_rejected,sale_refundedpayout_triggered,payout_paid,payout_failedcreator_wallet_threshold_reached(the $50 crossing moment, amount TBD in PKR)
Where These Come From
Most of these map directly onto state transitions already defined in 01. Business Logic → State Machines and 03. Database's tables — this doc doesn't invent new tracking, it specifies that those same transitions should also emit an analytics event, not just update a database row.
Open Questions
- Whether a dedicated analytics event pipeline (e.g. a lightweight events table, or a third-party product-analytics tool) is used, or whether KPIs/Funnel Tracking are computed via direct queries against the core tables for MVP — recommend direct queries for MVP (no extra infrastructure), revisit only if the query load becomes a real burden on the primary database (ties to 02. Caching Strategy and 03. Indexing Strategy's stated "revisit if it becomes a bottleneck" philosophy)
Update (2026-08-23): Campaign → Offer and Sale-Status Vocabulary Reconciled
Campaign events renamed to Offer events: per 01. Domain Model's 2026-08-23 revision (Campaign merged into Offer, no separate entity), campaign_created/published/paused/ended are renamed offer_created/published/paused/ended above — this doc had never been swept for that rename until now.
Sale event renamed to match current lifecycle vocabulary: sale_verified is replaced with sale_reported and sale_accepted (plus sale_rejected), matching 01. State Machines' "reported → accepted / rejected" model — "verified" no longer applies, since SellVia trusts a merchant-reported sale rather than witnessing a payment it processed directly. sale_refunded is unchanged.