A strong-subs source with weak revenue
Why one traffic source can show a healthy subscriber count and still trail sources with far fewer subs — and which number actually tells you the source is working.
Symptom
One traffic source's subscriber count looks strong, but its revenue trails far behind other sources that brought in fewer subs.
Cause
A $0 free-trial subscribe counts as a fan the instant it happens — core/fan/roster.py
classifies a fan's sub_type as trial the moment their earliest subscribe entry is either
typed trial or priced at 0, and that fan is counted in subs immediately, before they've
paid a single cent. A source that's mostly trial traffic can rack up a large subs number while
contributing close to nothing to revenue_net_cents, simply because none of those trials have
converted yet.
This isn't a bug in the count — subs genuinely means "distinct fans," and a trial fan is a
real fan. It's a read error to treat subs as a proxy for revenue quality on its own.
The number that actually tells you the source is healthy
Every source row also carries trial_subs (how many of its fans entered on a free trial) and
trial_to_paid (how many of those later produced real revenue). For judging whether a
subs-heavy, revenue-light source is actually working, read trial_to_paid relative to
trial_subs, not the headline subs count — a source with 400 subs and a 60% trial-to-paid
rate is healthier than one with 100 subs and a 10% rate, even though the second looks smaller on
the leaderboard's front page.
The full field definitions and where they appear in the leaderboard response are in Source attribution and the account-wide Trial → paid section of the attribution leaderboard read.
What's next
- Fan profile & signals — how a fan's lifecycle and value tier are computed once they do convert.
- Source attribution
Vault DLP export gates
A whole-folder read or export=true search trips a daily-quota + 2FA step-up gate before the read even runs — by design, not a bug.
Wall posting gotchas
Real failure modes in scheduling and delivering posts and stories — what each stuck status, cap, and disabled control actually means, sourced from the dispatcher's own logic.