Starting with where the ranking decision lives

Someone on the team pulls up last year's RFP template to start this year's vendor search. It's a good document. It's thorough. It has sections on pricing, on implementation timeline, on data security, on reporting cadence. It just has one problem: every requirement in it was written by looking at the vendor you already have.

That's not a criticism of whoever wrote it. It's what happens by default. The person holding the pen usually owns the ad contract, so the requirements describe, in more detail, the thing already being paid for. An RFP built that way can rank vendors. It can't discover one that does something your current vendor structurally can't, because nobody wrote down the question that would surface the difference.

Here's that question, and it's worth opening the document with it: where should the ranking decision live in your stack, the ad server, the search engine, or somewhere else? Everything else in a well-built RFP follows from the answer.

‍

TL;DR

Most retail media RFPs get written from the incumbent's feature list, which makes them structurally incapable of discovering anything the incumbent doesn't already do. The requirements get gathered from the team that owns the ad contract, not the team that owns the ecommerce search results page, so the document never asks about the one thing that actually determines what you can do in three years: where the ranking decision lives. Five requirements, written down before the document goes out, close that gap. The retailers gaining ground in the H1 2026 Sponsored Products Benchmarks Report treated this as an architecture question, not a placement question, and their RFPs reflect it.

‍

How Many of Your Requirements Were Copied From Your Current Vendor?

Worth an honest audit before anything else: pull your last RFP and check how many requirements describe a feature your incumbent already has, versus how many describe an outcome you actually need. If it's mostly the former, the document is a mirror, not a search. It will confirm that your incumbent is good at being your incumbent and tell you nothing about whether a genuinely different architecture would serve you better.

The fix isn't to throw out everything you know about your current setup. It's to add the requirements a mirror can't produce, because they ask about something your incumbent's feature list was never going to volunteer.

‍

Requirement 1: Where Does the Ranking Decision Actually Live?

This is the question that should open the document, because everything else depends on the answer. Every retail media vendor makes some product decide which sponsored products appear and where. That decision can sit inside the ad server, inside the search and personalization engine, or in an independent layer that sits between the two. Each of those is a different architecture with a different answer to what you can change later, and a feature grid that just lists "unified ranking" as a checkbox flattens all three into apparent equivalence.

Write the requirement specifically: the RFP must state which system makes the final ranking call, and require the vendor to describe it in enough detail that a technical reviewer, not just a salesperson, could confirm the answer. A vendor that answers this question directly, with a diagram and a named data flow, is telling you something real. A vendor that answers with "our proprietary optimization engine" is telling you to ask again. We've laid out how the ranking decision actually splits across the three common architectures in more detail if it helps to have that framework in front of you while you write this section, and a related piece walks through five questions that separate a genuine unified ranking system from a rebrand.

‍

Requirement 2: What Has to Stay Swappable, and What Does "No Rip and Replace" Actually Mean in the Contract?

Every vendor in this category will tell you their solution doesn't require a rip and replace. That phrase has started to mean everything and nothing, because it describes the pitch, not the contract. The requirement to write down is more specific: name which systems must remain independently replaceable after implementation, and require the vendor to state, in contract language, what happens to your data, your relevance tuning, and your existing integrations if you replace any one of them individually.

DocMorris's retail media overhaul is a useful real example of what this looks like done deliberately, executed as a sequence of independently reversible steps, each one leaving the rest of the stack untouched, rather than a single all-or-nothing migration. That's what "no rip and replace" means when it's a requirement instead of a slogan: not that the initial rollout is gentle, but that every future change stays gentle too.

This requirement should also settle a related but different question buyers often bundle in by accident: replacing your ad server does not have to mean replacing your search engine, and vice versa. An independent optimization layer is specifically designed to leave both in place while changing how they coordinate. If a vendor's answer to "can I keep my search engine" is "you'd need to migrate that too," you've just learned which architecture you're actually being sold, regardless of what the pitch deck called it.

‍

Requirement 3: Who Owns Relevance Tuning, and Can You Change It Without a Ticket?

This requirement catches a gap that often doesn't surface until year two. Ask directly: can the retailer's own team adjust relevance weighting, bid influence, and category-level rules without filing a request to the vendor and waiting on their release cycle?

Vendors will almost universally say yes in a sales conversation. The RFP should ask for something more specific than a yes: a description of the actual interface a retailer's team uses to make that change, and how long it takes from decision to live. If the honest answer involves a professional services engagement or a quarterly release window, that's a real constraint worth knowing about before signing, not after the first time your team needs to move fast.

‍

Requirement 4: What Signals Is the Sponsored Decision Actually Permitted to See?

If a vendor's sponsored ranking decision can only see bid value, the outcome of every page is largely pre-decided before a shopper ever arrives: whoever bids highest wins, regardless of whether their product belongs in that position. The requirement worth writing down: require the vendor to list every signal the sponsored ranking decision has access to at the moment it runs, including whether it can see the organic ranking, real-time inventory, and shopper context, not just the advertiser's bid.

This is the practical, RFP-ready version of the architecture question from Requirement 1. A system where sponsored and organic decisions run blind to each other will answer this question with a short list: bid, budget, maybe a keyword match. A system built as a genuine unified ranking layer will answer with a longer list that includes the same relevance signals driving organic results. The length and content of that list tells you which architecture you're actually buying, independent of what either vendor calls it.

‍

Requirement 5: What Does the Ecommerce Team Need to Be True in Order to Say Yes?

This is the requirement most RFPs skip entirely, and it's usually why a deal that looked done on paper stalls at the ad-load turf war instead of at price. Retail media RFPs get built by the team that owns the ad contract. They rarely get built with the team that owns the ecommerce search results page and answers for what happens to conversion rate and shopper trust in the room. Write the requirement anyway: name what the ecommerce team needs to see, measure, or control before they'll sign off, and get their answer in writing before the RFP goes out, not after a vendor is already selected.

This requirement earns its place for a second reason worth building in now rather than adding as an amendment next year: the same architectural choice is starting to apply to a newer surface. As onsite AI shopping assistants become real products rather than experiments, retailers are facing the same underlying question about where the recommendation logic lives, and whether a sponsored product gets bolted onto the output or genuinely folded into it, a question we've covered in more depth elsewhere. An RFP written today should ask whether the vendor's architecture extends to that surface, or whether it's a separate rebuild later. Getting the ecommerce team's requirements settled now, including their view on that forward-looking question, is cheaper than renegotiating them after an assistant ships.

‍

Three Diagnostic Questions

Could you replace your ad server next year without touching your search engine?

Can your own team change relevance weighting today without filing a ticket to a vendor?

Has anyone from your search or ecommerce team actually been in an RFP meeting for this category?

‍

Key Takeaways

• Most retail media RFPs get written by transcribing the incumbent vendor's feature list, which makes them structurally unable to discover a genuinely different architecture.
• Five requirements close that gap: where the ranking decision lives, what stays swappable and what that means contractually, who owns relevance tuning, what signals the sponsored decision can see, and what the ecommerce team needs before they'll sign.
• "No rip and replace" is a phrase every vendor uses. The requirement that matters is the contract language behind it, not the pitch.
• A vendor's answer to what signals its sponsored ranking can see is one of the clearest, most concrete ways to tell which architecture you're actually buying.
• Requirements gathered only from the team that owns the ad contract miss the objections that later stall the deal. Getting the ecommerce team's sign-off criteria in writing before the RFP goes out avoids that turf war.

‍

Frequently Asked Questions

Where should the ranking decision live in a retail media tech stack, the ad server, the search engine, or somewhere else? It can live in any of the three, and each choice trades off differently. Inside the ad server is the simplest commercial fit but locks sponsored and organic ranking into separate systems. Inside the search engine improves relevance but makes real-time bidding and future vendor changes harder, since ranking logic becomes entangled with core ecommerce infrastructure. An independent layer between the two keeps both systems in place and swappable, at the cost of one more vendor in the stack.

Does adding a retail media platform mean replacing my existing search engine? No. An independent optimization layer is specifically designed to sit between your existing ad server and your existing search engine, coordinating both without requiring either to be replaced. Whether a specific vendor's architecture actually works this way, rather than requiring a migration, is exactly what Requirement 2 is meant to surface before you sign.

Does Pentaleap replace my ad server? Not by default. Most retail media platforms, Pentaleap included, are built to add ranking logic on top of an existing ad server rather than to require its removal. Whether a given vendor can operate that way, or whether their pitch of "no rip and replace" holds up once you ask for it in contract language, is the specific thing Requirement 2 asks you to verify before signing rather than after.

What does "no rip and replace" actually mean for retail media technology adoption? In practice, it should mean that adopting a new ranking layer doesn't require removing your existing ad server, search engine, or campaign UI, and that future changes to any one of those systems can happen independently without disrupting the others. The phrase is used loosely across the category, so the useful test is asking a vendor to state it as a specific contractual commitment rather than accepting it as a tagline.

Should sponsored products appear inside AI shopping assistant recommendations, or alongside them? Both are viable starting points, but they're not equally valuable. Placing sponsored products alongside an assistant's output, clearly labeled and separate, is the lower-risk, easier-to-ship option. Folding sponsored consideration into the recommendation logic itself, so a paid product only surfaces when it genuinely fits, is the harder, larger opportunity, and it depends on the same architectural choice retailers already face for their onsite grid: whether that logic is rebuilt from scratch or reuses the search and personalization system already in place.