Skip to main content

why doesn't my number match?

whatever two numbers you're comparing — your chart, a video, what's in play, another report page — a mismatch comes down to one of six settings. the checklist, plus the quirks specific to each pair.

Written by Brad

summary: whatever two numbers you're comparing — your own chart, a video, what's in play, another report page — a mismatch almost always comes down to one of six settings. work the checklist, then read the section for the specific pair you're comparing.

if a number you measured disagrees with what edgeful shows, you're almost never looking at a bug. you're looking at two things configured differently.

this is the same checklist edgeful AI walks through when you ask "why doesn't my number match" — so if you've worked through it and the numbers still disagree, that's when it's worth flagging to us.

the six settings that change a number

these are ordered most-common-first. each one has a deep-dive article if you want the full mechanics.

1. timezone. edgeful runs every report on a fixed timezone. if your TradingView chart is on local or exchange time, your session windows land on different candles than ours — a "session high" at 9:30 EST is a different number than one at 9:30 your time. on TradingView, click the clock at the bottom right and set it to New York (UTC-5/-4).

2. session window. every number is tied to the exact window it measured — an IB "first hour" in NY means 9:30–10:30 EST. futures also roll to a new day at 6pm ET, not midnight, which moves what "previous day" means. see the 6pm session rollover explained.

3. contract, and whether you're straddling a rollover. if your chart is on a continuous contract like NQ1! and the report measured a front-month, or your range spans a roll date, the prices won't line up. a gap that looks like a huge overnight move is often just the contract rolling. see futures contract rollovers.

4. wick vs close. "did price reach this level" and "did price close beyond it" are two different questions with two different answers. many reports have a by-close variant, and which one you're on changes the number. see wick vs close — and what "broken" means across reports.

5. date range. the range changes the number, because it changes which sessions are in the sample. a stat over 3 months and the same stat over 2 years are measuring different sets of days. see how far back does edgeful data go.

6. subreport and customization. standard, by close, by rejection, and by weekday all measure different things, and per-report settings — IB window, ORB duration, opening candle size, fill threshold — change the setup itself. check both the subreport dropdown and the customize panel.

work down the list and compare again. if the numbers still disagree, the pair you're comparing has its own quirk — the next two sections cover the common ones.

comparing what's in play to a report page

this is the pair that produces the biggest gaps, and it has its own article: why what's in play and the report page show different percentages. the short version — three things differ:

  • WIP caps its history at 2 years. its lookback options are 3 months, 6 months, 1 year and 2 years; the report page's date-range selector goes further still, back to May 2018 with manual dates. match them in whichever direction suits you — but if you need more than 2 years of history, only the report page can go there.

  • WIP is conditioned on the live session. the report page asks how often this happened across every session in your date range. WIP asks how often it happened on the sessions that looked like today. a narrower, more specific sample gives a different percentage — that isn't drift, it's the read you are on WIP for.

  • the two sets of settings are independent. a 60-minute IB on WIP against a 30-minute IB on the report page is two different setups, and the window length alone can move a rate several points.

if WIP and a report disagree on which side formed first rather than on a percentage, that's a session-window mismatch specifically — see why your bias shows the high (or low) formed first.

comparing against a video or a stream

a video was recorded on a past date, with whatever date range, session, ticker, and settings the host had up at the time. the setup drifts from your defaults, and the data itself has moved on since — every session that has printed since recording is in your sample and not in theirs.

match the date range first, then the session and ticker, then the subreport and customization. the numbers should converge. if they don't, run the six checks above.

small samples move fast

once a sample is narrowed — by a short lookback, a weekday cut, or WIP's live conditioning — the count behind the percentage gets small, and small samples swing. at 30 occurrences one session moves the rate about 3 points; at 9 occurrences it moves it 11.

always read the occurrence count next to the rate. on WIP, the frequency filter drops thin cards off the dashboard for you.

IB reports: the day counts look wrong

two things on the initial balance reports look like bugs but aren't: days going "missing" when an IB-size filter is set, and the retracement level counts not summing to your total days (they're cumulative, so one day is counted at every level it reached). both are explained in how to read and trade the initial balance (IB) report.

still doesn't match?

if you've worked the six checks, accounted for the pair you're comparing — and the number still disagrees with a healthy occurrence count behind it — that's worth reporting.

reach out through the chat bubble and tell us the report, ticker, session, and what you measured vs what edgeful showed. we'll take a look.

related articles

Did this answer your question?