Audit the construction of auction profiles · 3 / 5
Composite volume profile: merge sessions without duplicates
A session POC discards most of the distribution that produced it. Two POC values cannot reconstruct a composite profile. Preserve the underlying price rows and check which trades belong to each window.
Athenum8 minUpdated:
Make session membership unambiguous
Use invented UTC windows on 2026-09-22: Early is [09:00, 10:00) and Late is [10:00, 11:00). A square bracket includes the start; a closing parenthesis excludes the end. A trade exactly at 10:00 belongs to Late only. These windows are a study definition, not an exchange schedule or a claim about an optimal session anchor.
The table is the complete hypothetical trade ledger, with one trade per row. A real reconstruction additionally needs stable trade identifiers, consistent quantity units, venue and instrument scope, and a policy for corrections or late arrivals. Missing records are not evidence of zero activity. Fix membership before comparing levels.
Preserve sufficient information for the merge
For a composite volume profile, align prices or compatible buckets and add their volumes. Compute the maximum only after that merge. A session's maximum alone does not preserve the other rows, so averaging session POCs, even with volume weights, generally cannot recover the composite POC.
VWAP behaves differently because its numerator and denominator are additive. Preserve each session's sum of actual price times quantity and its total quantity, add the respective totals and divide. Do not confuse this weighted-average identity with an averaging rule for maximum locations. Incompatible bucket grids require reconstruction or an explicitly described approximation before merging.
The composite maximum is calculated after aggregation
Early contains 10 units and has POC 98; Late contains 13 and has POC 100. Merge the rows to get 8 units at 98, 9 at 100 and 6 at 102. Total quantity is 23, and the composite POC is 100. The simple average of session POCs is 99, which is not that maximum.
Volume-weighting the session POCs gives 2,280 ÷ 23 ≈ 99.130435, also not the composite maximum. Actual price-times-quantity sums are 984 for Early and 1,312 for Late. Their combined 2,296 divided by 23 gives composite VWAP ≈ 99.826087 USD/unit. That result uses the actual trade-price sums, not the session POCs.
| UTC time | Price USD/unit | Volume, units | Window |
|---|---|---|---|
| 09:00:00 | 98 | 8 | Early |
| 09:30:00 | 100 | 2 | Early |
| 10:00:00 | 100 | 7 | Late |
| 10:30:00 | 102 | 6 | Late |
Open full-size diagram- Price 98: 8 units
- Price 100: composite POC: 9 units
- Price 102: 6 units
A stable POC can hide a broken population
If a boundary trade is counted twice, the maximum can remain at the same price even though the profile and VWAP are wrong. Comparing only the highlighted line is a weak reconciliation. Check total volume, weighted sums and unique trade membership against the source ledger.
Before acting
- Define timezone and endpoint inclusion for each session.
- Assign each trade to the intended population once.
- Align price rows and quantity units before addition.
- Find the composite maximum after merging the histogram.
- Reconcile volume and weighted sums, not only the POC.
Check your understanding
What happens if the 10:00 trade is included in both sessions before merging? Does an unchanged POC show that the merge is correct?
Show the explained answer
The 7 units at 100 are counted twice. Composite volume becomes 30, the 100 row becomes 16, and price-times-volume becomes 2,996. POC is still 100, but the erroneous VWAP is 2,996 ÷ 30 ≈ 99.866667. The unchanged line does not validate the population; the volume and unique-trade reconciliation expose the error.