Criteo vs — the feature table is not the comparison, the test design is

An unfinished query, and what people usually mean by it

"Criteo vs" is a search someone abandons halfway through typing, and that is useful information rather than a problem. It means the comparison set has not been chosen yet. Every page that ranks for it chooses one on the reader's behalf and then argues its own preference, which is how a buyer ends up comparing two platforms that were never really the alternatives to each other.

One definition first, because the acronym below collides with an unrelated Amazon business. A DSP is a demand-side platform — software for buying display, video and audio inventory programmatically through auctions. Amazon's Delivery Service Partner programme is a parcel-delivery franchise and has nothing to do with any of this. We are Dr. DSP, an Amazon demand-side platform product from Full Circle, a full-service Amazon management company with more than $500M in managed revenue across 100+ brands.

In practice, four comparisons hide inside the unfinished query, and they are answered by different evidence:

• Against Amazon's own DSP, when most of the revenue lands on Amazon and the question is really about signal depth.
• Against a general open-internet platform, when the goal is reach and inventory control rather than commerce data.
• Against buying retail media networks directly, when a small number of retailers account for nearly everything and an aggregation layer may not be earning its place.
• Against a managed service, which is not a platform comparison at all — it is a decision about who does the work and who is accountable for the outcome.

Deciding which of those four you are in takes one sentence and saves a fortnight. Write down the sentence "we are choosing between ___ and ___ because our constraint is ___" before you book anything. If you cannot fill in the third blank, the shortlist is not ready.

Why a feature table cannot settle this, and what it can settle

Feature tables are not useless. They are excellent at elimination: does this platform reach the inventory we need, does it support the creative formats we have, does it integrate with the systems we already run, can our team get access at our budget. Those are binary, checkable, and worth ten minutes.

What a feature table cannot do is predict performance, and performance is what you are actually buying. Two platforms with identical feature rows will deliver differently against the same audience because the differences live in the parts nobody tabulates: which auctions they enter, at what price, how quickly the model learns on your catalogue, how the supply path is composed, what share of a committed budget reaches inventory at all. None of that renders as a tick.

There is also a structural problem specific to media comparisons, and it is the reason this page exists. Two platforms cannot be compared by running them one after the other. A sequential test compares February to April, not platform A to platform B, and February and April differ in ways that dwarf any platform effect — seasonality, promotional calendar, competitor activity, your own inventory position, price changes, how fast customer ratings accumulate, whether a hero SKU went out of stock for nine days. Almost every "we tried X, then we tried Y" case study in this category is a seasonality story wearing a vendor's logo.

Nor can they be compared by their own reported numbers. Each platform reports the conversions it can see and attributes generously within its own window, so running two at once and adding up the reported results produces a total that exceeds the orders you actually took. That is not anybody misbehaving; it is what happens when two systems both claim credit for the same shopper. It does mean that the comparison has to be settled by evidence neither platform generates on its own.

The bake-off protocol — parity rules first, then run it

If you are going to spend money proving something, spend it on a design that can actually prove it. This is the protocol we would run, and we would run it the same way whether or not we were one of the candidates.

• Split the population, not the calendar. Divide by ASIN group or by region into two comparable halves — matched on revenue, margin, review count, price band and recent trend — and give one half to each platform. Both run in the same weeks, against the same market conditions.
• Match the budget per half, not in total, and hold pacing rules identical. A platform given more room will look better and will have taught you nothing.
• Use the same creative. One set of assets, same formats, same messaging. Creative is usually a larger performance lever than platform choice, so letting it vary destroys the read.
• Pre-register the metric, in writing, before launch. One primary measure, defined precisely — including the attribution window and whether it counts new-to-brand separately. Choosing the metric after seeing the data guarantees the answer you already wanted.
• Fix the window and do not touch it. Long enough for the models to exit learning and for your purchase cycle to complete, and then no mid-flight optimisation on either side beyond the rules you agreed at the start.
• Agree in advance what would make you stop. A rollback trigger, written down, so that pulling the plug is a plan rather than an argument.

Then hold back a third slice from both platforms. A clean holdout is what turns a comparison between two vendors into an answer to the more important question, which the next section is about.

The confounds that will ruin it, and how to disarm them

Even a well-split test can be wrecked by four things. Plan for them explicitly or the result will be argued about rather than acted on.

Contamination between halves. If your ASIN groups are substitutes, display on one half drives shoppers to the other, and the control is no longer a control. Split by product family or by geography rather than by individual SKUs inside the same family.

Double-counting with sponsored ads. Search is running underneath both halves and will claim orders that display generated, in whatever proportion each system's attribution allows. Without reconciliation you are comparing two inflated numbers to each other and hoping the inflation is equal. It is not.

Supply and price shocks. A stockout, a price change, a lost buy box or a competitor promotion inside one half invalidates that half. Log every such event daily during the window, and be prepared to exclude an affected period rather than explain it away afterwards.

The learning period. Both platforms will perform worst in week one. If your window is short, you have mostly measured which model learns faster, which is worth knowing but is not the same as which performs better at steady state.

The tool that disarms the second of those is Amazon Marketing Cloud. It is a clean room holding event-level records of your Amazon advertising and conversions, available at no cost to eligible advertisers, and it is where display and sponsored ads stop double-counting each other because you can see the paths rather than the platform-reported totals. Reconciling a bake-off there converts two sets of vendor-reported wins into one set of orders with a defensible allocation. It is more work than reading two dashboards. It is also the difference between a decision and a preference.

What Criteo is genuinely strong at, and when the comparison is unnecessary

Criteo's own advertiser pages describe a commerce media platform spanning 200+ retailers and 1,300+ direct publisher partners, with named lines including Commerce Growth, Commerce Max, Commerce Grid and a self-service route branded Criteo GO, and pricing stated as insertion-order based supporting CPC or CPM. That breadth is a real and specific advantage. If your business runs meaningfully across grocery, mass, specialty and the open web, and you want one commercial relationship covering onsite and offsite across many retailers, no Amazon specialist can match that footprint and you should buy for it. That includes us: we do not do it and we are not going to pretend the comparison is close.

There is also a case for skipping the bake-off entirely. Run the concentration test first. Take the share of your ecommerce revenue that comes from your single largest retailer. If it is above roughly three quarters, a multi-retailer aggregation layer is being asked to justify itself on a quarter of your business, and the honest first move is to go deeper where the revenue already is rather than broader where it is not. If it is below half, breadth is doing real work and the aggregation layer is probably earning its fee.

The other comparison worth resolving on paper rather than in market is against Amazon's own DSP, which describes audiences built from first-party shopping, browsing and streaming signals, offers full self-service control with no self-service minimum, and sets a typical managed-service minimum investment of USD 50,000, varying by country. That is a question about which signal you need, and no test is required to answer it: if the behaviour you want to act on is Amazon shopping behaviour, it exists in one place.

Where we come out, and who should ignore us

Our position is narrow on purpose. Dr. DSP is Amazon DSP run as a managed product, and the argument we make is about evidence rather than reach. Reported return on display is the number a platform can produce; incremental return is the number a business can bank, and only a holdout or a matched control can tell you which one you are looking at. So we design the test before the spend, reconcile in Amazon Marketing Cloud, and attach three things to every change we make: the evidence behind it, a measurement plan, and a rollback trigger.

The client sets the autonomy level and can move it at any time. Inventory risk, pricing, new products, new creative and any decision to stop display spend always come to a human. Commercially there is no published price — a demo, the first 30 days free, and pricing set on the call against real media budget and scope, month to month, with Orbit included at no extra cost. On the narrow point of published transparency, several vendors in this comparison are ahead of us, and we would rather write that sentence than dance around it.

As a scoped reference rather than a promise: across 30 advertisers in July 2026, the API pull showed 6.04x return on ad spend, 78.4 million impressions at a $4.00 CPM, a blended $1.42 cost per click, $5.49 cost per acquisition across 57,137 attributed purchases and 20.1% new-to-brand. That is thirty advertisers in one month, not a forecast for yours.

Two honest redirects. If the comparison you are really running is between agencies rather than platforms — a named team, a scope of work, coverage beyond Amazon — that is reMKTR, and it is a different purchase from this one. If the weakness you are trying to fix sits in sponsored search rather than display, Dr. PPC is the right product and publishes both its rate and its cap.