Discrepancy Report | Criteo Commerce Grid Documentation

Overview

Commerce Grid supports a standardized DSP discrepancy reporting process to investigate differences in metrics.

This article explains how Commerce Grid validates submissions and communicates investigation outcomes.

Commercial value for DSPs and Publishers

Discrepancies are a normal part of programmatic reporting. A standardized discrepancy intake and investigation process helps:

Protect revenue by enabling early detection of underbilling or overbilling
Build trust with DSPs and advertisers through transparent, consistent handling of reporting differences
Improve operational efficiency by reducing manual checks and repeated back-and-forth on formats, identifiers, and methodology
Set clear expectations on how discrepancies are handled and what outcomes are possible

Reporting & Billing Data

Commerce Grid reporting and DSP reporting systems are independent.

They are used according to the contractual agreements between the parties.

For Commerce Grid–managed supply, billing, payout, and IVT filtering are based on Commerce Grid logs. DSP-submitted reports may be used as supporting inputs during discrepancy investigations but do not override Commerce Grid reporting unless explicitly defined by contract.

DSP-submitted reports support reporting system alignment, enabling early detection of discrepancies and improving overall reporting reliability.

Billing and publisher payout are determined according to commercial agreements. Commerce Grid logs and DSP-reported data are used together during discrepancy investigations and validation. Any financial adjustments follow internal approval processes.

When discrepancy reporting is used

DSP-submitted reports are used by Commerce Grid teams to monitor and track discrepancies over time and to proactively identify potential issues before month-end close.

This reporting process supports early detection of:

Persistent variance trends across days or reporting periods
Potential financial risk (under- or over-billing)
IVT classification differences
Technical or integration-related issues (e.g., identifiers, time zones, delivery logic)

DSP reports are reviewed on an ongoing basis, rather than only in response to a single-day variance.

How to submit a discrepancy report

First, contact your Criteo representative to confirm the required report mapping.

Once confirmed, send the discrepancy request by email with the supporting report attached to grid-dsp-reports@criteo.com.

Submission guidelines

One report file per email
Supported formats: CSV or XLSX

Reporting frequency & data window

Reports should be submitted on an agreed reporting cadence (for example, daily (recommended) or weekly ), aligned with the commercial agreement.
The reporting period should include complete and finalized DSP data.
DSP data for very recent days (for example, the last few days) may still be subject to delays, corrections, or adjustments.
To ensure data completeness, the reported date range should either:
- exclude incomplete periods, or
- overlap recent, potentially incomplete days across consecutive submissions until data is finalized.
File naming convention:
- Use a clear and consistent file name that includes:
  - DSP name
  - Reporting date or date range
  - Report type (e.g. revenue or IVT)
  - Time zone

Example:

DSPName_RevenueReport_2024-06-01_to_2024-06-07_UTC.csv

DSP Spend Report- Format and Schema

Supported file formats

CSV (.csv) — UTF-8 recommended
Excel (.xlsx)

Column name	Required	Type	Description (for DSP)	OpenRTB source (if applicable)
Date	Yes	string	Date for which you report aggregated metrics. Send in YYYY-MM-DD format. The time zone is defined by the Time Zone column if present; otherwise, use the default reporting time zone agreed between the DSP and Commerce Grid (e.g.UTC).	N/A
Impressions	Yes	integer	Number of billable impressions for the given date and dimension combination (deal, creative, etc.). Unless agreed otherwise, this should include both valid and IVT impressions, with IVT broken out separately in IVT Impressions	N/A
Spend	Yes	decimal	Total media spend for the given date and dimension combination, reported in the agreed billing currency.	N/A
Publisher Id	Recommended	string	Publisher identifier as seen in the bid request. Send exactly the value from site.publisher.id (web) or app.publisher.id (in-app).	site.publisher.id / app.publisher.id
Creative Id	Recommended	string	DSP internal creative identifier used in reporting. Send the same value included in the OpenRTB bid response Bid.crid field.	seatbid[].bid[].crid
Deal Id	No	string	Deal identifier when the impression was delivered via a PMP or PG deal. Send the same value as seen in the bid request. Leave empty if the impression was not served via a deal.	imp[].[pmp.deals][].id
Time Zone	No	string	Time zone used to interpret the Date. Use IANA time zone identifiers (e.g. UTC, Europe/Berlin, America/New_York). All rows in a single file must use the same time zone.	N/A
Creative Type	No	string	High-level creative type (e.g. banner, video, native, audio). Values should be consistent across all reports.	Derived from imp[].banner, imp[].video, imp[].native, etc.
Media Type	No	string	Media channel classification (e.g. display, video, CTV, audio). The allowed values should be agreed between the DSP and Commerce Grid.	Supported values:
display
video
audio
native
Inventory Type	No	string	Inventory environment (e.g. web, app, CTV, DOOH). Used to distinguish delivery environment.	Supported values:
application
website
IVT Impressions	No	integer	Number of impressions classified as invalid traffic (IVT) according to the DSP’s IVT logic. This is a subset of total Impressions.	N/A
IVT Spend	No	decimal	Portion of Spend attributed to IVT Impressions, reported in the same currency as Spend.	N/A

Data Requirements

Date format

The Date column must use the following format:

YYYY-MM-DD

Example:

2024-06-01

Numeric values

The following columns must contain numeric values only:

Impressions, Spend, IVT Impressions, IVT Spend

Numeric fields must follow these rules:
- no extra characters (for example, no spaces, currency symbols, or text comments)
- no thousand separators (10000, not 10,000 or 10 000)
- use a dot (.) as the decimal separator for fractional values (for example, 75.50, not 75,50)

Identifiers

Values in the DSP Creative and Ads.txt Id columns must match the identifiers previously agreed between the DSP and Commerce Grid.
Consistent identifiers are required to ensure accurate data matching during investigation.

File time zone constraint

All rows in a single report file must use the same time zone. Mixed time zones are not allowed.
If included, use standard IANA identifiers (e.g., UTC, Europe/Berlin, America/New_York).

Example CSV

Date,Ads.txt id,DSP Creative,Impressions,Spend,Deal Id,Creative Type,Media Type,Inventory Type,IVT Impressions,IVT Spend
2024-06-01,1001,2001,15000,75.50,3001,Banner,Display,Web,1,2.00
2024-06-01,1002,2002,25000,125.00,3002,Video,Video,App,3,6.00

How the reconciliation process works

Submission

DSP sends a discrepancy email with the CSV/XLSX attachment to grid-dsp-reports@criteo.com.

Intake & Validation

Commerce Grid validates scope and checks the report format (columns, data types, time zone, identifiers).

Why reporting discrepancies occur

Typical causes include:

Timing & Time Zones

Different report time zones (e.g., UTC vs local)
Data latency or late-arriving events

Counting Methodology

Bid win vs ad render counting
Handling of partial or aborted loads

Traffic Filtering

Differences in IVT detection
Post-bid filters applied by Commerce Grid

Technical Factors

Request timeouts, network interruptions
Placement / GPID mapping inconsistencies