When GPID gets messy, publishers pay the price, with Eilon Goldstein of Rise

BY ROB BEELER, BEELER.TECH + EILON GOLDSTEIN, SENIOR PRODUCT MANAGER AT RISE

GPID is one of those things a lot of publishers know they’re supposed to care about, but it’s easy to push into the “technical plumbing” bucket and move on. I get why. It doesn’t sound like the kind of thing that should be sitting at the center of a revenue conversation.

But that’s exactly the point of this conversation with Eilon Goldstein, Senior Product Manager at Rise, who recently wrote an exclusive analysis for us on how GPID still falls short.

GPID was created to solve a very real publisher problem: making sure the same ad placement can be recognized consistently as it moves through SSPs, wrappers, reseller paths, and all the other places inventory travels before a bid happens. When that identity breaks down, buyers lose confidence in what they’re seeing. And when buyers lose confidence, publishers usually feel it in CPMs, demand, and optimization.

The tricky part is that a publisher can technically “have GPID” and still have a messy implementation that works against them. Opaque strings, legacy ad unit conflicts, suffixes from refresh or infinite scroll, multi-size splitting, and duplicated supply paths can all make the same placement look like several different placements. To a buyer, that creates uncertainty. To a DSP, it creates noise. To a publisher, it can quietly turn quality inventory into something buyers down-rank or avoid.

So this isn’t a conversation about checking a box. It’s about whether your placement identity is helping buyers understand and value your inventory, or giving them another reason to bid less. Eilon gets into what GPID was meant to solve, where implementations tend to go sideways, and what publishers should look at first if they want to know whether their setup is helping or hurting them.

Rob: A lot of publishers have heard of GPID, but many don’t think about it day-to-day. What problem was GPID actually meant to solve for publishers in the first place?

Eilon: GPID was introduced to give every ad placement a persistent, publisher-defined identifier. The core problem it was solving is that without it, the same ad slot can appear with completely different identifiers as the request moves across SSPs, wrappers, and reseller paths. That causes buyers to treat identical inventory as separate opportunities, which leads to redundant bidding and inflated costs.

For publishers, a well-implemented GPID means buyers can recognize your inventory reliably, wherever they see it, and bid on it with more confidence.

Rob: On paper, GPID should make inventory more transparent and more valuable. Where does that break down in the real world?

Eilon: The core promise of GPID is persistence.

The identifier should stay the same as the request moves through the supply chain. In practice, that promise gets broken in several predictable ways: some publishers never implement GPID at all, others use non-descriptive strings that give buyers no usable context, legacy ad unit codes create conflicting identity signals, dynamic page environments introduce suffix changes that make the same slot look like a new placement, and multi-size or multi-SSP setups generate duplicates that distort bidding.

Each of these is a different failure mode, but they all erode the same thing: a buyer’s ability to trust what they are looking at.

Rob: One issue you call out is that many GPIDs are unclear or unreadable. From a buyer’s perspective, why does that immediately impact how they value a placement?

Eilon: If a GPID is something like site882_pos99_x, a DSP has no way to tell whether that is an above-the-fold premium unit or a below-the-fold slot at the bottom of the page. They both look the same. When buyers cannot verify the location or quality of the inventory, the safest move for them is to bid down or ignore the signal entirely to manage their risk.

A descriptive format like /news/finance/sidebar_top immediately tells a buyer what they are purchasing and where. That context is what enables proper optimization, and without it, publishers are leaving value on the table.

Rob: You also highlight a kind of “dual identity” problem: where GPIDs and legacy ad unit codes both exist. What does that do to reporting and optimization on the publisher side?

When publishers send both a GPID and a traditional ad unit code, like a GAM path, and those two do not perfectly align, it creates mismatches in reporting. Performance data ends up fragmented across two different ID types. Buyers are then forced to guess which signal to trust, which dilutes the GPID’s role as the single source of truth.

For publishers, the downstream effect is that optimization becomes harder and less reliable, because neither identifier is giving a clean, unified picture of how a placement is performing.

Rob: Dynamic environments like infinite scroll and refresh introduce suffixes that break persistence. Why does that seemingly small change have such a big downstream impact?

Eilon: When a publisher appends a modifier like _1 or #scroll3 to a GPID on each new load or refresh, the DSP reads that as a brand new placement. It has no record of the original. The result is that buyers end up over-bidding on early scroll positions where they have some signal, while failing to track performance or viewability across the full lifetime of the placement.

What feels like a minor technical detail on the publisher side translates directly into distorted bidding behavior and lost optimization signal on the buy side.

Rob: The report describes duplication and multi-size splitting as a kind of hidden inefficiency. What’s actually happening in those scenarios, and how does it affect publisher revenue?

Eilon: When a multi-size request gets split into separate bid requests, one for 300×250 and another for 728×90, each often comes with a slightly different GPID. At the same time, when inventory moves through multiple SSPs or reseller paths, you get what are essentially ghost copies of the same placement.

\The consequence is that buyers end up bidding against themselves without realizing it. That wastes query-per-second capacity and erodes trust in the supply path. It is described as a hidden scourge precisely because the inefficiency is real but hard to see without digging into the bid logs.

Rob: You make the point that buyers are starting to prioritize “clean” GPIDs and down-rank messy ones. What does that mean for publishers who haven’t cleaned this up yet?

Eilon: There is already a two-tier ecosystem forming.

Publishers with persistent, descriptive, well-implemented GPIDs get prioritized in bidding algorithms. Those without, or with volatile or opaque GPIDs, are treated as opaque supply and see lower CPMs and reduced demand as a result. As buyers formalize GPID requirements in supply contracts and use traffic shaping to reward clean placement identity, the gap between those two tiers will only grow. Publishers who have not addressed this are not in a neutral position.

They are actively being down-ranked.

Rob: If a publisher wanted to sense-check whether their GPID implementation is helping or hurting them, what’s the one thing they should look at first?

Eilon: Start with whether your GPIDs are descriptive and stable.

If a buyer looking at your bid logs sees strings that give no readable context about the placement, or if the same slot shows up with different IDs across refreshes or supply paths, that is the clearest sign the implementation is working against you. Descriptive, human-readable GPIDs that remain completely static after initial assignment are the baseline. Everything else, deduplication, traffic shaping performance, CPM levels, follows from getting that foundation right.

👉Want to stay in the loop with what’s happening in the Beeler.Tech community? Subscribe to our newsletter. If you’re interested in attending or sponsoring a future event, you can explore our upcoming events here.

This is content created in paid partnership with Rise. We only feature partners who we believe bring real value to the publisher community.