Kinaura: First-Party Analytics & Revenue Ledger

The problem

Kinaura is a relationship app. Two people each complete an assessment, then connect. The metrics that matter are about pairs, not single users: did an invite turn into a connection, did the pair keep using the app, did either person pay. Off-the-shelf analytics tools count page views and single-user funnels, and they send user data to a third party.

What I built

• One event writer. Every product event goes through a single idempotent function, so retries never double count.
• Identity stitching. Anonymous activity joins the user’s record the moment they sign up.
• Analytics views for activation, pair formation, the invite loop, churn, recurring revenue movement, lifetime value, and risk signals: more than 68 views, all inside the product database.
• An append-only revenue ledger with multi-touch attribution, including ad click IDs, so every dollar has a source.
• A UTM registry with a coverage check that flags any link sent without registered tracking.
• Deliverability-safe email that only sends to verified addresses and ignores machine-generated opens.
• A forecast model with three scenarios, so pricing and ad spend get tested against unit economics before any money is spent.

How it works

Everything lives in Postgres next to the product data, with no analytics vendor in the middle. Payments reconcile against Stripe, and the ledger is the single source for revenue reporting.

Stack

Supabase (Postgres, views, functions), Stripe, Resend, Cloudflare Pages.

Where it stands

Live since August 2026 and feeding Kinaura’s launch decisions.