Quants: Trader Cohort Analysis Using 900 Million Indexed Events

Quants: Trader Cohort Analysis Using 900 Million Indexed Events

Quants: Trader Cohort Analysis Using 900 Million Indexed Events

Quant playbook for trader cohort analysis: maturity filters, persona KPIs, and Assymetrix Data API workflows across 900 million indexed events.

Quants: Trader Cohort Analysis Using 900 Million Indexed Events

Trader cohort analysis on Polymarket and Kalshi data exposes three things retail dashboards never show: retention decay by entry month, performance concentration in a thin wallet tail, and behavioral splits between specialist and generalist traders. Run correctly, it turns raw fill and redemption logs into a reproducible research pipeline. A unified data API supplies the wallet-level history and canonical IDs needed to build that pipeline without stitching together three venues by hand.

TL;DR:

  • Most retail traders are part of a small, highly active tail that generates the majority of trading volume and profits, skewing performance metrics.

  • Cohort retention curves can be misleading if maturity filters are not applied, especially for recent entrants with limited observable history.

  • Segmentation by trader persona reveals that high-frequency, high-capital wallets disproportionately drive liquidity and should be analyzed separately.

  • Using normalized, cross-venue data from a unified API streamlines cohort construction and mitigates bias from wallet splitting and duplicate accounts.

  • Running cross-venue and persona-based validation improves the reliability of behavioral signals used for trading strategies.

AssymetrixBuild Cohort Models From Unified DataAssymetrix gives quants unified access to cross venue prediction market data for reproducible wallet level research and analysis.Explore Assymetrix

Table of Contents

  • What Is Trader Cohort Analysis in Prediction Markets?

  • How Do You Build Trader Cohorts From On-Chain Data?

  • Which KPIs Actually Measure Cohort Performance?

  • How Do You Segment Traders Into Persona Tiers?

  • What Do Cohort Studies Usually Find in Prediction Markets?

  • How Do You Implement This With the Assymetrix Data API?

  • Where This Should Change Your Research Pipeline

  • Get Wallet-Level Data to Build Your Own Cohort Models

  • Sources

  • FAQ

What Is Trader Cohort Analysis in Prediction Markets?

Trader cohort analysis groups wallets by a shared starting point, usually the date of their first trade, then tracks how that group behaves over fixed time horizons. In prediction markets, the standard horizons are 7, 30, 90, 180, and 360 days after entry, mirroring the relative-time cohort structure documented in Polymarket retention dashboards. A cohort formed in March 2026 gets measured against those same windows as a cohort formed in June 2026, which is what makes comparison valid instead of anecdotal.

Prediction markets are unusually good subjects for this kind of work. Every fill, split, merge, and redemption is a public on-chain event tied to a wallet address, with no anonymized aggregation layer sitting between the trade and the researcher. That is a sharp contrast with equities or most centralized exchanges, where individual account behavior is locked behind broker-dealer privacy walls. A quant studying Polymarket can reconstruct a wallet’s entire trading history since inception, categorize every position by market type, and compute realized P&L down to the individual contract.

Three questions dominate serious cohort work in this space:

  • Retention: What share of a monthly cohort is still placing trades 30, 90, or 360 days after their first one?

  • Intensity: How does trading volume per active trader change as a cohort ages?

  • Concentration: How much of total P&L and volume comes from a small subset of wallets versus the long retail tail?

Answering those three questions consistently is the difference between a cohort study that holds up to scrutiny and one that just describes last month’s dashboard numbers. The rest of this piece walks through construction, KPI definitions, segmentation, and the empirical patterns that tend to show up once the pipeline is built correctly.

How Do You Build Trader Cohorts From On-Chain Data?

Raw event logs are noisy. Before any cohort math happens, the data needs cleaning, and skipping this step is the single most common reason cohort studies produce misleading retention curves.

Start with the fields you actually need: wallet address, trade timestamp, market ID, position size in USD notional, trade direction, and resolution outcome where applicable. You also need split and merge events, since Polymarket’s conditional token mechanics let a single deposit generate multiple downstream trades that look like separate activity if you are not careful. Filter out known system addresses, contract deployers, and market-maker bots that would otherwise inflate your retail cohort counts.

  1. Assign a first-trade timestamp to every canonical wallet, after clustering addresses that share deposit patterns or deployer interactions to reduce wallet-splitting bias.

  2. Compute a relative-day column for every subsequent trade, measured as days since that wallet’s first trade rather than calendar date.

  3. Bucket wallets into cohort months based on their first-trade date, then apply a maturity filter so a cohort only reports 90-day retention once 90 calendar days have actually elapsed for every wallet in that group.

  4. Flag active days per wallet within each horizon window, defining “active” as placing at least one trade or redemption in that window.

  5. Aggregate KPIs at the cohort-month and window level, using active-trader counts as denominators rather than total cohort size, since that avoids diluting intensity metrics with wallets that already churned.

Maturity filtering matters more than most quant teams expect. Reporting 180-day retention for a cohort that only has 60 days of observable history biases the estimate and makes recent cohorts look artificially strong, a distortion the Polymarket cohort methodology explicitly filters against.

Pro Tip: Publish your wallet-clustering thresholds alongside the results. Two studies using different deduplication heuristics can produce meaningfully different profit-share numbers, and reviewers will ask.

For a minimum-observation rule, most production cohort studies discard any cohort month with fewer than a few hundred distinct wallets, since smaller cohorts produce retention curves that swing wildly on a handful of dropouts.


How Do You Build Trader Cohorts From On-Chain Data? — overview diagram

Which KPIs Actually Measure Cohort Performance?

Retention percentage alone tells you almost nothing about whether a cohort is healthy. A cohort that retains 20% of its wallets at 90 days but sees those wallets triple their trade frequency is behaving very differently from one that retains 20% at flat activity.

Four metrics form the operational core of most cohort dashboards:

  • Retention share: the percentage of a cohort’s original wallets that placed at least one trade within a given window, calculated separately for each of the 7/30/90/180/360 day horizons.

  • Average volume per active trader: total USD notional traded in a window divided by the count of wallets active in that same window, not the original cohort size.

  • Trades per active trader: total trade count in the window divided by active wallets, a proxy for engagement intensity independent of position size.

  • Average ticket size: notional volume divided by trade count, which flags whether a cohort is shifting toward larger, less frequent bets or smaller, more frequent ones.

The active-trader denominator is the detail that separates a rigorous KPI from a misleading one. If you divide total volume by the original cohort size instead of currently active wallets, a cohort that lost 80% of its members but trades heavily with the remaining 20% will look like it collapsed, when in fact the surviving traders became far more engaged.

For presentation, a pivot table with cohort month on the rows and horizon window on the columns is the standard layout, the same structure used in the Polymarket retention dashboard. Survival-curve line charts work well for retention trends across cohorts, while heatmaps make volume-per-trader concentration visible at a glance, especially when a handful of cohort months dwarf the rest in intensity.

How Do You Segment Traders Into Persona Tiers?

Retention and intensity metrics get more useful once you stop treating every wallet in a cohort as equivalent. A frequency times volume persona matrix is the standard next step: cross-tabulate trade frequency (trades per active week) against average position size (USD notional per trade) to produce tiers like low-frequency/low-volume retail, high-frequency/low-volume grinders, low-frequency/high-volume whales, and high-frequency/high-volume specialists.

Threshold-setting is subjective but should be grounded in your own data’s distribution rather than round numbers pulled from nowhere. A common approach splits wallets at the 90th percentile of trade frequency and the 90th percentile of average ticket size, which tends to isolate a small but disproportionately influential tier.

  • Onboarding category shifts persona mix substantially: wallets entering through sports markets tend to have higher-frequency, lower-ticket behavior, while election or macro market entrants often hold larger, less frequent positions, a pattern consistent with category-level persona analysis on Polymarket.

  • Persona stratification lets you prioritize where to look for tradable signal, since the high-frequency, high-capital tier tends to drive liquidity and price discovery disproportionately relative to its wallet count.

  • Running retention and intensity KPIs separately by persona, rather than pooling all wallets together, usually reveals that headline retention numbers are being carried almost entirely by one tier.

A small number of high-frequency, high-capital wallets typically account for an outsized share of total trading volume relative to their share of the wallet population, a pattern that shows up consistently in persona-based Polymarket analysis. Treating that tier as a distinct cohort, rather than folding it into the retail average, is what makes persona segmentation worth the extra construction effort. It also changes how you should think about experiment design: a signal that looks strong pooled across all wallets can vanish once you control for the fact that one tier is driving nearly all of the variance.

What Do Cohort Studies Usually Find in Prediction Markets?

Run the pipeline above on a few months of Polymarket data, and certain patterns show up reliably enough that you should treat their absence as a red flag in your own methodology, not a genuine anomaly.

Activity and profit concentrate hard in a thin upper tail. Independent analyses of Polymarket address-level data show that only a minority of wallets are net profitable, and that share is sensitive to how you treat unresolved positions and split/merge events in your P&L reconstruction, a caveat documented in detail in Andrey Sergeenkov’s Polymarket profitability analysis. Broader research on the platform confirms strong right-tail concentration in volume and trade counts, meaning a small number of addresses generate a disproportionate share of total activity, as shown in work on Polymarket win and loss distributions. Treat any specific profit-share percentage you compute as methodology-dependent rather than a fixed constant, and always disclose your splits/merges handling alongside the number.

Smart money wallets tend to show behavioral discipline that retail cohorts lack. Large-sample research on trading behavior finds that separating winning from losing traders often comes down to measurable habits, not just capital size: risk-reward ratio, win-loss holding-time ratio, and win-loss ROI ratio all differ systematically between profitable and unprofitable traders, based on prospect-theory research across more than 28 million trades. Feed those same metrics into your cohort feature set and you will often find that specialist wallets, those concentrated in one market category, hold positions longer relative to their win rate than generalist wallets spread across many categories.

Retail cohorts, by contrast, show herding signatures that correlate with worse outcomes. Correlated trading among retail investors, where large numbers of wallets pile into the same position around the same time, is associated with measurably worse investment performance, a finding that holds across broader retail investor research on correlated trading. When a cohort’s trade timing clusters tightly around major news events or category-wide price swings, that clustering itself is testable: split the cohort into “herding” and “independent” sub-groups by entry-timing dispersion and compare their forward returns. The divergence between smart-money and herding cohorts is exactly the kind of gap that turns into a usable signal once you validate it out of sample rather than just describing it in a single backtest window.


What Do Cohort Studies Usually Find in Prediction Markets? — overview diagram

How Do You Implement This With the Assymetrix Data API?

Reproducing the methodology above requires wallet-level trading history at a scale most researchers cannot scrape themselves. The Assymetrix Data API normalizes fills, redemptions, splits, merges, and market metadata across Polymarket, Kalshi, and Limitless into a single schema, which removes the venue-by-venue cleaning step that otherwise eats most of a cohort study’s build time.

The fields that matter for cohort construction map directly onto normalized endpoints: trade fills with timestamp and USD notional, redemption events for resolved positions, split and merge events to prevent double-counting synthetic trades, canonical market metadata for category tagging, and flags that can identify wallets already showing specialist trading signatures. That last field lets you skip building your own smart-money classifier from scratch for an initial pass, using it instead as a validation check against your own persona thresholds.

A typical extraction workflow looks like this:

  1. Pull first-trade timestamps for the wallet population in your target window using the fills endpoint, sorted by canonical wallet ID rather than raw address to avoid the wallet-splitting problem described earlier.

  2. Run windowed active-detection by querying trade and redemption events within each relative-time horizon per wallet.

  3. Aggregate KPIs (retention share, volume per active trader, trades per active trader) at the cohort-month level using the active-wallet counts from step two as denominators.

  4. Stratify by persona using trade frequency and ticket size computed from the same pull, cross-referenced against the API’s Smart Money flags for validation.

Pro Tip: Paginate by timestamp rather than offset when pulling large result sets. Offset-based pagination degrades badly once you are querying months of cross-venue history, and timestamp cursors keep query latency flat regardless of how deep into the dataset you go.

For sample size, cohort estimates stabilize meaningfully once a monthly cohort includes at least a few hundred distinct active wallets. Below that, the historical depth available through the API, spanning roughly 1.5 terabytes of cross-venue history, becomes the practical constraint rather than the query logic itself.

Where This Should Change Your Research Pipeline

Most cohort studies fail not on construction but on sequencing. Run retention sanity checks before anything else: if your 30-day retention curve is not monotonically declining across cohort months in a stable market environment, your maturity filters are probably wrong, not your data.

The real tradeoff is recency versus statistical power. Recent cohorts give you the freshest behavioral signal but the smallest observable windows, while older cohorts give you full 360-day maturity at the cost of describing a market structure that may no longer exist. Split the difference by running persona-stratified backtests on your oldest six mature cohorts before trusting any pattern from the newest one.

The next real step, once single-venue cohorts stabilize, is cross-venue comparison: does a wallet’s Polymarket persona predict its behavior on Kalshi, and does a Smart Money signal validated on one venue actually hold up on another. That is where cohort work stops being descriptive and starts generating testable trading signals.

— Dean

Get Wallet-Level Data to Build Your Own Cohort Models

A unified platform provides quant teams with canonical wallet IDs, normalized fills, and Smart Money flags spanning multiple prediction market venues in one schema, so cohort construction stops starting with three separate cleaning scripts.


Assymetrix

The Data API covers roughly 900 million indexed events across nearly a billion rows of historical trading activity, the depth of sample needed to run the maturity-filtered, persona-stratified cohort work described above without running into small-sample noise at the 180 or 360-day horizons. Developers building cohort pipelines in Python can start with the Python developer guide for query examples that map directly onto the extraction workflow covered in this piece, and teams focused specifically on Polymarket wallet history can review the cross-venue data guide for quants for schema details before writing a single query. Request access to the API to pull a sample dataset and validate your own retention curves against a cross-venue baseline.

Sources

FAQ

What Is an Example of Cohort Analysis?

A monthly cohort of wallets that made their first Polymarket trade in January 2026, tracked for retention at 7, 30, 90, 180, and 360 days after that first trade, is a standard example. Analysts compare that cohort’s retention curve and volume-per-active-trader trend against February’s and March’s cohorts to see whether newer entrants behave differently, a structure used in Polymarket’s own cohort dashboard.

What Is Cohort Analysis and How Does It Work?

Cohort analysis groups traders by a shared starting event, usually their first trade date, and measures their behavior over identical time windows so different groups can be compared fairly. It works by assigning each wallet a relative-day counter from its first trade, then aggregating retention, volume, and trade-frequency metrics per window using only wallets active in that window as the denominator.

How Many Wallets Are Usually in a Cohort?

There is no fixed number, but most production cohort studies discard any monthly cohort with fewer than a few hundred distinct active wallets, since smaller groups produce retention curves that swing sharply on a handful of dropouts. Larger cross-venue datasets, like the 900 million indexed events available through Assymetrix, make it easier to hit stable sample sizes across every horizon window.

What Is Cohort 1 and Cohort 2?

“Cohort 1” and “Cohort 2” typically refer to two sequential groups of wallets defined by different first-trade periods, such as wallets that entered in one calendar month versus the next. Comparing them isolates whether changes in retention, volume, or persona mix reflect a shift in the trader population itself rather than random noise in a single group.

Does Assymetrix Provide Data for Building Trader Cohorts?

Yes. The Assymetrix Data API provides normalized fills, redemptions, splits, merges, and canonical wallet IDs across Polymarket, Kalshi, and Limitless, the fields required for relative-time cohort construction described in this article. Pricing details for API access are available on the Assymetrix site.

Quants: Trader Cohort Analysis Using 900 Million Indexed Events

Trader cohort analysis on Polymarket and Kalshi data exposes three things retail dashboards never show: retention decay by entry month, performance concentration in a thin wallet tail, and behavioral splits between specialist and generalist traders. Run correctly, it turns raw fill and redemption logs into a reproducible research pipeline. A unified data API supplies the wallet-level history and canonical IDs needed to build that pipeline without stitching together three venues by hand.

TL;DR:

  • Most retail traders are part of a small, highly active tail that generates the majority of trading volume and profits, skewing performance metrics.

  • Cohort retention curves can be misleading if maturity filters are not applied, especially for recent entrants with limited observable history.

  • Segmentation by trader persona reveals that high-frequency, high-capital wallets disproportionately drive liquidity and should be analyzed separately.

  • Using normalized, cross-venue data from a unified API streamlines cohort construction and mitigates bias from wallet splitting and duplicate accounts.

  • Running cross-venue and persona-based validation improves the reliability of behavioral signals used for trading strategies.

AssymetrixBuild Cohort Models From Unified DataAssymetrix gives quants unified access to cross venue prediction market data for reproducible wallet level research and analysis.Explore Assymetrix

Table of Contents

  • What Is Trader Cohort Analysis in Prediction Markets?

  • How Do You Build Trader Cohorts From On-Chain Data?

  • Which KPIs Actually Measure Cohort Performance?

  • How Do You Segment Traders Into Persona Tiers?

  • What Do Cohort Studies Usually Find in Prediction Markets?

  • How Do You Implement This With the Assymetrix Data API?

  • Where This Should Change Your Research Pipeline

  • Get Wallet-Level Data to Build Your Own Cohort Models

  • Sources

  • FAQ

What Is Trader Cohort Analysis in Prediction Markets?

Trader cohort analysis groups wallets by a shared starting point, usually the date of their first trade, then tracks how that group behaves over fixed time horizons. In prediction markets, the standard horizons are 7, 30, 90, 180, and 360 days after entry, mirroring the relative-time cohort structure documented in Polymarket retention dashboards. A cohort formed in March 2026 gets measured against those same windows as a cohort formed in June 2026, which is what makes comparison valid instead of anecdotal.

Prediction markets are unusually good subjects for this kind of work. Every fill, split, merge, and redemption is a public on-chain event tied to a wallet address, with no anonymized aggregation layer sitting between the trade and the researcher. That is a sharp contrast with equities or most centralized exchanges, where individual account behavior is locked behind broker-dealer privacy walls. A quant studying Polymarket can reconstruct a wallet’s entire trading history since inception, categorize every position by market type, and compute realized P&L down to the individual contract.

Three questions dominate serious cohort work in this space:

  • Retention: What share of a monthly cohort is still placing trades 30, 90, or 360 days after their first one?

  • Intensity: How does trading volume per active trader change as a cohort ages?

  • Concentration: How much of total P&L and volume comes from a small subset of wallets versus the long retail tail?

Answering those three questions consistently is the difference between a cohort study that holds up to scrutiny and one that just describes last month’s dashboard numbers. The rest of this piece walks through construction, KPI definitions, segmentation, and the empirical patterns that tend to show up once the pipeline is built correctly.

How Do You Build Trader Cohorts From On-Chain Data?

Raw event logs are noisy. Before any cohort math happens, the data needs cleaning, and skipping this step is the single most common reason cohort studies produce misleading retention curves.

Start with the fields you actually need: wallet address, trade timestamp, market ID, position size in USD notional, trade direction, and resolution outcome where applicable. You also need split and merge events, since Polymarket’s conditional token mechanics let a single deposit generate multiple downstream trades that look like separate activity if you are not careful. Filter out known system addresses, contract deployers, and market-maker bots that would otherwise inflate your retail cohort counts.

  1. Assign a first-trade timestamp to every canonical wallet, after clustering addresses that share deposit patterns or deployer interactions to reduce wallet-splitting bias.

  2. Compute a relative-day column for every subsequent trade, measured as days since that wallet’s first trade rather than calendar date.

  3. Bucket wallets into cohort months based on their first-trade date, then apply a maturity filter so a cohort only reports 90-day retention once 90 calendar days have actually elapsed for every wallet in that group.

  4. Flag active days per wallet within each horizon window, defining “active” as placing at least one trade or redemption in that window.

  5. Aggregate KPIs at the cohort-month and window level, using active-trader counts as denominators rather than total cohort size, since that avoids diluting intensity metrics with wallets that already churned.

Maturity filtering matters more than most quant teams expect. Reporting 180-day retention for a cohort that only has 60 days of observable history biases the estimate and makes recent cohorts look artificially strong, a distortion the Polymarket cohort methodology explicitly filters against.

Pro Tip: Publish your wallet-clustering thresholds alongside the results. Two studies using different deduplication heuristics can produce meaningfully different profit-share numbers, and reviewers will ask.

For a minimum-observation rule, most production cohort studies discard any cohort month with fewer than a few hundred distinct wallets, since smaller cohorts produce retention curves that swing wildly on a handful of dropouts.


How Do You Build Trader Cohorts From On-Chain Data? — overview diagram

Which KPIs Actually Measure Cohort Performance?

Retention percentage alone tells you almost nothing about whether a cohort is healthy. A cohort that retains 20% of its wallets at 90 days but sees those wallets triple their trade frequency is behaving very differently from one that retains 20% at flat activity.

Four metrics form the operational core of most cohort dashboards:

  • Retention share: the percentage of a cohort’s original wallets that placed at least one trade within a given window, calculated separately for each of the 7/30/90/180/360 day horizons.

  • Average volume per active trader: total USD notional traded in a window divided by the count of wallets active in that same window, not the original cohort size.

  • Trades per active trader: total trade count in the window divided by active wallets, a proxy for engagement intensity independent of position size.

  • Average ticket size: notional volume divided by trade count, which flags whether a cohort is shifting toward larger, less frequent bets or smaller, more frequent ones.

The active-trader denominator is the detail that separates a rigorous KPI from a misleading one. If you divide total volume by the original cohort size instead of currently active wallets, a cohort that lost 80% of its members but trades heavily with the remaining 20% will look like it collapsed, when in fact the surviving traders became far more engaged.

For presentation, a pivot table with cohort month on the rows and horizon window on the columns is the standard layout, the same structure used in the Polymarket retention dashboard. Survival-curve line charts work well for retention trends across cohorts, while heatmaps make volume-per-trader concentration visible at a glance, especially when a handful of cohort months dwarf the rest in intensity.

How Do You Segment Traders Into Persona Tiers?

Retention and intensity metrics get more useful once you stop treating every wallet in a cohort as equivalent. A frequency times volume persona matrix is the standard next step: cross-tabulate trade frequency (trades per active week) against average position size (USD notional per trade) to produce tiers like low-frequency/low-volume retail, high-frequency/low-volume grinders, low-frequency/high-volume whales, and high-frequency/high-volume specialists.

Threshold-setting is subjective but should be grounded in your own data’s distribution rather than round numbers pulled from nowhere. A common approach splits wallets at the 90th percentile of trade frequency and the 90th percentile of average ticket size, which tends to isolate a small but disproportionately influential tier.

  • Onboarding category shifts persona mix substantially: wallets entering through sports markets tend to have higher-frequency, lower-ticket behavior, while election or macro market entrants often hold larger, less frequent positions, a pattern consistent with category-level persona analysis on Polymarket.

  • Persona stratification lets you prioritize where to look for tradable signal, since the high-frequency, high-capital tier tends to drive liquidity and price discovery disproportionately relative to its wallet count.

  • Running retention and intensity KPIs separately by persona, rather than pooling all wallets together, usually reveals that headline retention numbers are being carried almost entirely by one tier.

A small number of high-frequency, high-capital wallets typically account for an outsized share of total trading volume relative to their share of the wallet population, a pattern that shows up consistently in persona-based Polymarket analysis. Treating that tier as a distinct cohort, rather than folding it into the retail average, is what makes persona segmentation worth the extra construction effort. It also changes how you should think about experiment design: a signal that looks strong pooled across all wallets can vanish once you control for the fact that one tier is driving nearly all of the variance.

What Do Cohort Studies Usually Find in Prediction Markets?

Run the pipeline above on a few months of Polymarket data, and certain patterns show up reliably enough that you should treat their absence as a red flag in your own methodology, not a genuine anomaly.

Activity and profit concentrate hard in a thin upper tail. Independent analyses of Polymarket address-level data show that only a minority of wallets are net profitable, and that share is sensitive to how you treat unresolved positions and split/merge events in your P&L reconstruction, a caveat documented in detail in Andrey Sergeenkov’s Polymarket profitability analysis. Broader research on the platform confirms strong right-tail concentration in volume and trade counts, meaning a small number of addresses generate a disproportionate share of total activity, as shown in work on Polymarket win and loss distributions. Treat any specific profit-share percentage you compute as methodology-dependent rather than a fixed constant, and always disclose your splits/merges handling alongside the number.

Smart money wallets tend to show behavioral discipline that retail cohorts lack. Large-sample research on trading behavior finds that separating winning from losing traders often comes down to measurable habits, not just capital size: risk-reward ratio, win-loss holding-time ratio, and win-loss ROI ratio all differ systematically between profitable and unprofitable traders, based on prospect-theory research across more than 28 million trades. Feed those same metrics into your cohort feature set and you will often find that specialist wallets, those concentrated in one market category, hold positions longer relative to their win rate than generalist wallets spread across many categories.

Retail cohorts, by contrast, show herding signatures that correlate with worse outcomes. Correlated trading among retail investors, where large numbers of wallets pile into the same position around the same time, is associated with measurably worse investment performance, a finding that holds across broader retail investor research on correlated trading. When a cohort’s trade timing clusters tightly around major news events or category-wide price swings, that clustering itself is testable: split the cohort into “herding” and “independent” sub-groups by entry-timing dispersion and compare their forward returns. The divergence between smart-money and herding cohorts is exactly the kind of gap that turns into a usable signal once you validate it out of sample rather than just describing it in a single backtest window.


What Do Cohort Studies Usually Find in Prediction Markets? — overview diagram

How Do You Implement This With the Assymetrix Data API?

Reproducing the methodology above requires wallet-level trading history at a scale most researchers cannot scrape themselves. The Assymetrix Data API normalizes fills, redemptions, splits, merges, and market metadata across Polymarket, Kalshi, and Limitless into a single schema, which removes the venue-by-venue cleaning step that otherwise eats most of a cohort study’s build time.

The fields that matter for cohort construction map directly onto normalized endpoints: trade fills with timestamp and USD notional, redemption events for resolved positions, split and merge events to prevent double-counting synthetic trades, canonical market metadata for category tagging, and flags that can identify wallets already showing specialist trading signatures. That last field lets you skip building your own smart-money classifier from scratch for an initial pass, using it instead as a validation check against your own persona thresholds.

A typical extraction workflow looks like this:

  1. Pull first-trade timestamps for the wallet population in your target window using the fills endpoint, sorted by canonical wallet ID rather than raw address to avoid the wallet-splitting problem described earlier.

  2. Run windowed active-detection by querying trade and redemption events within each relative-time horizon per wallet.

  3. Aggregate KPIs (retention share, volume per active trader, trades per active trader) at the cohort-month level using the active-wallet counts from step two as denominators.

  4. Stratify by persona using trade frequency and ticket size computed from the same pull, cross-referenced against the API’s Smart Money flags for validation.

Pro Tip: Paginate by timestamp rather than offset when pulling large result sets. Offset-based pagination degrades badly once you are querying months of cross-venue history, and timestamp cursors keep query latency flat regardless of how deep into the dataset you go.

For sample size, cohort estimates stabilize meaningfully once a monthly cohort includes at least a few hundred distinct active wallets. Below that, the historical depth available through the API, spanning roughly 1.5 terabytes of cross-venue history, becomes the practical constraint rather than the query logic itself.

Where This Should Change Your Research Pipeline

Most cohort studies fail not on construction but on sequencing. Run retention sanity checks before anything else: if your 30-day retention curve is not monotonically declining across cohort months in a stable market environment, your maturity filters are probably wrong, not your data.

The real tradeoff is recency versus statistical power. Recent cohorts give you the freshest behavioral signal but the smallest observable windows, while older cohorts give you full 360-day maturity at the cost of describing a market structure that may no longer exist. Split the difference by running persona-stratified backtests on your oldest six mature cohorts before trusting any pattern from the newest one.

The next real step, once single-venue cohorts stabilize, is cross-venue comparison: does a wallet’s Polymarket persona predict its behavior on Kalshi, and does a Smart Money signal validated on one venue actually hold up on another. That is where cohort work stops being descriptive and starts generating testable trading signals.

— Dean

Get Wallet-Level Data to Build Your Own Cohort Models

A unified platform provides quant teams with canonical wallet IDs, normalized fills, and Smart Money flags spanning multiple prediction market venues in one schema, so cohort construction stops starting with three separate cleaning scripts.


Assymetrix

The Data API covers roughly 900 million indexed events across nearly a billion rows of historical trading activity, the depth of sample needed to run the maturity-filtered, persona-stratified cohort work described above without running into small-sample noise at the 180 or 360-day horizons. Developers building cohort pipelines in Python can start with the Python developer guide for query examples that map directly onto the extraction workflow covered in this piece, and teams focused specifically on Polymarket wallet history can review the cross-venue data guide for quants for schema details before writing a single query. Request access to the API to pull a sample dataset and validate your own retention curves against a cross-venue baseline.

Sources

FAQ

What Is an Example of Cohort Analysis?

A monthly cohort of wallets that made their first Polymarket trade in January 2026, tracked for retention at 7, 30, 90, 180, and 360 days after that first trade, is a standard example. Analysts compare that cohort’s retention curve and volume-per-active-trader trend against February’s and March’s cohorts to see whether newer entrants behave differently, a structure used in Polymarket’s own cohort dashboard.

What Is Cohort Analysis and How Does It Work?

Cohort analysis groups traders by a shared starting event, usually their first trade date, and measures their behavior over identical time windows so different groups can be compared fairly. It works by assigning each wallet a relative-day counter from its first trade, then aggregating retention, volume, and trade-frequency metrics per window using only wallets active in that window as the denominator.

How Many Wallets Are Usually in a Cohort?

There is no fixed number, but most production cohort studies discard any monthly cohort with fewer than a few hundred distinct active wallets, since smaller groups produce retention curves that swing sharply on a handful of dropouts. Larger cross-venue datasets, like the 900 million indexed events available through Assymetrix, make it easier to hit stable sample sizes across every horizon window.

What Is Cohort 1 and Cohort 2?

“Cohort 1” and “Cohort 2” typically refer to two sequential groups of wallets defined by different first-trade periods, such as wallets that entered in one calendar month versus the next. Comparing them isolates whether changes in retention, volume, or persona mix reflect a shift in the trader population itself rather than random noise in a single group.

Does Assymetrix Provide Data for Building Trader Cohorts?

Yes. The Assymetrix Data API provides normalized fills, redemptions, splits, merges, and canonical wallet IDs across Polymarket, Kalshi, and Limitless, the fields required for relative-time cohort construction described in this article. Pricing details for API access are available on the Assymetrix site.

Other Blog