Skip to main content
The Preview tier is now deprecated following our new versioning policy. You have until the end of 2026 to migrate to either the current stable 2026.07 version or the upcoming release candidate 2027.01, which will be available soon.
This endpoint enables Retail Media DSP partners to retrieve a transaction-level log of every purchase event attributed to their campaigns. Each row represents a single attributed transaction and captures the product advertised, the product purchased, the attribution rule applied, and the time elapsed between ad delivery and purchase.
This is not a performance report. Aggregated metrics — impressions, clicks, spend, attributed sales totals — are not available here. Use POST /reports/performance for those.
Primary audience: Data scientists and analysts auditing attribution methodology, understanding cross-sell and halo effects, or analyzing purchase behavior at the transaction level. Not a day-to-day campaign monitoring workflow. The endpoint supports asynchronous report generation. Submit a request, poll for status, and download the output when ready.

​
Request

​
Required fields

startDate, endDate, filters, dimensions, and metrics are all required. filters must contain exactly one scope filter (filters.accountIds[], filters.campaignIds[], or filters.lineItemIds[]).

​
Optional fields

​
Example request

​
Response

A successful request returns 200 OK with a reportId. Poll for status until status is success or failure:
Download the output when status is success:
Each row in the report output represents one attributed purchase event.

​
Metrics

Select measures using the metrics[] array. metrics is required.

​
Dimensions

Select output columns using the dimensions[] array. dimensions is required. The advertised product (advertised*) and purchased product (purchased*) fields together give the bilateral view described below.
Fields marked Retailer catalog only are available only for retailers that provide a product catalog to Criteo. For retailers without a catalog, they are not populated.

​
Understanding the advertised vs. purchased product fields

The advertised product (advertisedProduct*) and purchased product (purchasedProduct*) are often the same — but not always. When the attribution rule is same brand, same taxonomy, or same seller, the ad may have driven a purchase of a related product rather than the exact item advertised. Example: An ad for a camping jacket is served. The shopper purchases a different jacket from the same brand. The row will show:
  • advertisedProductId: the advertised jacket
  • purchasedProductId: the purchased jacket
  • advertisedToPurchasedProductRelationship: same brand
This bilateral product structure makes this endpoint useful for cross-sell and halo analysis — you can see exactly which advertised products drove purchases of which other products, and under which attribution rule.

​
Migrating from reportType: attributedTransactions

Replace your existing call on /reports/campaigns or /reports/line-items with a call to this endpoint. Endpoint change:
Request shape changes:
  • Replace the top-level accountId / campaignId / lineItemId fields with a filters object containing accountIds[], campaignIds[], or lineItemIds[] arrays (exactly one scope filter).
  • Add required dimensions[] and metrics[] arrays to select output columns — the fields listed above are no longer a fixed response schema; you choose which to return.
  • startDate and endDate are required (date-only YYYY-MM-DD).
  • Remove reportType: attributedTransactions — it is not accepted on this endpoint.
Field renames: the adv-prefixed fields are now spelled out as advertised* (e.g. advProductId → advertisedProductId, advDate → advertisedDate, advEngagement → advertisedEngagement, advToPurchasedProductRelationship → advertisedToPurchasedProductRelationship). pageTypeName is now pageType.