> For the complete documentation index, see [llms.txt](https://docs.bloop.plus/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.bloop.plus/referral-program/analytics.md). # Analytics Read revenue, behaviour and the funnel to judge whether the programme pays. Analytics is where you decide whether your referral programme is earning its keep. It runs from outcomes — who joined, who bought, how much revenue — back through the funnel to behaviour: who saw the offer, who shared, and on which channel. Open **Referral → Analytics**, and pick the campaign and date range you want to look at. A shorter version of the same numbers sits on each campaign's overview, next to a **Branding** card that tells you whether your widget is live and your referral page exists. That pairing is deliberate: a flat share count usually means a surface you never turned on. > **Best practice:** Watch two ratios above everything else — **shares per impression** (is the offer compelling?) and **successful referrals per share** (do those shares convert?). Revenue totals look good on a slide; these two tell you what to change. ### Pick a period Presets cover last 7, 30 and 90 days, last week, month and year, and week, month or year to date. **Custom** takes a **Since** and **Until** date. The 7- and 30-day views resolve "today" against your store's timezone, so they end on your calendar day rather than the server's. If a banner tells you **tracking starts from** a date, that's when the metric went live — Bloop can't backfill behaviour it wasn't recording yet. Compare periods after that date only. ### The summary Four tiles sit above everything: | Tile | What it counts | | ---------------------- | --------------------------------------------------------------- | | Total referrers | People enrolled in the programme | | Successful referrals | Referred purchases that qualified — the programme's real output | | Total referrer revenue | Revenue from orders placed by referrers | | Total referee revenue | Revenue from orders placed by the people they referred | ### Revenue, split the way it matters | Card | What it tells you | | --------------------------- | ------------------------------------------------------------------------------------- | | Total referral revenue | Referrer and referee revenue together, plotted over time | | First referral revenue | Revenue from referees' **first** orders — the true acquisition value of the programme | | Subsequent referral revenue | Revenue from referees' **repeat** orders — whether referred customers stick | | Total referee orders | Order volume from referees, first and repeat | | Total subsequent orders | Repeat orders from referees alone | First versus subsequent is the split that answers the awkward question. A programme with strong first revenue and no subsequent revenue is buying one-off discount hunters; a programme where subsequent revenue grows is buying customers. Referred customers should out-retain your other acquisition channels — if they don't, the problem is your onboarding, not your referral offer. ### Behaviour, and exactly how it's counted These three look similar and mean different things. Reading them as the same number is the most common mistake on this page. | Card | Counted as | | ------------------- | ---------------------------------------------------------------------------------- | | Shares | Every share-channel click or copy-link action, with no deduplication | | Store visits | Every click on a referral link, first and repeat, with no deduplication | | Unique store visits | Store visits deduplicated per day by device and IP — one per device and IP per day | So **shares** counts enthusiasm, not people: one referrer copying their link five times adds five. **Unique store visits** is the honest traffic number; the gap between it and store visits tells you how much of your referral traffic is the same people coming back. Two more: * **New enrolled referrers** — how many people joined per day across the period. * **Welcome emails viewed** — how many times the welcome email was opened, which is your check on whether the invites land at all. ### Who and where **Top referrer** ranks your advocates by successful referrals and revenue, with the date each last brought someone in. Read the *last active* column, not just the totals: a top referrer who stopped three months ago is a lapsed advocate worth an email. **Referral entry point performance** is the table to act on. Each surface where the offer appears — widget, referral page, post-purchase, customer account — gets a row with: | Column | Meaning | | ----------------- | --------------------------------------------- | | Impressions | Unique customers who saw that entry point | | Copy/Share | Unique customers who copied or shared from it | | CTR (%) | Copy/Share as a percentage of impressions | | Top share channel | The channel those customers used most | A surface with high impressions and a low CTR has a copy problem. A surface with almost no impressions has a placement problem — or isn't turned on. Check the Branding card before you rewrite anything. **Sources of referees** shows where referred customers arrived from; **Sharing sources** shows where referrers shared from. Together they tell you which channels to keep, promote or drop — see [sharing channels](/referral-program/branding/social-sharing.md). ### Read the funnel The value is in the drop-off between stages, not in any single total: 1. **Entry-point impressions** — how many people saw the offer. 2. **Shares** — how many acted on it. 3. **Successful referrals** — how many of those shares became qualifying purchases. Where the number falls off sharply is where your problem lives. ### Diagnose by symptom | Symptom | Likely cause | What to try | | --------------------------------------------- | ---------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | High impressions, few shares | The offer isn't compelling | Strengthen the [reward](/referral-program/rewards.md); lead with the friend's reward in the [widget](/referral-program/branding/popup.md) | | Few impressions overall | The programme is hard to find | Add entry points — [post-purchase widget](/referral-program/branding/post-purchase.md), [referral page](/referral-program/branding/page.md), [account blocks](/referral-program/branding/account-extension.md) | | Plenty of shares, few referrals | Friends click but don't buy | Sweeten the referee reward, or drop a minimum spend | | Store visits far above unique visits | Referrers are clicking their own links | Real reach is smaller than it looks — judge by unique visits | | Strong first revenue, weak subsequent revenue | A retention problem, not a referral one | Fix post-purchase lifecycle, not the offer | | Few referrers joining | Audience too narrow, or programme hidden | Widen the [target audience](/referral-program/target-audience.md) | | One channel takes every share | Channel mix doesn't match your audience | Reorder [sharing channels](/referral-program/branding/social-sharing.md) | Confirm any fix that costs real money — a bigger reward, especially — with an [A/B test](/referral-program/ab-testing.md) rather than a hunch. ### What "good" looks like Referral rates vary enormously by industry, so judge your dashboard against its own trend rather than a borrowed benchmark: * **The trend beats the absolute.** Shares and referrals climbing month over month matter more than any external number. * **Conversion should hold as you scale.** A falling share-to-referral rate means you're reaching less-engaged sharers. * **Cost per referral should stay sane.** A reward that wins on raw count can still lose money — read revenue alongside what each reward costs you. ### A worked example *Illustrative, not measured Bloop results.* Over 30 days: 8,000 impressions, 400 shares (5% — low), 40 successful referrals (10% of shares — healthy). The cliff is at the share step, so the fix is the offer, not the funnel: strengthen the referee reward, lead the widget copy with it, then confirm with an [A/B test](/referral-program/ab-testing.md). ### Common mistakes to avoid * **Reading totals and ignoring ratios.** Total revenue feels good but doesn't tell you what to fix. * **Treating shares, store visits and unique store visits as the same number.** They're counted differently on purpose. * **Peeking too early.** A few days of data is noise. Let a range gather real volume. * **Changing two things at once.** Then you won't know which moved the needle. * **Comparing across the tracking start date.** Anything before it reads as zero because nothing was recorded. ### Next steps * Adjust incentives in [Referrer and referee rewards](/referral-program/rewards.md). * Confirm a fix before rolling it out with [A/B testing](/referral-program/ab-testing.md). * Add entry points — see [making your referral program visible](/best-practices/program-visibility.md). --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.bloop.plus/referral-program/analytics.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.