NQ and MNQ Order Flow: Ticks, Size and Settings

Most footprint guides stop at the notation. If you already trade Nasdaq futures, the open question is which setting is making your chart unreadable — and which ones you inherited from a market you no longer trade. Contract, tick, aggregation, bar type, imbalance threshold, session: in that order, because each changes the meaning of the next.

NQ and MNQ order flow: two contracts, two tapes

NQ and MNQ are two distinct CME futures contracts written on the same Nasdaq-100 index, each with its own order book, its own executions and its own volume. They move together because the underlying index is identical, but nothing about the order flow is shared: a trade printed on the Micro is not printed on the E-mini.

The practical NQ vs MNQ difference is what one contract represents. One E-mini carries the index exposure of ten Micros, so a size filter or a “large trade” threshold expressed in contracts does not carry over. How size actually splits across prints is something to measure on your own feed, not to assume from the product name.

Check three things on the chart title before you touch a setting:

• The root. NQ or MNQ — not a lookalike symbol from another data source or a CFD proxy.
• The contract month. These contracts expire and volume migrates at the roll; a thin tape is often just an expired front month.
• Continuous or single-month. A stitched series is convenient for price history and misleading for order flow: two different books are glued together at the roll.

Contract specifications to read at the exchange source

Every number below comes from the CME Group contract specification for each product. Specs change; read them at the source rather than trusting a table copied into a blog post — including this one.

Because the tick is 0.25 index points on both, the two footprints share a price grid while counting the size on it in units that are not comparable: restate any volume filter or bar size when you switch product.

MNQ tick size on a footprint chart: one session, two pictures

Price aggregation is the number of exchange ticks a footprint groups into a single row. At one tick per row, an MNQ footprint chart prints a row every 0.25 index points; at four ticks per row, every full index point. The executions are identical in both cases — only the grouping of the display changes.

On a Nasdaq contract a single bar can span a wide range in index points. Unaggregated, it becomes a column of thin rows carrying a handful of contracts each; aggregated too hard, distinct levels merge and the bid × ask detail that justifies a footprint disappears.

The trap is that aggregation is not only cosmetic:

• Imbalances move. Diagonal comparisons are computed between the rows you display, so regrouping changes which comparisons exist and which cross the threshold.
• Stacking changes. Three consecutive flagged rows at one tick are not the same event as three at four ticks.
• Profile references shift. The point of control and the value-area edges are read off the aggregated rows; see how a volume profile is built.

Fix the grouping for the whole sample and never compare two sessions read at different groupings. New to the notation? Start with how to read a footprint chart.

Choosing a bar type on a fast contract

A bar type is the rule that decides when the current bar closes and a new one opens. On a contract that alternates between bursts and near-silence, it decides how much information each footprint column carries.

None of these is the right answer; switching between them mid-observation is the wrong one. Fixed activity per bar — tick or volume — fills cells more evenly, at the cost of a time axis that is no longer linear.

Imbalance thresholds: why a ratio tuned on ES misreads NQ

A footprint imbalance is a diagonal comparison — the bid volume at one price against the ask volume at the price above or below — flagged when the ratio between the two exceeds a threshold you set. The threshold is a display convention, not a market constant, which is exactly why it does not travel.

Contracts with different queue behaviour produce different per-level distributions:

• Size per level. Where a book concentrates size at one price, the ratio test has a large denominator and fires rarely; where levels are thinner, the same ratio fires constantly on small absolute numbers.
• Aggregation interacts with the ratio. Grouping four ticks into one row sums four levels of size before the comparison, so a threshold derived at one tick per row is not the same test at four.
• The minimum-size filter does most of the work. Without one, a 3-against-1 comparison on tiny volume counts as much as a 300-against-100 — one common reason a chart looks “covered in imbalances”.

To re-derive your own settings instead of importing them:

1. Fix the contract, session definition and aggregation, and write all three down.
2. Keep the default ratio and count flagged levels per bar over a defined sample.
3. Raise the minimum-size filter first: it removes flags carrying no size.
4. Adjust the ratio after that, only enough that flags stay examinable.
5. Re-run the same count on a second, non-overlapping sample before keeping the values.

What the flag means does not change with the threshold — see order flow imbalance explained for how stacked diagonals and absorption are read.

Session boundaries: regular hours against the full session

Nasdaq futures trade nearly around the clock, so “the session” is a definition you choose, not a fact the data hands you. A full-session chart includes the overnight activity that formed the levels price is reacting to at the cash open; a regular-hours chart removes it and produces a cleaner, smaller picture of the day.

The choice propagates further than most settings:

• The volume profile, its point of control and its value area are computed on the window you declared.
• Cumulative delta resets at the session boundary, so a different boundary means a different curve.
• A session-anchored VWAP starts where the session starts, by construction.

It is also the usual explanation when totals disagree between two tools: two windows, and sometimes two contract months. The failure mode is documented in why footprint volume does not match your broker; the check never changes — one contract month, one session definition, one window.

Data and entitlements, billed separately from the software

Exchange market data for CME futures is charged by the data source and the exchange, separately from any charting subscription. Order flow also needs more than a price feed, and each capability is entitled on its own: live executions with an aggressor side, resting depth for the DOM and the liquidity heatmap, historical trades for replay, and historical depth — which cannot be reconstructed from trades alone.

If you connect through Rithmic, the credentials and the system name come from your broker or prop firm, and what the account permits varies with it: a working login does not establish depth access, historical coverage or order-routing permission. The Rithmic connection and data checklist lists what to confirm with the provider; Databento CME data and crypto venues are separate paths with their own terms (see data feeds).

How Senzoukria shows it

Senzoukria is a native Windows desktop application, with macOS and Linux builds in beta. On a Nasdaq futures contract it renders a bid × ask footprint from your own connection — Rithmic, a local NinjaTrader bridge or Databento CME data — with the settings above exposed directly: tick aggregation per row, five bar types (time, tick, volume, range and delta) anchored on the session rather than on when you opened the chart, imbalance and absorption highlighting, and sixteen cell types.

Alongside it: a DOM and a liquidity heatmap built from depth updates when your feed carries them, cumulative delta and volume profile on the same canvas, and CSV export of the loaded bars. Gamma exposure views are conditional — they need a separate options data source and are not derived from the futures tape. Crypto instruments (Binance spot and perpetuals, Bybit) are supported for analysis, which is not order routing. Manual order entry exists on supported connections, and the optional strategy autopilot sends orders only after a human arms it explicitly, with risk limits and a STOP control. Pricing is $9 for the first month, then $29 per month or $240 per year (see pricing); exchange and market-data charges are billed separately by the data source.

A starting configuration, and how to test it

A starting point, not a recommendation with any expected result: every value here is a convention to be replaced by your own measurement.

Record those six values, the dates and the data source, then change one setting at a time and compare the counts on a second, non-overlapping sample. Only once the display is stable is there anything worth turning into a written rule and evaluating with realistic costs — the method is in the futures backtesting guide.