Filtering Analytics
Historical context for filtering decisions. Analytics turns rejection records into pass-rate KPIs, category and source comparisons, and a ranked list of the rules affecting the most tokens.
Presets
1H, 6H, 24H, 7D, or All
Custom
Exact start and end timestamps
KPIs
Scanned, passed, and rejected
Breakdown
Category, source, and reason
What the Analytics tab is for
Use Analytics when Status tells you what is happening now but you need to understand whether it is normal. Select a preset or custom time range, compare total scanned, passed, and rejected tokens, then identify which categories and exact reasons shaped the outcome.
Reading the interface
Each area answers a different operational question. Use the descriptions below before changing a filter.
Time controls
The selected period changes every KPI and ranking in the view.
Preset ranges
Use 1H or 6H for immediate tuning, 24H or 7D for broader behavior, and All for the complete retained history.
Custom range
Choose exact timestamps when comparing filtering behavior with a deployment, configuration change, or market event.
Outcome KPIs
The top row establishes the scale and selectivity of the chosen period.
Total Scanned
The number of filtering decisions included in the selected range.
Passed Tokens and pass rate
The successful outcomes and their percentage of all evaluated tokens.
Rejected Tokens and rejection rate
The rejected outcomes and their percentage of the evaluated set.
Rejection comparisons
Two charts answer whether rejection pressure comes from a class of risk or a particular provider.
By Category
Groups related reasons, such as liquidity, volume, authority, holder distribution, or data quality.
By Source
Compares Core, On-Chain, DexScreener, GeckoTerminal, RugCheck, and AI decisions where applicable.
Top rejection reasons
The table identifies the exact rules with the greatest impact.
Count and percentage
Shows absolute frequency and share of rejections for each rule.
Relative impact bar
Makes the strongest rejection reason visually comparable with the rest of the top ten.
Recommended workflow
- 1
Start with a time range that includes enough decisions to avoid reacting to a tiny sample.
- 2
Compare pass rate with the same range you normally use for operational review.
- 3
Identify the dominant category, then confirm which source and exact reason produced it.
- 4
Open Explorer for the dominant reason and inspect representative tokens before changing a threshold.
Practical guidance
- Use a short range immediately after a configuration change and a longer range before adopting it permanently.
- A dominant missing-data reason should be investigated as a provider or enrichment issue before loosening quality rules.
- Analytics measures filtering outcomes, not trading profitability; validate strategy performance separately.
Do not tune a safety threshold from pass rate alone. First inspect the affected tokens in Explorer and confirm that the rule is rejecting good candidates rather than correctly removing risk.