Direct answer
To assess slippage, collect data that links an order’s intent to the actual execution outcome. At minimum, you need the intended execution price (or decision reference), the executed price, the timestamps that place those events on the same time axis, and the related execution costs (for example, spread and commissions) so you do not mistake “price movement” for “fees” or “quote effects.” Also record where the data comes from (platform, broker report, or order ticket) and how complete it is.
Mechanism and definition
Slippage is the difference between the price you expected when you placed or confirmed an order and the price you actually got when it filled. In practice, assessment depends on which “expected price” you choose:
- Order-side reference price: the price shown at order submission or at order approval.
- Quote-side reference price: a mid/ask/bid level observed near the order decision time.
- Execution-side reference price: a price recorded by the execution venue or trading system at the moment the broker accepts the order.
These choices matter because slippage can be computed different ways. To keep calculations meaningful, state your assumption explicitly, for example: “slippage = executed price − reference price for a buy, using the quote recorded at order confirmation time.”
Separate components that may look similar:
- Market movement: price changes while the order waits to be executed.
- Execution constraints: how your provider routes orders, handles liquidity, and applies available prices.
- Transaction costs: commissions, financing, or other fees that can shift your effective cost.
If you treat costs as slippage, your assessment may overstate the execution gap.
Evidence, example, and what data to record
A self-contained slippage record for a single order typically needs:
- Instrument details: symbol/currency pair identifier and contract size (to avoid mixing instruments).
- Side and order type: buy/sell and whether it is market/limit; execution logic differs.
- Intended/reference price: the price you used as “expected” (and where you got it).
- Executed price: the fill price(s) you actually received.
- Timestamps: time of order submission, time of acceptance/confirmation, and time of each fill. Use a consistent timezone or include timezone offsets.
- Fill structure: whether the order filled once or in parts; if partial fills occurred, record each fill and total quantity.
- Cost breakdown: at least commissions and any documented fee components that affect net execution cost.
- Data provenance and completeness: whether the values come from an order ticket, execution report, ledgers, or system logs, and whether any fields are missing.
Concrete calculation example (assumption required):
- Assume your reference price is the quote shown at order confirmation time.
- For a buy order, compute slippage_points = executed_price − reference_price for each fill, then compute a quantity-weighted average slippage if there are multiple fills.
- If you want slippage in cost terms, convert price difference using contract size, and then separately add documented commissions to avoid mixing “execution price difference” with “fees.”
Limitations and risks (material failure modes)
Several limitations can make slippage assessment unreliable:
- Reference-time mismatch: if your “expected price” is recorded at a different moment than the execution decision, the computed slippage can reflect timing misalignment rather than execution quality.
- Partial fills and aggregation errors: averaging incorrectly across multiple fills (or ignoring that fills occurred at different times and prices) can misstate slippage.
- Missing or altered fields: if execution reports omit certain events, or if the platform rewrites prices during reconciliation, your dataset may not match the true execution timeline.
- Cost confusion: spreading costs (bid/ask) and commissions can be confused with price slippage unless you separate “effective price” and “fee components.”
- Non-stationary relationships: any historical relationship between slippage and conditions does not guarantee future behavior; market liquidity and volatility can change.
The safest way to handle uncertainty is to treat slippage as a computed metric that depends on your chosen reference definition and data integrity, not as a single universal number.
Verification and next question
To independently verify your facts, you should be able to point to the exact fields used for reference price, executed price, and timestamps, and confirm they come from the same execution lifecycle (order ticket vs. execution report).