← Back

Lions Den Gaming Partner Portal

A traceable affiliate dashboard for an invite-only iGaming partner program.

Project overview

  • Type: Client · 12-week engagement · responsive web portal
  • Team: with 1 PM, 2 engineers, and an affiliate-ops stakeholder
  • Project type: Systems Design · Data-dense Dashboard · Affiliate / B2B · Trust & Retention
  • Role: Lead Product Designer · Information Architecture · Systems Design · Interaction Design
  • Methods: Stakeholder interviews · session-replay analysis · tree testing · A/B
  • Tools: Otter.ai · Hotjar · Figma + Dev Mode · Amplitude · Statsig
  • Case thesis: Designing an affiliate dashboard where every commission traces back to the link and player cohort that earned it, so partners trust the payout enough to keep promoting instead of leaving for a competing program.

The context

The portal serves an invite-only set of affiliates — influencers and gaming enthusiasts who drive referrals to the company's slot and casino products and earn commission on the players they bring in. It belongs to a family of platforms alongside the casino product I had designed earlier for the same company, sharing a component foundation while carrying its own theme and identity. Affiliates run this as a side business and choose where to send traffic based on which program pays clearly and on time. As a regulated iGaming product, the portal also operates under data-protection and responsible-gambling constraints that shaped what partner-facing data could be shown and how.

The problem

Affiliates distrusted the numbers. Across a quarter of support records, 45% of all affiliate tickets were payout or reconciliation disputes (operational, ticket analysis, n=1,180) — partners asking why the portal's commission differed from their own tracking. The earnings balance was the single most-viewed screen (behavioral, Amplitude), while the link-level breakdown that would explain it sat three taps deep and was opened by only 12% of affiliates. Partners could see a total they could not verify.

The goal

Make the click-to-payout chain self-service and verifiable, so affiliates reconcile their own earnings without a ticket, measured by payout-dispute ticket volume and 90-day affiliate retention, rather than by dashboard polish.

Empathize — Affiliates checked their balance constantly but could not reconcile it, and disputes were 45% of all support tickets

In this section: Research foundation · Key insights

Research foundation (method)

  • Phase 1 — Affiliate interviews (n=14, ~45 min, recruited from the active partner base, transcribed in Otter.ai): how partners decide where to send traffic and how they judge a program's trustworthiness.
  • Phase 2 — Support ticket analysis (n=1,180 affiliate tickets, one quarter): coded by reason against a written scheme to size the dispute problem.
  • Phase 3 — Portal behavior analytics (Amplitude + Hotjar session replay, web + mobile web): screen views, drill-down reach, and where partners stalled; session replays showed partners opening the balance, scrolling for a way to verify it, and leaving for support.
  • Phase 4 — Tree testing (n=20 affiliates): validated where partners expected to find the link-level breakdown and the next-payout detail, which set the drill-down hierarchy before visual design.
  • Phase 5 — Prototype pilot (Amplitude-instrumented, 60 affiliates, ~30 per A/B arm): behavior and ticket data on the rebuilt dashboard.

Key insights

1. Partners obsess over the balance and cannot trace it. The earnings screen was the most-viewed surface, yet the data behind it stayed hidden, and reconciliation disputes dominated support. Triangulation:

  • Behavioral: balance was the #1 screen; the link-level conversion breakdown was reached by 12% of affiliates.
  • Operational: 45% of affiliate tickets were payout or reconciliation disputes.
  • Verbatim (A4, mid-volume affiliate, ~18 months active) — coded: Payout distrust: "Your dashboard says one thing, my own spreadsheet says another, and I have no way to see which clicks turned into what."

2. The dashboard led with clicks while burying the metric that pays. Total clicks sat at the top of the old view, but commission comes from referred players who deposit, and that conversion was not visible per link. Affiliates could not tell which campaign earned.

  • Raw example: a partner running four promo links saw one combined click count and one combined balance, with no way to see that a single link drove most of the depositing players.
  • Verbatim (A9, content affiliate) — coded: Wrong headline metric: "Clicks don't pay me. I needed to know which link actually sent players who deposited, and that was nowhere."

3. Payout uncertainty correlated with churn. Affiliates who filed a reconciliation dispute were more likely to go inactive within 90 days. The relationship is correlational — a partner already drifting may also dispute more — so it motivated the design bet rather than proving it; the pilot retention change (below) is the actual test.

  • Behavioral: affiliates with at least one payout dispute showed roughly 2.3× the 90-day inactivity rate of those without.

Dashboard — Where affiliate support volume comes from

Where affiliate support volume comes from
Scope: 1,180 affiliate tickets · one quarter · coded by reason
Guiding question: What are affiliates contacting support about?

  Payout / reconciliation disputes ........ 45%
  Link & tracking setup ................... 21%
  Account / settings ...................... 18%
  Payment method & billing ................ 16%

Key Insight: Nearly half of all contact is partners trying to verify a
number the product would not let them verify themselves.

Define — Every commission number had to drill down to the specific links and player cohorts that earned it

In this section: POV · How Might We · Principles · Insight→decision map

POV statement. Affiliates need to trace each commission back to the specific link and depositing-player cohort that earned it, in one view, because their decision to keep promoting versus switching to a competing program depends on trusting the payout.

How Might We

  1. How might we let an affiliate reconcile a payout to its source clicks and player cohort without filing a ticket?
  2. How might we surface which link and campaign drive depositing players, so partners promote the ones that earn?
  3. How might we make the next payout date and amount unambiguous and self-evident?

Design principles (each traceable to an insight)

  • Traceability. Every total drills to the events that produced it. (Insight 1)
  • Conversion over clicks. The dashboard leads with referred players who deposited, per link. (Insight 2)
  • Payout certainty. Next payout date and amount, and how it was computed, are always one glance away. (Insight 3)
  • Privacy by design. The drill-down resolves to anonymized, aggregated player cohorts (counts, pseudonymous IDs, deposit totals), never player-identifying data, because affiliates are third parties under data-protection rules. (regulatory constraint)
  • Legible at density. A high-contrast dark theme and disciplined typographic hierarchy keep dense financial data scannable. (data-density constraint)

Insight → decision map

Insight (from Empathize) Concrete design decision
45% of tickets are reconciliation disputes; balance can't be traced The balance expands inline into the clicks → signups → deposits → commission chain, per link and time range, resolving to anonymized player cohorts
Clicks led the view; the converting link was invisible The dashboard opens on depositing players and commission per link, with clicks demoted to a secondary column
Disputes correlate with 2.3× inactivity A payout panel shows next date, projected amount, and a computed breakdown, removing the reason to file a ticket

Ideate & Craft — The dashboard was rebuilt around the click-to-payout funnel, with every total traceable to its source

In this section: Design execution · Data & privacy model · Before → after · Other deliverables

Design execution

  • Funnel-first home — the dashboard opens on the chain that pays: clicks, signups, depositing players, and commission, broken out per referral link and adjustable by date range.
  • Inline reconciliation — tapping the balance expands it into the contributing links and anonymized player cohorts, so a partner verifies the number in place instead of contacting support.
  • Link management — partners create and label multiple referral links per campaign, each with its own funnel, to compare what converts.
  • Payout panel — current balance, next payout date, projected amount, and the computation behind it, plus full transaction history.
  • Secure settings — personal and payment details with confirmation steps appropriate to money movement.

Data & privacy model (the regulatory constraint, made explicit)

Affiliates are third parties, so the drill-down never exposes player-identifying data. Each total resolves to aggregated cohorts — counts of signups and depositing players, pseudonymous references, and deposit/commission sums per link and date range — enough to reconcile a payout to its source, never enough to identify a player. This keeps the portal inside data-protection rules while still delivering the traceability that builds trust; the boundary between "verifiable" and "identifiable" was a core design constraint, not an afterthought.

Before → after

Before After
What the home view leads with Total clicks Depositing players and commission, per link
Verifying the balance File a support ticket Expand the balance inline to its source events
Comparing campaigns One combined number Per-link funnel, side by side
Next payout Unclear Date, projected amount, and computation shown
Player data exposure n/a Aggregated cohorts only, never PII

Other deliverables

The portal extends a shared design system built in Figma. Using variables and tokens, the partner portal inherits the casino platform's components and spacing while applying its own dark high-contrast theme, so the two products read as one family and ship from common foundations. Handed off via Dev Mode.

Dashboard — Self-service reconciliation replaces the ticket

Self-service reconciliation replaces the ticket
Scope: Last 30 days · web · Lions Den Partner Portal pilot (60 affiliates)
Guiding question: Did partners verify earnings without contacting support?

  Reached link-level breakdown
    Before (3 taps deep) ............ 12% of affiliates
    After (on home + inline) ........ 71% of affiliates

  Payout / reconciliation tickets per 100 affiliates / month
    Before .......................... ~22
    After ........................... ~8   (−64%)

Key Insight: Surfacing the breakdown moved reconciliation from a support
task to a self-service one, cutting dispute tickets by roughly two thirds.

Prototype / Test — A single simplified earnings number raised confusion and disputes; making it traceable fixed both

In this section: The experiment · What it taught

The first hypothesis was that the dashboard overwhelmed partners, so the early build led with one large consolidated earnings figure and tucked the detail away, aiming to reduce clutter. It was A/B tested against the traceable, expandable balance in Statsig across the pilot.

The failed variant. The consolidated number tested as cleaner in first impressions, but reconciliation tickets did not fall, and time-on-dashboard rose as partners hunted for a way to verify it. In a domain where the whole relationship rests on trusting the payout, a number a partner cannot inspect reads as a reason to distrust the program.

A cleaner number partners can't inspect doesn't reduce disputes
Scope: Statsig A/B · web · Partner Portal pilot · ~30 affiliates / arm
Guiding question: Which balance design reduces reconciliation disputes?

  Variant A — Consolidated single number
    First-impression clarity rating . highest
    Reconciliation tickets / 100 .... ~21   (vs ~22 baseline)
    Median time on dashboard ........ up 28%

  Variant B — Traceable, expandable balance
    First-impression clarity rating . slightly lower
    Reconciliation tickets / 100 .... ~8
    Median time on dashboard ........ down 12%

Read with care: ~30 affiliates per arm. The dispute-ticket gap is large and
consistent; the softer ratings are directional. The decision rested on the
ticket effect, not on first-impression scores.

Key Insight: Reducing visible detail looked simpler and changed nothing;
letting partners expand the number to its source is what cut disputes.

What it taught. Simplicity in a financial tool comes from making the computation inspectable; when trust is the product, hiding detail removes the thing that earns the trust. The traceable balance shipped.

Outcomes & reflections

In this section: Causal chain · Limitations · Competitive context · Reflections · References

Causal chain (pilot, 60 affiliates)

Reconciliation moved into the product, so payout-dispute tickets fell from ~22 to ~8 per 100 affiliates a month (−64%) — and, as a share of all affiliate tickets, from 45% to roughly 23%. That raised partners' rated confidence in payout accuracy, which lifted 90-day affiliate retention from 58% → 74% (the 58% baseline measured from the pre-pilot affiliate cohort), and retained partners both kept promoting and shifted spend toward their highest-converting links. Affiliate-attributed depositing players rose ~19% over the window — reported as a leading indicator rather than a causal result, given n=60, no control group, and the many other factors that move deposits in iGaming.

Metric Before After Δ
Reconciliation tickets per 100 affiliates / month ~22 ~8 ~−64%
Payout-dispute share of affiliate tickets 45% ~23% computed from the absolute drop
Affiliates reaching link-level breakdown 12% 71% +59 pts
90-day affiliate retention 58% 74% +16 pts
Affiliate-attributed depositing players baseline ~+19% leading indicator; not causal-attributed

Scale note: in an affiliate program, partners are a recurring acquisition channel, so a 16-point retention gain compounds — each affiliate kept is months of continued referrals rather than a one-time win.

Limitations (stated, because a portfolio claim is only as strong as what it concedes)

  • Small pilot. 60 affiliates, ~30 per A/B arm. The dispute-ticket and drill-down-reach effects are large and consistent; the depositing-players figure is a directional leading indicator, not an attributed result.
  • Correlational churn signal. The 2.3× inactivity-with-disputes figure motivated the design but does not prove causation; the pilot retention lift is the supporting test, itself on a small cohort.
  • Traceability ≠ tracking accuracy. The design makes the computation inspectable and discrepancies explainable; it does not fix underlying attribution gaps (cookie loss, attribution windows). Where the portal and a partner's own tracking differ for a real reason, the design surfaces why, rather than forcing a single truth.
  • Privacy boundary is load-bearing. Showing aggregated cohorts instead of player data is what keeps the product compliant; any future feature that drills deeper has to hold that line.

Competitive context

Affiliates choose where to send traffic, and the iGaming affiliate-software category is established — Income Access (Paysafe), Cellxpert, MyAffiliates, Affilka by SoftSwiss, and Track360 among them — with several already positioned around transparent reporting and dispute reduction, and player-level attribution a standard feature. Since the operator could have adopted one of these, the case for a bespoke portal is specific: it is part of a platform family sharing a design system with the casino product the same team built, carrying its own identity, with full control over the drill-down hierarchy and the privacy boundary. The differentiation is not a feature competitors lack; it is coherence across the family and a reconciliation experience designed end-to-end for this partner base.

Reflections (transferable principles)

  • In a financial or payout product, perceived simplicity comes from inspectability; a number the user can expand to its source builds more trust than a tidier number they cannot. (The A/B is the evidence: the cleaner consolidated number changed nothing.)
  • Affiliate retention is a measurable design outcome: the trust that keeps a partner promoting is built or lost in whether the dashboard lets them reconcile their own pay.
  • In a regulated domain, the design constraint is the design: drawing the line between verifiable and identifiable, rather than treating privacy as a later compliance pass, is what made the traceability shippable.
  • Designing one product inside a family is a systems problem first; shared tokens and components let a sibling platform ship faster and stay coherent while still carrying its own identity.

References (for the competitive and compliance claims)

  • iGaming affiliate-software landscape and feature norms — Income Access, Cellxpert, MyAffiliates, Affilka by SoftSwiss, Track360 (category guides, 2026).
  • iGaming marketing compliance spans affiliate-program, player-communication (responsible gambling), and data-protection (GDPR) levels (category compliance overviews, 2026).