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 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.