Deep Dive: Compression in Commerce Grid Reporting Tools | Criteo Commerce Grid Documentation
Compression Overview
Data Compression Overview
Data sampling, often referred to as compression in the context of Commerce Grid's reporting tools, is essentially taking a small, representative snapshot of a much larger dataset instead of examining it all.
Think of it like this:
You've cooked a huge pot of soup for a party of hundreds. Before serving, you need to check if it has enough salt and seasoning.
- The Full Data Set: The entire, huge pot of soup.
- The Data Sample: A single spoonful you taste.
You don't need to drink the whole pot to know if it's salty enough. Tasting just one spoonful gives you a quick, accurate-enough idea of the whole pot's flavor.
Compression in Commerce Grid Tools
Why Compression exists in some Commerce Grid tools
Some Commerce Grid reporting tools (u-Slicer and our APIs) use compression for two main reasons: speed and efficiency.
Speed
When you're trying to view a report or dashboard in our reporting tools, the underlying data set has billions of records (e.g., impressions, bids, etc), querying all of it takes a long time, potentially even hours hours.- Compression's Role: By looking at a smaller sample—say, 1% of the data—the tool can process the request much faster (in seconds) and display the report almost instantly.
Efficiency
All of our reporting tools are offered to our publishers free of any additional charge. Compression helps us maintain efficient costs to make this possible.
- Compression's Role: By querying a small amount of data and offering an accurate representation of the whole, we can maintain efficiency in our data processing and continue to offer tools that provide value to customers at no additional charge.
Where Do I Encounter Compression in Commerce Grid Tools?
Simply put, u-Slicer and our reporting APIs are the main tools in which compression is a factor.
Publishers working exclusively in the Reporting Tab will not encounter compression, as the Reporting Tab provides a controlled environment with fewer options for stacking large amounts of data.
Reducing Compression
Commerce Grid is always working to reduce compression on keys where publishers require exact aggregates.
As of October 2025, we have removed compression across the following keys, and any combination of:
| UI name | API name | Description |
|---|---|---|
| CGrid UI Account ID | publisher.account_id | Indicates the Publisher Account ID |
| Network ID | publisher.network_id | Indicates the Publisher Network ID |
| Inventory Group | publisher.id | Specifies the Publisher Inventory Group |
| Ad Unit ID | publisher.ad_unit_id | name and id(UID) of an ad unit |
| App Bundle | app.bundle | Specifies the app bundle |
| Browser | user.agent.browser.name | Specifies the browser name, e.g, Firefox |
| Country | user.geo2.country | Specifies the country in which the impression was displayed |
| Creative Size | creative_size | Indicated data broken down using the selected creative sizes, e.g. 300x250 |
| Day | granularity_day | Returns data broken down by day. |
| Device Type | user.agent.device.type | Specifies the device type, e.g. Phone, PC, Tablet |
| DSP | grid_or_verona_dsp_id | Indicates the DSP that purchased the inventory |
| Inventory Type | inventory_type | Indicates whether the impression was app or site, returns the following values: app, web, or ctv |
| Media Type | publisher.media_type | Indicates the inventory content type, i.e., video, banner, or native |
| OS | user.agent.os.name | Specifies the Operating System, e.g., Android, iOS, Linux |
| Publisher Domain | publisher.domain | Specifies the domain that the publisher represents, e.g., forbes.com |
| Publisher Sub ID | publisher.publisher_sub_id | Indicates Publisher Sub ID |
| Creative Size | creative_size | Indicated data broken down using the selected creative sizes, e.g., 300x250 |
Deep Dive: Compression in u-Slicer & u-Slicer Reporting API
What is u-Slicer
u-Slicer is our Enterprise data analysis tool that allows for the creation of highly granular reports.
To learn more about u-Slicer, visit the u-Slicer guide.
Why is there Compression in u-Slicer
Due to the vast amount of data queryable within u-Slicer, compression is utilized across a range of reporting keys.
Without compression, pulling data in u-Slicer wouldn't be instant, and could take hours to complete reporting requests.
How do I understand Compression in the u-Slicer UI
To understand if a report you've pulled in u-Slicer contains compressed data, look for the red +XX% next to your output results.
The ±XX% number represents the confidence range of the dataset based on the metrics you selected, meaning how different the actual data may be from what is shown.
The good news is that many of our most essential reporting keys inside of u-Slicer are NOT compressed, offering the ability to query mission-critical data in recent weeks and months without encountering any compression at all, especially when the pull is limited to a single key.
How do I know if I'm encountering Compression in the u-Slicer API
In cases where compression is being used, the confidence_range variable will be returned with a percentage within the Total rows.
If confidence_range contains “N/A” if the compression status is unknown and "0" for uncompressed rows.
For cases where compression is too high in the u-Slicer API (such as when multiple compressed datasets are stacked), the request may time out.
How do I reduce Compression in u-Slicer & the u-Slicer API
Several factors influence the degree of compression observed in u-Slicer and it's associated API:
- Stacking many reporting keys
- This is the most common issue, where publishers have stacked multiple keys that are compressed, resulting in significant compression.
- To resolve this, reduce the number of keys being queried. It is always better to query a single key than to stack multiple keys within u-Slicer.
- Querying historical data on compressed keys
- The further back your data pulls look, the higher the likelihood of encountering compression. For example, a report that pulls data from 6-months ago, and includes multiple different keys is likely to result in compression.
- To resolve this, limit the number of keys on a historical data pull, or, if possible, pull more recent data.
I'm unable to resolve my Compression issue in u-Slicer - help!
If you have a business case that requires a historical lookback, or multiple compressed keys and you're unable to isolate the data to something more recent, or repull using a single key, reach out to your Commerce Grid support team.
Deep Dive: Compression in Reporting Tab & Basic Commerce Grid Reporting API
What is the Reporting Tab
The Reporting Tab is our basic reporting platform offering inside the Commerce Grid UI. Visit the Reporting Tab guide section to learn more.
Is there Compression in the Reporting Tab?
No, because the Reporting Tab does not allow you to stack reports, and contains a limited amount of data overall, it is not impacted by compression.
The associated Commerce Grid Reporting API, however, is impacted by compression.
How do I know if I've encountered Compression on the Commerce Grid Basic Reporting API?
In cases where compression is being used, the confidence_range variable will be returned with a percentage within the Total rows.
If confidence_range contains “N/A” if the compression status is unknown and "0" for uncompressed rows.
The Commerce Grid Reporting API will time out and return an error if compression exceeds a certain threshold on the API. The Commerce Grid Reporting API has an even lower threshold for compression than the u-Slicer Reporting API.
If you are seeing errors in your queries, despite all settings being correct, it is likely a compression issue.
How can I reduce Compression on the Commerce Grid Basic Reporting API?
Several factors influence the degree of compression observed in the API:
- Stacking many reporting keys
- This is the most common issue, where publishers have stacked multiple keys that are compressed, resulting in significant compression.
- To resolve this, reduce the number of keys being queried. It is always better to query a single key than to stack multiple keys on the API.
- Querying historical data on compressed keys
- The further back your data pulls look, the higher the likelihood of encountering compression. For example, a report that pulls data from 6-months ago, and includes multiple different keys is likely to result in compression.
- To resolve this, limit the number of keys in a historical data pull, or, if possible, pull more recent data.