A shopper searches "cordless drill" on Google. An ad appears, funded by your offsite media budget, and the shopper clicks it.

They land on your site, run a second search, and see a list of drills ranked by a completely different system than the one that just won the auction on Google, thirty seconds and one click earlier.

Shoppers never notice that seam. You probably do, because both halves work on their own: the offsite auction did its job, the onsite ranking did its job. Nobody designed the two to agree with each other, because onsite and offsite usually get built and bought as two separate businesses instead of one relevance decision with two doors into it.

Here's the stance worth stating up front: onsite is where you should start, and where most of your retail media revenue already comes from. 

Offsite is what you add once onsite is proven, not a parallel channel with its own rules. And you don't need a single vendor's bundled platform to make the two agree with each other.

You need one thing: whatever demand shows up, wherever it came from, gets weighed by the same relevance and margin logic before it reaches a shopper.

TL;DR: Onsite and offsite don't need the same technology. They need the same relevance and margin logic applied to whichever demand shows up. Onsite is where a product earns its position on your own site. Offsite is a source of demand for that position, budget arriving from somewhere you don't own. The two connect through RTB and API, in real time, without either one dictating how the other has to be built, and without you needing to buy one all-in-one platform to make it happen.

‍

What onsite decides, and what offsite brings

Start with the plain version of the split: onsite is the decision layer. It's where a product earns or loses its position on your own site, using data you own, search intent, inventory, margin, and a page you control. Offsite is a demand source. It's budget that exists somewhere you don't own, Google, Amazon, the broader programmatic and social market, arriving to compete for a position your onsite relevance layer still has to award.

Confuse the two and you end up in one of two bad places: building a second ranking system just to handle offsite budgets, or treating offsite money as a free pass that skips the relevance decision entirely, letting whoever pays the most win a spot regardless of whether the product deserves it.

Neither is necessary, and here's why: onsite demand has always had to clear your relevance bar, because you own the page and can enforce it. Offsite demand only has to clear the same bar if your relevance layer is built to receive it as just another bid, not as a separate revenue stream with its own rules. That's the one thing the two channels actually need in common. Not the same technology. The same standard applied to whichever demand shows up.

‍

Do you need a platform, or a connection? What to ask before you add offsite demand

This is worth deciding before volume becomes the pitch. A vendor conversation about a new offsite demand source usually leads with reach, more advertisers, more budget, more impressions. Reach isn't the risk. What that demand does once it arrives is, and here's what to ask before you say yes:

Does this offsite demand compete under the same relevance and margin logic as everything else on the page, or does it get a reserved position? A reserved position for offsite money is the same fixed-tile problem retail media already solved for onsite sponsored placements, just relocated.

Is the connection RTB, API, or something proprietary to one vendor? RTB and API connections can be added or removed independently of everything else in your stack. A proprietary pipe usually can't, which is how retailers end up locked into a platform they didn't mean to commit to.

What happens to margin and merchandising priorities once offsite budget starts competing for onsite positions? If the answer is "the highest bid wins," ask what stops a high-bid, low-margin product from displacing a better one, the exact problem unified ranking was built to solve onsite in the first place.

Does adding this offsite demand source require changing your onsite ranking system, or just connecting to it? The second answer scales without disrupting what already works. The first is a rebuild wearing an offsite label.

‍

How offsite demand actually reaches your onsite grid

Two mechanisms answer that question in practice, and they solve different problems.

RTB (real-time bidding) connects programmatic and search demand, including sources like Google and Amazon, directly into your onsite auction at the moment of the request, not on a batch cycle. Pentaleap and Teads built one version of this together: a real-time bidding integration that lets Teads Ad Manager activate Sponsored Product Ads across a retailer's onsite inventory, alongside advertisers' broader omnichannel campaigns. The demand originates offsite, in an advertiser's existing media plan, and competes for an onsite position under the same relevance and margin logic as everything else on the page.

API connections bring in demand from commerce and orchestration platforms that manage advertiser relationships at scale. Pentaleap's integration with Skai works this way: Skai's network of advertisers gets a path into the ad networks Pentaleap powers for retailers, without Skai ever touching your page directly. The demand flows in; the decision about what actually gets shown stays with your own relevance layer.

Neither mechanism requires you to adopt a second ranking system for offsite money. Both just require your relevance layer to be open enough to receive that demand as just another bid.

‍

Is aligning onsite and offsite the same problem as aligning your own channels?

Not quite, and it's worth naming the difference. Connecting offsite demand into your onsite inventory is a different problem from unifying decisioning across your own onsite and offsite placements, which is closer to what Zitcha and Pentaleap address together. Zitcha's Margin Manager feeds product-level margin and merchant-decisioning data into Pentaleap's ranking engine, so a product's performance in the ad auction gets weighed against whether it's actually a product your merchant team wants pushed, not just whichever bid was highest. That's a governance problem as much as a demand problem: it keeps your advertising incentives and merchandising incentives pointed at the same outcome, across whichever channels a campaign touches.

You'll likely need both eventually: an open door for offsite demand, and alignment across your own channels, alongside the broader tradeoffs retailers weigh when they extend this thinking into in-store. But they're solving different problems, and a vendor conversation that blurs them tends to produce a stack that's either open to offsite money without margin guardrails, or has margin guardrails but no real offsite demand reaching it.

‍

What this looks like once it's running

Pentaleap's ad networks already handle production traffic at scale for major retailers including The Home Depot and Macy's, processing millions of daily ad requests without requiring either retailer to rebuild onsite ranking to accommodate new demand, the same incremental, low-disruption approach that got them there in the first place. The pattern holds across both RTB and API connections: the onsite relevance layer doesn't change shape to accommodate new offsite demand. The demand adapts to the layer's existing rules, because the connection is built at the API or RTB level, not by merging two ranking systems into one.

‍

Key takeaways

• Onsite and offsite don't need shared technology. They need shared relevance and margin logic applied consistently to whichever demand shows up, and you don't need one bundled platform to get there.
• Onsite is the decision layer. Offsite is a demand source. Confusing the two leads either to a second ranking system or to offsite money skipping the relevance decision entirely.
• RTB and API are the two mechanisms that bring offsite demand in: RTB for real-time programmatic and search bids (Teads, Google, Amazon), API for platforms managing advertiser relationships at scale (Skai).
• Zitcha's Margin Manager addresses a related but distinct problem: keeping your own onsite and offsite decisions aligned with merchant priorities, not just ad revenue.
• Retailers doing this well didn't rebuild onsite ranking to accommodate offsite demand. They opened the relevance layer they already trust to receive it under the same rules.

‍

Frequently Asked Questions

Do onsite and offsite retail media need to run on the same platform?

No. They need to share the same relevance and margin logic. The technology bringing offsite demand in, RTB or API, can be entirely separate from the technology ranking your onsite page.

‍

What's the difference between RTB and API demand connections?

RTB brings in real-time programmatic and search bids, at the moment of the request, from sources like Google, Amazon, and Teads. API connections bring in demand from commerce and orchestration platforms, like Skai, that manage advertiser relationships at scale rather than bidding in real time.

‍

Does opening onsite inventory to offsite demand mean losing control of the page?

Not if your relevance layer stays the decision-maker. Offsite demand should compete for a position under the same standard as everything else, not bypass that standard because it came with its own budget attached.

‍

How is a demand partnership like Teads or Skai different from an alignment partnership like Zitcha?

Teads and Skai bring offsite advertiser budget into your onsite inventory. Zitcha's Margin Manager aligns your own advertising and merchandising decisions across channels. One is about where the money comes from; the other is about what the money is allowed to do once it arrives.

‍

Do I need offsite demand before I can improve onsite relevance?

No, and you shouldn't wait for it. Onsite relevance is typically the fastest place to prove a result, because it doesn't depend on any external demand source being connected yet.

‍

Get in touch with Pentaleap to learn more.

‍