What members see

The seven affiliate screens a member gets, the two referral link formats and how each one is tracked, what the dashboard numbers actually measure, and which marketing features are cosmetic.

5 min readUpdated 3 August 2026members, referral link, dashboard, network, qr

Once the extension is enabled, signed-in members get Services → Affiliate Program in the site header, leading to seven screens under /affiliate. The landing page is public; everything else needs a session.

Screen Path What it is
Home /affiliate Public pitch page with live programme statistics
Dashboard /affiliate/dashboard The member's own performance
Network /affiliate/network The downline tree
Referrals /affiliate/referral A list of people they introduced
Link Generator /affiliate/referral-generator Links, QR codes and share buttons
Rewards /affiliate/reward Earned commissions and the Claim button
Commission Rates /affiliate/condition What the programme pays

Home — the public pitch

/affiliate is reachable without signing in, and it is built from live data rather than static copy. It shows the number of affiliates who have made at least one referral, the total ever paid out in claimed rewards, an average monthly earning figure, the proportion of referrals that are ACTIVE, the average number of referrals per affiliate, and the top earner's total.

Below that: your active commission rules, the top five affiliates by lifetime earnings (avatar and join date only — no names), and the ten most recent rewards from the last 30 days.

Every number is computed from your own data. On day one the page reads "0 total paid out" and shows no top affiliates. If you are launching publicly, consider seeding the programme with a soft launch before you point advertising at this page.

The commission rules shown here are filtered by which addons you have enabled, so nobody is offered an NFT commission on a platform without the NFT addon. The filter on this page is slightly stricter than on the signed-in Commission Rates page — spot-trade commissions are hidden here unless the Ecosystem addon is enabled, but shown there. If your spot markets run through a connected exchange rather than Ecosystem, that rule will be missing from the public page.

Dashboard

The member's own numbers, with a period selector of 1, 3, 6 or 12 months. Each figure is shown against the equivalent previous period, so "last 3 months" compares against the 3 months before that.

Figure What it counts
Total referrals All of the member's referral records
Active referrals Those with status ACTIVE
Pending referrals Those awaiting approval
Total earnings The sum of every reward they have earned, claimed or not
Conversion rate Rewards created in the period ÷ referrals gained in the period
Period growth Referral count this period against the previous one

Underneath: the referrals gained in the selected period, recent rewards, and a monthly earnings chart.

Two things to be ready to explain. Conversion rate is not a click-through rate — nothing counts link clicks anywhere in the product, so it is a ratio of rewards to new referrals and can exceed 100% when existing referrals keep earning. Total earnings includes unclaimed rewards, so it will not match the member's wallet balance.

When Require Approval is on, the dashboard's referral list shows only ACTIVE referrals, while the counters still include pending ones. That is intentional but it does prompt questions.

If your KYC levels gate the affiliate_mlm feature (Affiliate Program in the level builder), this screen shows a verification notice instead of the data. That gate is presentational — it hides the dashboard, it does not stop commissions accruing. The gate that actually blocks money is withdraw_affiliate, enforced at claim time.

Network

A visualisation of the downline: the member at the root, their referrals beneath, and their referrals' referrals below that, down to your configured level count. It also shows who introduced them, and their lifetime reward total.

What it renders depends on your structure setting — a flat list of direct referrals under DIRECT, the sponsor hierarchy under UNILEVEL, the binary node tree under BINARY. Binary depth is capped at 10 regardless of your level setting, so very deep trees render a slice rather than timing out.

Under BINARY, a member with no referral record of their own gets a self-referral row and a root tree node created the first time they view this page. That row occupies their one and only "who referred me" slot — after it exists, that member can never be recorded as somebody else's referral.

It is how legacy accounts get retro-fitted into the tree, and it is harmless for members who genuinely have no sponsor. It is a problem if you were planning to import historical sponsor relationships later. Import first, switch structure second.

Referrals

A paginated list of the people the member introduced: name, email, avatar and sign-up date, newest first. Page size is capped at 100 and the page number at 1,000, so a very large downline is browsed rather than dumped.

The member's referral link is built from their own user id:

https://your-site.com/en/register?ref=8b1f0c2e-4d3a-4f21-9f52-6e0d7a1c3b44

There is no separate referral code table — the member's UUID is the code. That has two consequences worth knowing: links are long and unmemorable, and a member's referral link is effectively their user id in public.

A second, shorter format also works:

https://your-site.com/en/ref/8b1f0c2e-4d3a-4f21-9f52-6e0d7a1c3b44

That route stores the code and redirects to the homepage with the registration form open. Both formats store the code in the browser's session storage, so a visitor can arrive through a referral link, browse the site, and still be credited when they register later in the same tab.

The registration form looks the referrer up and shows their name and avatar, so the person signing up can see who invited them before they commit.

The generator can append campaign=, source= and custom= to a link, and the UI presents them as campaign management. Registration reads only ref. Nothing stores the other three, nothing reports on them, and no screen breaks a member's referrals down by campaign.

They are useful if you feed the links into your own analytics — the parameters survive into your web-server and analytics logs — but there is no attribution inside the platform. Do not promise members campaign-level reporting.

The QR tab renders the link as a QR code, with a size and colour picker. The QR image is generated by a third-party service (api.qrserver.com): the referral URL is sent to an external host, and the tab shows a broken image if that service is unreachable or blocked. Nothing else on the page depends on it.

The share tab produces pre-filled links for Twitter, Facebook, LinkedIn, WhatsApp and email.

Rewards

Every reward the member has earned, with the condition it came from, the amount, the currency and whether it has been claimed. Unclaimed rows carry a Claim button.

Claiming credits the wallet named by the condition and is subject to the payout threshold and the withdraw_affiliate KYC feature — see Rewards and payouts. When the KYC gate blocks them, the screen shows a verification notice with a route to complete it rather than a failed button press.

Members also get an in-app notification each time a commission is created, titled Referral Reward Earned, linking straight here.

Commission Rates

The public rulebook: every active condition, its title, description, reward and reward type, filtered to the addons you actually run. This is what a member reads before deciding the programme is worth promoting, so the title and description fields on your conditions are marketing copy, not internal notes — edit them accordingly on Admin → Affiliate → Conditions.

Nothing on this screen shows level percentages. A member on a multi-level plan sees the headline commission and has no in-product way to work out that their level 3 share of it is 20%. If you run BINARY or UNILEVEL, publish the level breakdown yourself — a knowledge-base article or the condition descriptions are the two places to put it.

Next: Running the programme.