Blog

You Don't Have to Replace Your Campaign Stack to Fix How Products Rank

Sarah Mackinnon
September 10, 2026
Share
Jump to Title

Most retail media teams are running at least two systems that make decisions about the same page: a campaign tool that launches and manages sponsored placements, and a search or ranking system that decides what shows up organically. Somewhere along the way, "fix our ranking" started getting sold as "replace everything you're currently running." Those are not the same project, and treating them as one is why so many retailers stall out before they start.

TL;DR

  • Campaign orchestration (how sponsored placements get launched and managed) and ranking decisioning (what actually shows up, organic and sponsored, and why) are two separate jobs. They don't have to be handled by the same system.
  • There are really only three places the ranking decision can live: inside the ad server, inside the search engine, or in an independent layer that sits between them. Each has different tradeoffs.
  • An independent layer means your campaign tools and your ranking logic can evolve on separate schedules. Upgrading one doesn't require renegotiating the other.
  • Internal A/B testing across multiple retailers shows 80 to 140% more ad revenue from existing inventory and roughly 2x CTR for unified ranking versus legacy ad serving alone.
  • Independent ranking layers have separately been in production for five years across named retailers. Existing ad servers, search engines, and campaign UIs stay in place either way. Nothing gets ripped out to get started.

The two decisions retailers keep bundling together

Ask most retail media teams how their page decides what to show, and the honest answer is "it depends which system you ask." The ad server knows what's been paid for. The search engine knows what converts. Neither one is fully aware of what the other is doing, and the campaign tool brands use to launch and manage their placements sits on top of both, blissfully unaware that it's one of three opinions on the same page.

That's not a strategy problem. It's an architecture problem, and it's the reason "unify our retail media" so often gets misread as "buy one new platform that does everything." It doesn't have to. The tool your teams use to launch and manage campaigns and the logic that decides what actually ranks, organic or sponsored, are two different jobs, and they can be handled by two different systems that never have to merge.

Three places the ranking decision can live

Strip away the vendor pitches and there are really only three architectures for where that ranking decision sits:

  1. Inside the ad server. This is the default for most legacy retail media setups. It's bundled and familiar, but it also means you're locked into whatever that vendor decides sponsored products deserve, with no visibility into how that stacks up against what's ranking organically.
  2. Inside the search engine. Some retailers push ranking logic into the same AI that powers their onsite search. That has a latency advantage, since the decision happens right next to the results. But it comes with an agility risk (search engines aren't built to be reconfigured on a vendor's roadmap), and real-time bidding becomes nearly impossible to support, since search engines aren't built to run live auctions.
  3. An independent layer that sits between the two. This is the approach a unified ranking layer takes: modular, and any single component (the ad server, the search engine, the campaign UI) can be swapped out without touching the others.

The first two answer "how does sponsored inventory get ranked" by picking a single system to own the whole decision. The third answers a different question: "how do we let organic and sponsored ranking optimize together without locking our stack to one vendor's roadmap." That's the actual choice on the table, and it's worth naming out loud before evaluating any specific product.

What "modular" actually buys you

Here's the part that's easy to gloss over in a sales conversation: modular doesn't just mean "flexible" in the abstract. It means the system that launches your campaigns and the system that decides what ranks can genuinely run on separate release schedules.

Practically, that looks like this: the tool your brand or trade marketing team uses to set up sponsored campaigns keeps evolving on its own roadmap, adding features, changing workflows, whatever it does. Meanwhile, the logic that decides how organic and sponsored products rank together against each other evolves on a completely separate track, because it's a separate layer, not a feature bolted onto the campaign tool. Neither one is waiting on the other to ship something before it can improve.

This is also what makes "no lock-in" more than a slogan. If the ranking layer is independent, you can change your campaign tool, your ad server, or your demand sources later without re-architecting how products get ranked in the first place. Each piece is separately reversible. Nobody has to bet the whole stack on one vendor's five-year roadmap to get started.

What this actually requires from your team

The honest answer here matters more than the fast one. Adding an independent ranking layer does not mean ripping out your existing ad server, search engine, or campaign UI. All of them stay in place. The ad server can keep running as one of several demand sources, or get phased out later, entirely the retailer's own call and on the retailer's own timeline, not a forced migration on day one.

The standard path is a pilot period that runs alongside whatever you already have: no new ad slots for advertisers to learn, no changes to how campaigns get launched, just the ranking logic itself being tested against your current baseline before anything scales. If the lift holds up, the rollout happens in stages, fixing ranking first, then connecting additional demand sources, then extending to other channels if that's the goal, with each stage optional and reversible on its own.

That's a fair question to ask any vendor pitching a ranking fix, and it's one procurement and engineering teams are right to press on directly: what does our team actually have to build or maintain, measured in person-days, not marketing language. A vendor who can quote that number has done this before. One who can't is asking you to find out the hard way.

The real question to bring into a vendor conversation

If you're building the case internally for fixing how your page ranks, the question worth asking isn't "which platform should we standardize on." It's "which layer are we actually trying to fix, and does fixing it require touching everything else we've already built." Most of the friction in these decisions comes from treating those as the same question when they aren't.

Nobody enjoys re-platforming an ad server they just finished configuring. With the layer decoupled from the tools around it, they don't have to, and that's the actual trade-off worth pricing in before the next vendor conversation.

Key Takeaways

  • Campaign orchestration and ranking decisioning are separate jobs. Conflating them is why "fix our ranking" so often turns into a full replatforming project it never needed to be.
  • There are three places ranking logic can live: the ad server, the search engine, or an independent layer between them. Only the third lets each piece of the stack evolve on its own schedule.
  • Modularity means real reversibility: your campaign tools, ad server, and demand sources can all change later without re-architecting how ranking works.
  • Internal A/B testing across multiple retailers shows 80 to 140% more ad revenue from existing inventory and roughly 2x CTR for unified ranking versus legacy ad serving alone, with independent ranking layers separately proven in production for five years.
  • Nothing about adding this kind of layer requires removing your existing ad server, search engine, or campaign UI on day one.

Frequently Asked Questions

How does a unified ranking layer actually work? It sits between a retailer's ad server (or servers) and the product grid, letting the retailer's existing search AI rank sponsored products the same way it already ranks organic ones, on relevance, margin, and conversion, instead of ranking sponsored inventory by bid price alone in a silo. It isn't an ad server, and it isn't a bundled tool that replaces what you already run. It's a layer that connects systems that are already in place.

Does this replace our existing ad server or search and personalization engine, like Algolia or Bloomreach? No. The existing ad server, search engine, and campaign UI all stay in place. The ad server can continue serving as a demand source, or be phased out later, entirely at the retailer's own pace. There is no rip-and-replace step required to get started.

What engineering resource will this actually require, estimated in person-days? This depends on your current stack, but the honest scope is: a pilot period that runs alongside your existing systems with no new ad slots and no changes to advertiser-facing workflows, followed by an incremental rollout if results hold up. Ask any vendor to quantify this in person-days rather than a general timeline before committing.

Is this reversible if it doesn't work out? Yes. Because the ranking layer is independent and modular, each stage of adoption, from the initial pilot to connecting additional demand sources, is separately reversible. Nothing requires a full commitment before you've seen the results against your own baseline.

Does this mean giving up our current campaign tool? No. The campaign tool your team uses to launch and manage placements and the layer that decides how products rank are two different systems by design. One doesn't have to change for the other to improve.

Stay Ahead with Retail Radar

Subscribe for cutting-edge insight into the latest retail media developments and trends

By submitting I accept the Privacy Policy.
Thank you! You are now subscribed to the Pentaleap newsletter.
Oops! Something went wrong while submitting the form.
A mail box
Thank you! You are now subscribed to the Pentaleap newsletter.