Measurement

Investigating impression discrepancies without guessing

Normalize scope and definitions before comparing two reporting systems.

Skills Labs Tech editorial · Updated 30 September 2026 · 6 min read · Educational examples

Align the reporting contract

Before comparing numbers, write down the reporting date range, timezone, currency where relevant, account, inventory filters, and event definition. A request, served impression, rendered impression, and viewable impression describe different events. An apparent discrepancy can be a measurement mismatch rather than a lost event. Do not subtract totals until both reports describe the same scope.

Use an explicit denominator

If system A reports 100,000 impressions and system B reports 94,000, the difference relative to A is 6%. Relative to B it is approximately 6.38%. Neither denominator is universally correct. Name the reference system and calculate consistently. The discrepancy calculator on this site uses A as its reference and keeps the sign so the direction remains visible.

Work from aggregate to segment

Break the comparison into date, inventory, integration type, device category, and creative format where both reports support those dimensions. Begin with the largest absolute differences. A small segment can have a large percentage difference without explaining the overall business impact. Keep low-volume segments separate rather than over-interpreting their rates.

Inspect event timing and loss

Check whether either report is delayed, uses different deduplication rules, filters invalid traffic, or counts at a different stage of delivery. Then investigate timeout behavior, abandoned page loads, blocked requests, and creative render errors. These are hypotheses to test, not a list of confirmed causes. Match anonymized event traces where access and privacy rules allow it.

Define a sustainable response

Document the accepted reference, reporting delay, known exclusions, and escalation conditions with both parties. Reconcile after the agreed reporting window closes. Store a repeatable query or export procedure rather than manually comparing screenshots each day. A product fix should improve the definitions or missing observability as well as the immediate incident.

Build a reconciliation worksheet

Create a worksheet with one row for each aligned segment and columns for system A, system B, absolute difference, relative difference, and investigation status. Add the source report names and extraction times. Keep the filtering contract next to the data: date range, timezone, inventory scope, and event definition. This makes the comparison reproducible when another person reruns it. Use unrounded counts for calculations and reserve formatting for display. If one source has not finished processing, label the comparison provisional. A neat percentage is less useful than knowing whether the underlying exports describe the same period and the same kind of impression.

Work through an illustrative segmentation

Suppose the reference system reports 100,000 impressions and the other system reports 94,000. Divide the scope into two fictional placements. Placement one has 80,000 versus 78,000; placement two has 20,000 versus 16,000. The second placement explains 4,000 of the 6,000 missing events despite being the smaller segment. Its relative difference is 20%, compared with 2.5% for the first placement. Investigating the largest reference segment alone would miss the primary contributor. These numbers demonstrate prioritization, not a normal or acceptable discrepancy threshold. The appropriate threshold depends on the measurement contract and operational context.

Check timezone boundaries explicitly

A daily report is a window of time, not simply a date label. Two systems can label a report with the same calendar date while including different hours. Convert the start and end boundaries into an agreed timezone and verify daylight-saving behavior where relevant. Use interval boundaries consistently so an event at midnight is neither excluded from both reports nor included twice. Compare hourly data around the boundary if the systems support it. When exporting reports, record the configured reporting timezone rather than relying on the timezone shown by the operator’s browser or computer, which may be unrelated.

Identify the counting event

Ask each system what creates an impression record. One may count a server-side response while another waits for a browser event. A visitor who leaves between those stages can legitimately appear in one total and not the other. Also ask how failures, retries, duplicate notifications, and invalid traffic are handled. The purpose is not to force every report to use the same event, but to make the relationship between reports explicit. Once the definitions are clear, document which losses are expected at the boundary and which unexplained changes require an investigation into the integration or measurement pipeline.

Use samples without overstating them

When event-level access is available and authorized, sample identifiers from a high-difference segment and follow them across the relevant boundary. Record whether each sample reached the second system and whether its count was eligible there. A small sample can suggest a cause, but it should not be presented as a precise population estimate without an appropriate sampling design. If the sample is chosen only from failures, it cannot describe the overall failure rate. Keep the evidence and conclusion separate: observed missing callbacks support a callback hypothesis, while the reported percentage still comes from the aligned aggregate data.

Make corrections traceable

If a discrepancy is caused by an incorrect filter or a reporting definition, correct the report and record why the previous comparison was misleading. If it is caused by delivery behavior, describe the fix and the expected change at the counting boundary. Retain a before-and-after comparison using equivalent scopes. Avoid silently editing historical totals without a documented process, because other teams may already have used them for billing or performance analysis. A reconciliation record should distinguish restated reporting from changes to actual delivery. Both can improve agreement between systems, but they have different business and accounting implications.

Turn recurring issues into observability

A recurring discrepancy should produce a better operational signal. Add a metric for the handoff being investigated, a documented reporting-delay window, or a reason code for the relevant rejection. Set alerts around a meaningful change rather than a percentage that ignores volume. A tiny segment fluctuating by a few events should not generate the same escalation as a large revenue-bearing placement losing a substantial share of its delivery. Include an owner and an action in the alert definition. The purpose of observability is to help someone decide what to investigate next, not to create another unexplained number.

Apply this guide with anonymized fixtures. Add your own verified operational examples when documenting a real integration.