Every retail media pitch eventually gets to the ranking problem: paid and organic results fighting each other on the same page instead of working together. Fewer pitches get honest about what fixing that is supposed to cost you. Usually it's a new ad server, a new search engine, or a campaign UI your team spent a year learning and trusts to run promotions correctly.

That's normally where the conversation stalls. Nobody wants to trade a relevance problem for a migration project.

Here's the part that doesn't show up in the pitch: the retailers running unified ranking today didn't make that trade. Three different companies, three completely different stacks, and none of them replaced anything to get there. What's more interesting than the fact that they kept their systems is which systems they kept, and how differently the same fix had to be built around each one.

TL;DR

• Fixing the ranking problem doesn't require replacing the ad server, search engine, or campaign UI already in place.
• Three real deployments: one where the front-end tool changed later without the ranking layer moving with it, one where the legacy campaign UI stayed and new demand was queued for later, and one where that same legacy setup added a demand source via real-time bidding after go-live.
• The integration path in each case was decided by what already existed, not by a single fixed rollout template.
• Rollout doesn't stop at go-live. In each case, more placements and demand sources got added months after launch, not before.
• The real question for a retailer evaluating this isn't "what do we replace." It's "what does our current setup require the integration to handle."

‍

The pitch says "no rip and replace." Here's what that actually looks like three times.

"No rip and replace" is easy to say and hard to make specific. So instead of restating the promise, here's what it looked like across three deployments, each with a different starting stack.

‍

Configuration one: the front-end changed. The ranking layer didn't have to move with it.

One retailer started in the same place as most: brands managed campaigns through the legacy ad server's own campaign UI, with ranking layered underneath it. Since then, the retailer moved to a separate front-end orchestration tool for managing cross-channel campaigns, a decision made entirely on its own timeline. The ranking layer stayed exactly where it was through that change, reading the same search and personalization signals the retailer's system produces and unifying them with connected demand, indifferent to which interface sits on top of it.

That's a different claim than "nothing changes." Something did change, just not the thing that usually causes the migration-project fear. The front-end a merchandising team opens every morning is free to evolve on the retailer's schedule, because it was never load-bearing for the ranking logic underneath it. Decoupling isn't a promise that nothing moves. It's a guarantee about which parts don't have to move together.

‍

Configuration two: the legacy ad server's campaign UI stays, demand comes later

A second retailer kept its existing ad server's native campaign UI in place. Ranking logic was layered on top of it. What makes this configuration different from the first isn't the ad server itself. It's the sequencing: additional demand sources were queued up as a second phase, connected after the ranking layer was already live and already unifying paid and organic results, rather than wired in on day one.

That sequencing decision wasn't a limitation. It was the retailer choosing to prove the ranking fix on its own before adding new demand into the mix, so any lift could be attributed to relevance first, and to expanded demand separately, later. Two different questions, answered in two different phases, on purpose.

‍

Configuration three: same legacy setup, but RTB gets added mid-flight

A third retailer started from the same place as the second: legacy ad server, native campaign UI, nothing replaced. The difference shows up after go-live. A major demand source was connected through real-time bidding once the ranking layer was already unifying results, expanding the pool of advertisers competing for the same inventory without touching the ad server underneath it.

That's a genuinely different integration problem than configuration two, even with an identical starting stack. Adding demand through an API and adding it through RTB are not the same engineering conversation, and the timing (after ranking was already stable, not before) was itself a decision, not an accident of scheduling.

‍

The variable was never the vendor. It was always the stack.

Line those three up and the pattern isn't "unified ranking is flexible" as a marketing claim. It's that a layer built to sit between the ad server and the organic listings, instead of replacing either, has exactly one hard requirement: read whatever the retailer's existing search and personalization system already produces, and unify it with whatever demand is already connected, whether that demand comes in through RTB or an API.

Everything else, which system stays at the front door, whether new demand shows up on day one or month four, how many surfaces get covered first, is a downstream decision that belongs to the retailer's stack, not to a fixed integration template. A platform that replaces your ad server or search engine only has one integration path to offer, because there's only one system on the other end of it: its own. A layer that leaves your systems in place has to solve a different version of the same problem for every stack it meets. Three configurations, three different engineering conversations, same underlying requirement.

‍

Go-live is a milestone. It isn't the end of the integration.

There's a second assumption worth correcting: that integration is a single event you complete and move past. In all three configurations, rollout kept expanding well after the initial launch. Category pages, product listing pages, seasonal placements, a new rule restricting a specific demand source from certain pages: each of these showed up after go-live as its own small implementation pass, not as part of one original scope.

That's not scope creep, and it isn't a sign the first launch was incomplete. It's what it looks like when a system is actually being used instead of shelved after a pilot. A retailer asking to open more inventory ahead of a seasonal push, or test a new placement, is asking for exactly the kind of expansion a modular layer is built to handle without a second migration project.

‍

The actual decision this creates

If you're evaluating this for your own stack, the useful question isn't "what will we have to replace." Across all three configurations, the answer to that question was nothing. The useful question is narrower: what is our current setup actually going to require of the integration, given what's producing our search results today, how our demand connects, and how many surfaces we want covered on day one versus month four.

That's a scoping conversation, not a purchasing decision, and it's answerable before any contract gets signed.

‍

Key Takeaways

• Three deployments, three different starting stacks: a proprietary in-house front-end, a legacy ad server's native campaign UI with demand added later, and the same legacy setup with demand added via RTB after go-live.
• None of the three replaced an ad server, search engine, or campaign UI to get unified ranking live.
• The one fixed requirement across all three: read the existing search and personalization output, unify it with whatever demand is already connected, RTB or API.
• Rollout continued well past go-live in every case, with new placements and demand sources added as separate, later implementation passes.
• The question worth asking isn't what gets replaced. It's what your current setup requires the integration to handle.

‍

Frequently Asked Questions

Will unifying ranking require us to replace our existing ad server or search engine? No. The layer is built to sit between the ad server and the organic listings, using whatever search and personalization system already generates results rather than replacing it.

Do we need to change our campaign UI to add unified ranking? Not based on any of the three configurations above. Two retailers kept their existing ad server's native campaign UI in place outright. A third later moved to a separate front-end orchestration tool on its own schedule, and the ranking layer didn't need to move with it. In all three, the interface a merchandising team uses day to day was never the thing standing in the way.

How does new demand get connected without touching our existing ad server? Through whichever method the retailer already supports, RTB or API. In one configuration, demand was added via API as a second phase after the ranking layer went live. In another, a major demand source was added later through real-time bidding. Neither required replacing the ad server underneath.

If nothing gets replaced, why does the integration process look different every time? Because the layer has to work with whatever a retailer already runs, and no two retailers run identical combinations of ad server, search engine, campaign UI, and demand connections. The variation is the layer adapting to the stack, not an undefined process.

Does the integration end once ranking goes live? Not in practice. All three configurations continued expanding after go-live, adding placements, demand sources, or specific rules well past the initial launch, as separate implementation passes rather than part of one fixed scope.