ADR 0118 — Shadow-analytics data goals + consent-UX consequences

Status: Proposed 2026-04-24 (Kristerpher — conversational thread during PR #268 review) Supplement to: ADR 0017 — E2E with shadow-analytics posture Related PR: #268 Deciders: Kristerpher Henderson

Context

ADR 0017 locked Option B: E2E encryption as base invariant, opt-in client-side shadow-analytics pipeline for consenting users. The 2026-04-24 review of PR #268 confirmed the surrounding decisions (k=20 anonymity, k-anonymity only for v1, analytics store as a separate service rather than a Raptor Blueprint, no DP-noise at v1, DPIA ack).

One question surfaced during that review that 0017 did not resolve: what happens when a user who previously opted out tries to opt back in? The initial instinct was "don't let them re-opt-in — it's simpler." On reflection, Kristerpher flagged that this instinct was answered without a clear picture of what the analytics data is actually for. Different goals imply different consent shapes, and the re-opt-in call is downstream of goal selection.

This ADR exists to articulate the data goals, rank them by near-term likelihood, and let the goal ranking settle the consent-UX open questions that 0017 left partially open (re-opt-in, single vs granular toggles, friction level at opt-in, default-copy framing).

The four plausible data goals

Each is a real reason Raxx might want anonymized aggregate signal flowing into the analytics store. They have different product value, different consent weight, and different timing.

Goal 1 — Product improvement (telemetry)

Purpose: Understand which UX flows break, which strategies confuse users, which features go unused, which error paths users hit most.

What the data looks like: Error-type histograms. Page-dwell-time buckets. Strategy-construction-abandoned-at-step counts. Feature-visit frequency.

Consent framing: "Help us fix what's broken and build what's useful." Users generally say yes.

Re-opt-in stakes: Low. If a user opts out and later opts in, they've helped us improve the product in the interim via the aggregate signal from other users. Re-opt-in just resumes that contribution.

Goal 2 — Strategy recommendations

Purpose: Power recommendations grounded in what actually works for cohorts. "Users in your investor-profile + regime-mix + risk-tolerance bucket had strong results with cash-secured puts on high-implied-vol single-names" — sourced from anonymized aggregate performance of similar users.

What the data looks like: Strategy-family × regime × win-rate-bucket × hold-period-bucket aggregates. Never individual trades.

Consent framing: "Share your signal to get better recommendations. The more users who opt in, the better your recommendations get." Reciprocal benefit.

Re-opt-in stakes: Medium. A user who opts out sees neighbors (friends, community) getting recommendations while their own feed is generic. Some will want back in. Locking them out creates permanent product friction.

Goal 3 — Anonymized data as a product

Purpose: Raxx's shadow-analytics store is itself a valuable asset — anonymized aggregate trading behavior at retail-options scale is useful to market researchers, academics, or institutional buy-side. Raxx could monetize access (subscriptions, research licenses) or publish reports.

What the data looks like: Same aggregate signal as Goal 2, but exposed via a separate B2B product surface (API, published research, licensed dataset).

Consent framing: Heaviest. Under GDPR this is "sharing with third parties for commercial purpose" — different consent category than "product improvement." CCPA "do not sell" language applies in CA. Distinct opt-in required; cannot bundle with Goal 1/2 consent.

Re-opt-in stakes: Extreme. Withdrawal of consent here must be permanent and auditable — Raxx must be able to prove, per-user, which consent state was active at each moment data was used.

Timing: Genuinely interesting (per Kristerpher's PR #268 review comment: "there might be a value opportunity there in the future"), but not a v1 concern.

Purpose: Powers features like #211 (Founders referral leaderboard), future strategy leaderboards, community-insight widgets. User performance visible in aggregate + opt-in peer comparisons.

What the data looks like: Cohort-aggregate performance per leaderboard slice. Individual-user signal only surfaces if the user specifically opts into being visible.

Consent framing: Similar to social-media profile visibility. "Show your stats (anonymized / pseudonymous) in this leaderboard?" Users expect granular control.

Re-opt-in stakes: Medium-low. Turning leaderboard participation off and back on is expected behavior, like hiding/unhiding a social-media profile.

Timing: Matters when #211 ships and future leaderboards follow.

Ranking (near-term likelihood)

Goal	MBT v1	v1.5	v2+	Consent weight
1. Product improvement	✓ primary	✓	✓	Light
2. Strategy recommendations	✓ secondary	✓ primary	✓	Medium
3. Data product	—	—	maybe	Heavy
4. Social / gamification	—	✓ (leaderboards ship)	✓	Medium

v1 serves Goals 1 + 2. Goal 3 is future-proofed by the shadow pipeline architecture (data is already anonymized + separated), but is NOT a v1 consent ask. Goal 4 waits on leaderboard features shipping.

Decision

Consent UX at v1 covers Goals 1 + 2 together — a single coherent ask framed as "help improve the product + improve your recommendations." Goal 3 (data-product) is explicitly out of scope for v1 consent; if that product line is later pursued, users will be asked for a new, distinct consent.

Single bundled toggle for Goals 1 + 2 at v1. Not granular sub-toggles, because: - The two goals are served by essentially the same aggregate signal at v1 - Multiple toggles = multiple confusing choices; single toggle = clear "yes / no" decision - Granular toggles can be introduced at v1.5 if user feedback requests them

Language on the toggle: something close to "Share anonymized usage signals so we can improve the product and your recommendations" + a link to a plain-language explainer of exactly what's shared.

2a. Privacy-toggle surface design (UX principle)

Privacy toggles live in a dedicated, clearly-labeled Privacy panel within Settings (e.g. Settings → Privacy), NOT scattered across the app or buried inside unrelated settings pages. The panel is a durable, first-class destination — linkable, discoverable, and exhaustive (every toggle that affects what data Raxx sees or stores is listed here, not just the shadow-analytics toggle).

Rationale: - Users looking for "what can I control about my data?" should find the answer in one place on the first try - Scattered toggles create the perception (and reality) of hidden controls — a trust cost - Centralization also simplifies engineering: any new consent control lands in one panel, with one consistent pattern

This principle applies not only to the shadow-analytics toggle but to any future privacy-affecting control (Goal 3 consent if ever shipped, leaderboard visibility toggles per Goal 4, telemetry-only-if-crash toggles, etc.).

Precedent references (apps Kristerpher has cited approvingly): Proton's Settings → Privacy, Apple's Settings → Privacy & Security, Firefox's Settings → Privacy & Security.

v1 Privacy panel contents (minimum): - Shadow-analytics consent toggle (Goals 1 + 2 bundle, per this ADR) - Link to the privacy-policy page - Link to the data-export flow (GDPR Art. 20 right-of-access) - Link to the account-deletion flow (GDPR Art. 17 right-to-erasure) - Consent-history viewer (read-only; shows the user their own consent transitions over time)

3. Re-opt-in behavior — REVISED from PR #268 review

Allow re-opt-in, with a confirmation screen. This reverses the initial "no re-opt-in" instinct from the #268 review, because:

Goals 1 + 2 are both low-to-medium stakes; permanent lockout is disproportionate friction
Users changing their mind is a normal, legitimate behavior — not an attempt to game the system
k=20 k-anonymity + separate analytics store means re-opt-in can't leak prior state (a user's old shadow data was hard-deleted within 30 days of opt-out; opt-in starts fresh)
Permanent lockout makes the opt-out decision feel punitive, which discourages the very pause-to-reflect behavior we want from users weighing consent

Friction: Re-opt-in requires a second confirmation ("are you sure? you previously withdrew consent on [date]; opting in resumes data contribution from now forward. Past data is gone and will not be restored."). This is consistent with how reputable privacy-respecting products (Proton, Tuta) handle re-engagement.

Non-gaming protection: We track the count + cadence of opt-in/opt-out cycles per user. Rapid cycling (> 3 transitions in < 30 days) triggers a quiet flag and the user sees a different copy on their next opt-in attempt ("you've toggled this several times recently — let us know if the choice isn't clear"). No lockout, just a signal that UX needs work for them.

4. Future decision points

These re-open if goal ranking changes:

If Goal 3 becomes a v2 product: distinct consent flow with its own opt-in, separate from Goals 1+2. Re-opt-in policy for Goal 3 will be reviewed separately — likely heavier friction given legal exposure.
If Goal 4 ships before v1.5: leaderboard consent is separate from shadow-analytics consent; user can participate in one without the other.
If a DPIA review flags Goal 2 as higher-stakes than assumed: granular toggles might become required (improvement ✓ / recommendations ✗).

Consequences

Consent UX at v1 = one toggle + one confirmation screen. Not a consent-management suite.
No permanent lockout mechanism to build. Simpler.
Opt-out hard-delete pipeline (ADR 0017) handles all withdrawal cases uniformly; no special permanent-delete variant.
Data-model additions: consent_history append-only table tracking every transition per user, sufficient to prove consent-state-at-time for GDPR Art. 7 compliance. No separate re-opt-in-block table needed.
Goal 3 (data product) remains a latent option; v1 architecture doesn't close the door, but doesn't open it either. If pursued, expect a new ADR, a separate consent flow, distinct legal review.
Goal 4 (leaderboards) consent lives in whatever ADR covers #211 when it's picked up; leaderboard participation is NOT an implied consequence of shadow-analytics opt-in.

Alternatives considered

Permanent lockout on re-opt-in (the original #268 review instinct). Rejected because it's disproportionate to the Goal 1+2 stakes and because the separate analytics store + k=20 + hard-delete pipeline already provide structural protection that makes re-opt-in safe.
Granular per-goal toggles at v1 (Goal 1 ✓ / Goal 2 ✓ independently). Rejected because at v1 the signal shapes are similar enough that the UX complexity isn't earning its keep. Revisit at v1.5 if users request it.
Defer this ADR until Goal 3 clarity. Rejected because the consent UX must ship at v1 regardless of Goal 3's fate; locking Goals 1+2 now doesn't foreclose Goal 3 later.
Combined v1 consent covering Goals 1+2+4. Rejected because leaderboard consent genuinely is a different shape (visibility of self vs sharing of aggregate), and bundling confuses both.

Open questions (non-blocking)

What's the plain-language toggle copy? Drafted examples above; marketing-strategist or a copywriter should polish before shipping. Tone precedent: Proton's privacy toggles.
Do we track "would have contributed" counter for opted-out users? (i.e. show them "you would have contributed N signals this month had you opted in" — mild nudge.) Unresolved; defer to whoever owns the consent-UI implementation card.
Does the consent-history table need to be encrypted under the user's passkey key, or is it operational metadata? Proposal: operational metadata (server-readable) because we need to be able to answer "what was this user's consent state at time T?" independent of the user's presence. Confirm with DPIA review.

References

ADR 0017 — E2E with shadow-analytics posture — the parent ADR this supplements
Research doc — passkey E2E with opt-in shadow analytics
PR #268 — review comments establishing the decision thread
GDPR Art. 7 — conditions for consent
ICO guidance on consent