Benchmark Methodology

1. Cohort definition

Every Keeping Up user is assigned to a cohort: a group of users sharing the same combination of three attributes:

• City — a metro area, not a precise ZIP. We use 16 large US metros at launch (NYC, LA, Chicago, Houston, Dallas-Fort Worth, Washington DC, Miami, Philadelphia, Atlanta, Phoenix, Boston, San Francisco, Riverside, Detroit, Seattle, Minneapolis-Saint Paul) and a residual "Other US" category for everyone else. Metro areas are wide enough that knowing someone's city doesn't identify them.
• Industry — one of 21 broad categories (Finance, Tech, Healthcare, Education, Government, Manufacturing, Retail, Hospitality, Real Estate, Legal, Marketing, Consulting, Non-profit, Media, Energy, Construction, Transportation, Agriculture, Arts, Self-employed, Other). Granular enough to capture meaningful pay-band differences; broad enough that millions of US workers fall into each.
• Age range — one of 7 brackets (22-26, 27-29, 30-37, 38-44, 45-50, 51-55, 56+). Roughly aligned with career-stage cohorts.

Total possible cohorts: 17 cities × 21 industries × 7 age ranges = 2,499 cohorts. Not all are populated equally — "NYC × Finance × 30-37" will have far more users than "Other US × Agriculture × 56+". Sample-size thresholds (§3) handle this.

We do not sub-segment by gender, race, ethnicity, marital status, or parental status. These attributes are not collected and not used in cohort construction.

2. What we benchmark

The following metrics are computed for each cohort:

• Net worth — total assets (cash + investments + property + vehicles) minus total liabilities (mortgages + credit cards + student loans + auto loans + other)
• Savings rate — (monthly income − monthly spending) ÷ monthly income, smoothed over 90 days
• Monthly spending by category — Dining, Groceries, Housing, Transport, Shopping, Entertainment, Healthcare, Travel, Subscriptions, Other (10 categories)
• Investment allocation — % of investable assets in stocks vs bonds vs cash vs alternatives (Pro feature)
• Emergency fund months — liquid savings ÷ monthly spending
• Debt-to-income ratio — total non-mortgage debt ÷ annual income

We do not benchmark: specific transaction merchants, account balances at named institutions, credit scores (we don't pull these), tax-return data, or anything tied to an identifiable individual.

3. Sample-size thresholds and confidence indicators

A cohort with 3 users tells you nothing about "the typical 27-year-old in Phoenix Construction." To avoid misleading-precision claims, we apply tiered thresholds:

• n ≥ 30 users: full distribution shown (p10/p25/p50/p75/p90), no confidence indicator
• 10 ≤ n < 30: distribution shown with an "Approximate" confidence badge. The benchmark is rendered slightly faded with the user explicitly told the sample size.
• n < 10: we don't show a cohort-specific benchmark. Instead we widen the cohort by collapsing the age dimension (e.g., "Phoenix Construction 27-44" instead of "27-29") until n ≥ 30, OR we fall back to a national benchmark for that industry × age combination.

Seeded benchmarks (launch only): at launch, several cohorts are pre-populated with synthetic data derived from the Federal Reserve's Survey of Consumer Finances (SCF 2022) so the product is usable from day one. Synthetic benchmarks are clearly labeled with a "Seed data" badge. As real users sign up, real percentiles replace seeded percentiles cohort-by-cohort. After ~3 months of operation, no cohort displayed to a user should still be seed-derived.

4. Computation cadence

Benchmark distributions are recomputed nightly via a scheduled job running at 02:00 UTC. The job:

1. Recomputes each user's metrics for the prior day (net worth, savings rate, etc.) from their latest connected-account data
2. Groups users by cohort and computes percentile distributions per metric
3. Writes the new distributions to a dedicated benchmarks data store, replacing the prior day's values

Your dashboard reads the most-recent benchmark row when you log in. Numbers shift slightly day-to-day as the cohort population and members' data evolve. The shift is typically <1 percentile point per day for stable cohorts.

5. Privacy and de-identification

Three guarantees worth being explicit about:

(a) No raw individual data leaves your row. The benchmark aggregator reads from each user's pre-computed metrics (net worth, savings rate, monthly spending by category). It never sees specific transactions, merchant names, account numbers, or anything tied to your identity. The aggregator groups by cohort and computes percentiles; that's the only data flow.

(b) Cohort outputs are statistical, not enumerable. The benchmarks data store holds percentile values (p10, p25, etc.) — numbers like "p50 net worth for NYC Finance 30-37 = $584,350". Even with full read access to those rows, you cannot work backwards to identify any specific user. With n ≥ 30 users per cohort, the percentile values would be unchanged if any single user were removed.

(c) Cohort assignment isn't a covert tracker. The cohort identifiers (city, industry, age range) you give us at signup are visible to you in your profile and editable any time. We don't derive these from your transactions, IP address, or any other inferred data.

The full data-handling description, including third-party processor disclosures and your CCPA / GDPR / state-equivalent rights, is in our Privacy Policy.

6. Statistical methods

We use straightforward percentile computation — no machine learning, no probabilistic modeling. For a metric M and a cohort C with N users:

• Collect the N values of M from each user in C
• Sort ascending
• p10 = value at the 10th percentile (linear interpolation between observations)
• p25, p50, p75, p90 — same approach at their respective percentile positions

Outlier handling: at small cohort sizes a single extreme value can dominate the percentile output. For n < 100, we apply a 5%-trim before computing percentiles (drop the top and bottom 2.5%). At n ≥ 100, no trim is applied.

Cross-cohort consistency: when a user falls into a sparse cohort and we fall back to a wider cohort (e.g., dropping the age dimension), the resulting percentile carries a methodology note in the UI explaining the fallback. No cohort change happens silently.

7. Limitations and caveats

Things this methodology does not claim:

• Causation. A user in the "top 12% of NYC Finance 30-37 net worth" is statistically ahead of 88% of their cohort. We don't claim that any specific behavior caused that ranking — many factors (inheritance, market timing, life events) are not captured.
• Predictive accuracy. Benchmarks describe the current population, not future outcomes. Being in the top quartile today doesn't guarantee being there next year; being in the bottom quartile doesn't mean you will stay.
• Equivalence across cohorts. "Top 25% in NYC Finance" and "top 25% in Nashville Healthcare" are not the same dollar number. The percentile is the comparison, not the absolute dollar amount.
• Survey representativeness. Our cohort populations are Keeping Up users — self-selected to use a personal finance app. They may skew higher-income or higher-engagement than the underlying US population. Where seed data is used, we note that explicitly.

Individual results may vary. A peer comparison is descriptive context, not personalized financial advice. For specific tax, legal, or investment decisions, consult a qualified professional.

8. Auditability

The methodology described here is auditable in three ways:

1. This page is versioned in our compliance documentation; material changes are published 30 days before they take effect.
2. The benchmark computation code is straightforward (percentile math on aggregated metrics). Third-party security researchers can request a code review under our responsible-disclosure policy at /security.
3. The cohort population at any point in time is observable through the "Confidence indicator" (sample size + computed-at timestamp) shown next to every benchmark in the app.

Questions about specific cohort numbers, methodology, or sampling are welcome at support@keepingup.com.

9. Changelog

We'll log material changes to this methodology here. The first version of this document was published on May 10, 2026.

• 2026-05-10: Initial publication.