Build a Custom Referral Tracking Dashboard for Digital Products
Most Australian creators selling e-books, online courses, presets or Notion templates rely on whatever analytics ship with Gumroad, Lemon Squeezy or a basic affiliate plugin. Those numbers rarely tell the full story — they show what sold, but not who drove the sale, which channel converted, or whether a promoter in Brisbane is actually pulling weight. A custom referral tracking dashboard closes that gap by capturing the full journey from a referral link to a paid customer, in a view you actually control.
This guide walks through the end-to-end build of a referral tracking system tailored to digital products. It covers the data model, the stack, event capture, dashboard design, Australian tax considerations, and a rollout plan that won't break under real traffic.
Why referrals still outperform paid ads for Aussie creators
Australia's creator economy has matured quickly, and Sydney-based coaches, Melbourne designers and Brisbane course creators are noticing the same pattern: a recommendation from a trusted voice converts better than a cold advert. CPMs on Meta and Google have risen sharply, while audiences have learned to skip anything labelled "sponsored". A promoter who genuinely uses your digital product carries weight paid ads cannot replicate, which makes a referral dashboard worth the engineering effort even at modest monthly volume.
Referrals also have a shorter feedback loop. With the right dashboard you can spot under-performing promoters within a week, double down on advocates, and adjust commission tiers without waiting on an agency report. The same data answers questions paid analytics never address, like whether your Telegram channel beats your Substack, or whether Australian customers share at a higher rate than buyers overseas.
If you already spend on paid ads, treat referral as a complementary channel. The two work well together when the dashboard captures both paid utm parameters and referral codes, letting you compare true CAC across every channel in one view.
Planning the data model before you touch any code
The first sketch of any referral tracking system should happen on a whiteboard, not in an IDE. At minimum you need four entities: users (your customers), promoters (people sharing links), referrals (the link plus metadata like campaign and landing page), and events (clicks, signups, purchases, refunds). Add a fifth, commissions, so payouts live independently from conversions and disputes get easier to resolve.
Australian details matter at this stage. Store currency as integer cents in AUD to avoid drift, and pin timestamps to UTC while letting the dashboard render in AEST or AEDT depending on daylight saving. Selling into New Zealand as well? Remember AEST differs from NZST by two hours during parts of the year, which affects how same-day promotions get reported.
Decide attribution windows up front — last-click, first-click, or multi-touch. For most digital product sellers, last-click within a 30-day window is the simplest rule and the easiest to defend if a promoter ever disputes a payout. Bake that rule into the referrals schema so you can revisit it later without rewriting queries.
Choosing the right tech stack for the build
The stack you pick affects shipping speed and maintenance cost. Here is a comparison of three common paths for a custom referral tracking dashboard.
| Stack | Best for | Australian hosting | Time to v1 | Maintenance |
|---|---|---|---|---|
| Next.js + Supabase (Postgres) | Solo creators wanting serverless | Supabase Sydney region | 2–3 weeks | Low, migrations handled |
| Laravel + MySQL on VPS | Small teams comfortable with PHP | Sydney or Melbourne VPS | 3–4 weeks | Medium, you own the server |
| Retool + Airtable + webhooks | Non-technical operators | Hosted overseas, fine for low traffic | About 1 week | Very low, limited customisation |
For most Australian digital product sellers, the Supabase option strikes the right balance. The Sydney region keeps page loads quick for local buyers, Row Level Security gives clean promoter-level access, and the SQL surface means you can pivot the schema quickly as commission rules evolve. Retool is tempting for speed, but once commission logic gets hairy — tiered rates, refunds, currency conversion — you outgrow it fast.
Whichever path you take, keep the event ingestion layer separate from the read layer. A dedicated events_raw table that flushes into an aggregated events_daily view keeps dashboard queries fast even as row counts climb into the millions.
Wiring up event capture without bloating pages
Event capture is the difference between a dashboard that earns trust and one that misleads. You need three capture points: the click on a referral link, the downstream conversion (signup, checkout completion, or both), and any refund or chargeback. Each should fire from server-side code where possible, because client-side pixels get blocked by Safari's ITP and increasingly aggressive Australian privacy extensions.
A typical implementation uses a short code in the URL, like ?ref=ADELAIDE10, which your edge function resolves into a promoter record and stores as a first-party cookie, or more durably as a server-side session hint tied to the visitor's email once they sign up. Persisting the referral across the conversion requires storing the referral_id at signup and copying it onto the order record at checkout.
Australian privacy law adds a real constraint here. The Privacy Act 1988 and the Australian Privacy Principles require you to collect personal information only when reasonably necessary, and to clearly tell customers why you are attributing the purchase to a promoter. A plain-English note saying "We share anonymised commission data with the promoter who referred you" is usually enough, but it must actually be true in the data you expose to the promoter dashboard.
Designing a dashboard that surfaces real signals
Aesthetics matter far less than signal density. Group the interface into four panels: a top-line panel for revenue attributed to referrals versus total revenue, a promoter leaderboard sorted by net commissionable sales, a campaign panel that breaks down which product, landing page or promo code drove each conversion, and a flagged-activity panel surfacing suspicious patterns such as self-referrals, repeated conversions from the same IP, or chargebacks.
Keep date pickers flexible but anchored to Australian time. Most analytics tools default to US-Pacific, which makes a Friday-night Australian promo look like a Thursday. Force the dashboard to render in Australian timezones, even when servers sit in UTC, and let users toggle between AEST, AEDT and UTC when debugging.
Colour and typography should reflect your wider brand. Canva-style dashboards read better than default Bootstrap, and small touches like always showing the AUD symbol next to every figure — rather than leaving currency implicit — cut down support tickets from promoters who are paid in their home currency and want to sanity-check conversions.
Calculating commissions under Australian tax rules
Once commissions start flowing, GST and withholding become real concerns. If you are registered for GST and your turnover is above the threshold (A$75,000), any commission you pay an Australian promoter is treated as a taxable supply in many cases, and the promoter may need to issue a tax invoice. Selling digital products cross-border adds another wrinkle, because GST applies to low-value imported goods under A$1,000 from 1 July 2018 onwards, and your dashboard needs to know which side of that line each transaction falls on.
For promoters based overseas, the ATO generally does not require you to withhold PAYG, but you should keep records of the country on file and consider any local obligations your promoter flags. Stripe and eWAY both export transaction-level CSVs that map cleanly to commission records, which makes monthly reconciliation far less painful than scraping a payment processor manually.
Build commission calculation as a deterministic function of the order's taxable amount, the promoter's tier rate, and any overriding campaign. Avoid hard-coded magic numbers in dashboard code. The first time the ATO asks for figures, or a promoter disputes a payout, you will be glad the rules live in one auditable place.
Rolling out, testing and scaling the system safely
Even a clean build benefits from a closed beta. Pick five to ten trusted promoters — perhaps a couple from your Melbourne mastermind, a Sydney course creator, and a few interstate advocates — and run them through the new dashboard for a single campaign. Capture their feedback on which fields they actually use, what is missing, and what is confusing. Most first-pass dashboards are over-built; a beta surfaces the 20% of features that deliver 80% of the value.
Set up alerting around the failure modes that hurt most. A webhook delivery failure, a database migration that drops a column, or a refund event that never propagates to the promoter ledger can quietly erode trust. Configure basic monitors for webhook success rates, row counts in the events table, and mismatches between Stripe payouts and commission totals, and review them weekly during the first quarter.
When the time comes to scale past a few hundred promoters, the same architecture holds up. Sharding becomes a real concern only past tens of thousands of daily events, and by that point revenue justifies a small backend investment. Until then, a dashboard on Supabase or a single Laravel server will serve an Australian digital product business well, with all the data you need to make confident referral decisions.
Ready to ship a referral program without rebuilding from scratch? VTU Script publishes free templates and video walkthroughs that pair with the architecture above, and the community forum is a good place to ask questions about edge cases unique to your stack. Browse the free SEO and analytics tools, or jump into the Q&A to swap notes with other creators running referral programs for digital products sold in Australia and beyond.