How can Execution Price be measured?

Define Execution Price as a measurable field

Execution Price is the price at which an order (or part of an order) is actually filled. In practice, you measure it from the trade execution record that a platform or execution venue reports for a specific order fill. Because an order can be partially filled, the “execution price” you measure may exist as multiple fill prices rather than one single number.

A useful measurable definition is: Execution Price (per fill) = the executed trade price associated with an order-fill event. If you need one number for the whole order, you must define how to aggregate fills (for example, a weighted average using executed quantities). Without an explicit aggregation rule and a clear link between fills and the original order, “execution price” comparisons can be misleading.

Mechanism: what you can measure and how

To measure Execution Price independently, rely on fields that are typically available in order/trade history:

Executed price per fill: the price reported for each fill event.
Executed quantity per fill: how much was filled at that executed price.
Timestamps: at least one time value that indicates when the fill was recorded (and sometimes both “requested” and “executed” times).
Order identifier and fill linkage: an identifier that lets you connect each fill back to the specific order you submitted.

Aggregation example (assumptions required): If an order has two fills at prices P1 and P2 with executed quantities Q1 and Q2, then a common measurement is a quantity-weighted average execution price:

Weighted Avg = (P1·Q1 + P2·Q2) / (Q1 + Q2)

Assumptions you must state:

P1 and P2 correspond to the same quote basis (e.g., consistent price units) across both fills.
Q1 and Q2 are the same “quantity type” reported consistently.
Any costs included or excluded are clearly treated (for instance, whether the execution price field is “mid” versus “net” after certain fees depends on the provider).

Evidence or example: comparing measurement across time and fills

A practical way to verify your measurement is to compute it directly from the trade records you observe.

Choose a single order.
Extract every fill for that order: (executed price, executed quantity, timestamp).
Compute the per-fill execution price list.
If needed, compute the weighted average using the aggregation rule above.

Then compare two timelines rather than just two prices:

Order submission/request time (when the order was placed)
Fill record time (when the execution was reported)

Even if the fill timestamp differs from the quote that was visible when you requested the order, your measurement remains consistent as long as you always measure from the execution record’s executed price and its associated time. This distinction is important because real trading systems can report different timestamps for request and execution, and those timestamps may not be directly comparable across systems.

Limitations and failure modes

Execution Price measurement is constrained by several limitations:

Partial fills change the meaning of “the” execution price. If you treat multiple fills as one value without a defined aggregation method, results can vary.
Timestamp ambiguity. Some systems store the time when the fill was generated, received, or recorded. If you mix timestamp types when comparing execution quality, your conclusions may be invalid.
Provider-specific reporting. Different platforms and execution venues can format price and quantity fields differently, and some may separate execution price from other cost components. Without consistent definitions, “net vs. gross” comparisons can be wrong.
No guarantee of future repeatability. Historical execution patterns do not establish future execution results, especially when market conditions change.

Verification and next question to define

To independently verify Execution Price facts, you can document:

The exact order ID you used.
The list of fills (executed price, executed quantity, timestamp) for that order.
The aggregation rule (if converting multiple fills into one number).

If you still need a deeper comparison, the next question to clarify is how your chosen provider separates execution price from other transaction costs and whether the timestamp refers to request time, venue execution time, or reporting/record time. That clarification determines what “execution price” really measures in your dataset.