Skip to main content
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. advProductIdadvertisedProductId, advDateadvertisedDate, advEngagementadvertisedEngagement, advToPurchasedProductRelationshipadvertisedToPurchasedProductRelationship). pageTypeName is now pageType.