Affiliate Performance Dashboard
Define the metric set and layout for an affiliate performance dashboard, delivered as a dashboard specification document - metric definitions with explicit formulas, views per audience, refresh and review cadence, and alert thresholds for top affiliates, conversion by source, and program ROI. Covers B2B SaaS recurring revenue-share and B2C ecommerce order-level CPA programs. Use whenever the user mentions affiliate program reporting, affiliate KPIs, affiliate ROI, revenue concentration, or what to put on an affiliate dashboard, even if they never say dashboard. Specifies metrics, never builds them in a BI tool. Do NOT use for one creator campaign's measurement plan - use mbfinotti/partnerships-skills@influencer-measurement-framework instead.
- Skill ID
- mbfinotti/partnerships-skills/affiliate-performance-dashboard
- Publisher
- mbfinotti
- Repository
- partnerships-skills
- Installs
- 528
- Files
- 7
- License
- MIT
- Synced
- Oct 23, 2026
Open any RiverX project, open the Skills panel in the chat, and search for this identifier. The files are fetched from the source repository at install time.
mbfinotti/partnerships-skills/affiliate-performance-dashboardInstalls these files- SKILL.md
- evals/evals.json
- references/concentration-and-cohorts.md
- references/layout-cadence-and-alerts.md
- references/metric-definitions.md
- references/roi-and-incrementality.md
- references/worked-examples.md
What this skill tells the agent
Affiliate Performance Dashboard
Define what an affiliate program dashboard measures and how it is laid out, then deliver a dashboard specification document. The spec - not a built dashboard - is the artifact: whoever owns the BI tooling implements it from the spec.
No canonical affiliate-dashboard framework exists, and metric definitions are not standardized: no standards body enforces them, IAB and the PMA publish guidance only. Say this plainly to the user; never present a branded framework that does not exist.
The method borrows four established things and nothing else:
- Incrementality measurement, via holdout and geo-lift testing, resting on explicit definitions of incrementality, baseline conversions, and model validation.
- Attributed ROAS vs attributed ROI split, where ROAS divides attributed revenue by media cost and ROI divides it by media cost plus COGS.
- Sourced vs influenced separation rule.
- Tiered metric hierarchy plus good-metric criteria, from Croll & Yoskovitz's _Lean Analytics_: a metric must be comparative, a ratio or rate, understandable, and behavior-changing.
The platform glossary behind the first two definitions is named in references/metric-definitions.md, not here; the definitions are the skill's operative ones regardless of which platform the program runs on.
Ground Rules
- Report validated/approved commission and net revenue, never gross - gross is the bigger number and the most-named practitioner error.
- Give every metric a one-sentence definition naming numerator, denominator, window, timezone, and counting method. A definition that cannot fit one sentence is theater.
- Provenance-tag every benchmark: vendor, trade body, synthesis, or the program's own derived baseline. Nearly all published affiliate benchmarks come from parties with an incentive to inflate the channel.
- Never sum partner-sourced and partner-influenced revenue; report them as two separate, capped numbers.
- Never compare two periods with different validation windows - reversal lag makes the recent one look artificially good.
- Keep fraud and compliance signals on the same view as performance, never in a separate tool - daily decision-makers need both at once.
Interview
Ask before specifying anything, following these rules:
- One question per message.
- Multiple-choice where possible.
- Skip anything already answered.
- B2B SaaS, B2C ecommerce, or both?
- Program size and maturity: active partner count, monthly commission spend, program age?
- Who reads the dashboard - executive, operator, or both - and what decision should it drive?
- Commission model, and is any of it recurring?
- Validation/locking window length and clawback policy?
- Attribution model and cookie window?
- Which data sources exist - affiliate platform, billing/orders, CRM, warehouse - and does the partner ID reach billing or orders at all?
- Is partner type / promotional method captured per partner?
- Is new-vs-returning customer captured per conversion?
- Refresh capability and tooling constraints - live queries, daily batch, manual export?
- Current pain: what question can the program not answer today?
- Reporting cadence today, and which review meetings already exist?
- By what date must the first version be in front of its readers?
- One-off win - settle one contested question now - or a compounding asset the program is run from every week?
- Effort ceiling: analyst hours available, who owns the data join, and whether standing maintenance is fundable at all?
Those last three answers re-rank every option menu in this skill and its references. Say out loud which answer moved which option:
- A near date pins the spec to the orders spine and deletes every metric needing a join that does not exist yet.
- A compounding mandate promotes the customer-file join, cohort views, and churn-adjusted partner LTV.
- A thin effort ceiling deletes the modeled warehouse, the brand-bidding alert, and the creative slice outright rather than parking them at the bottom of the spec.
Every ranking here is a default, not a law - it shifts with context and with who executes it. Re-rank against what you already know about this user: a network that exports partner classification cleanly, a warehouse already loaded with billing and CRM, or no analyst at all each move different rungs.
Workflow
- Run the Interview; collect every answer the spec depends on.
- Fix the source of truth and write the comparability contract - event definition, date basis, timezone, currency, counting method - before specifying any metric. Every later number inherits these choices; changing them afterwards invalidates all history. Three data foundations compete here, ranked by value per unit of effort, where effort is reconciliation work and standing maintenance:
- efficiency:
billing/orders spine > customer-file join > modeled warehouse - value:
modeled warehouse > customer-file join > billing/orders spine - effort (most first):
modeled warehouse > customer-file join > billing/orders spine
Three costs distinguish these foundations:
- The spine: a week of reconciling the platform export against orders or billing, then near-zero standing cost.
- The customer-file join: a quarter, because the partner ID has to be stamped at order or account creation before new-to-file and sourced-vs-influenced are computable at all.
- The modeled warehouse: a standing job.
Default to the spine and climb only when a named decision needs it.
Deleted, not demoted: the affiliate platform's own export as source of truth. Those are the claimant's numbers, so no effort saving redeems them; the platform stays the source for clicks and traffic, reconciled to the money spine.
What this order starves is the modeled warehouse: highest value, loses every round. Promote it when the program's live question is incrementality rather than reporting, or when one repricing decision moves more money than the build costs.
- Select the metric tier set: business/headline tier, input/driver tier, health/guardrail tier.
Four metrics are floor rather than choice, because the Pass Threshold cannot be met without them:
- Net program contribution
- Cost of sale
- Top-N partner concentration
- Partner-sourced MRR/ARR in B2B
Everything beyond that floor is a menu: take the top rungs of your segment's efficiency order in references/metric-definitions.md, which ranks B2B and B2C separately and names what each order starves. Reject any metric failing the four good-metric criteria, and stop adding rungs before the dashboard shows everything and therefore nothing. Delete every metric whose data the Interview says does not exist, naming it under Open items instead of leaving it in the spec as a wish.
- Write each metric's spec row (see Output Shape), resolving every competing definition explicitly - the chosen numerator, denominator, window, and counting method go in the row, not in anyone's head.
- Choose the slicing dimensions the program's data can actually support, in the efficiency order of references/layout-cadence-and-alerts.md:
partner > partner type > product/plan > geography > device > landing page > creative. Partner type is not the cheapest slice and is the one that pays - build it anyway. - Lay out one view per audience: executive and operator views differ in metrics, not just detail level.
- Set refresh and review cadence per tier - each tier has its own natural rhythm; one refresh rate for the whole dashboard is a defect.
More from mbfinotti
Use this skill in a project
Open any RiverX project, search the Skills panel for mbfinotti/partnerships-skills/affiliate-performance-dashboard, and install it in one click.
