The architecture of Prebid Programmatic Guaranteed (PG) is inherently multi-vendor. A PG
Host Company runs a global distributed cluster of Prebid Servers. These servers handle the ‘real-time’ requests… those that need to have millisecond response times. They also run a couple of backend servers that help manage the PG line items. One of them
is called the
General Planner. The General Planner can connect out to multiple sources of PG Line Items, and that’s where you come in – as a PG Bidder, you can contribute PG Line Items into the auction ecosystem for the publishers who utilize the Host Company’s installation.
Here’s a diagram from the white paper.
Delivery Stats Serviceis available for PG Bidders to obtain up-to-date reports on how line items are delivering.
Dimension Value APIshould be used by bidders to create targeting values.
These are the high level steps for how to develop a PG Bidder and plug it into a Host Company’s implementation.
The Host Company will give PG Bidders access to their Dimension Value API which will let them know what attributes and values their Prebid Servers can target at runtime for particular clients. The values used will differ between Host Companies and publishers. For example, there may be different geographic and device info services. Publisher AdSlot and First Party Data fields will also vary.
Once granted authenticated access to the Dimension Value endpoint, you’ll use the it to query it to get attribute names and values specific to the accounts you’re working with. e.g.
There are various options for filtering data. See the Dimension Value API documentation for more details.
In order to access client-specific targeting data, you’ll need to know the account ID the Host Company uses for each publisher.
There are two reasons PG Bidders need data from the Host Company’s PG Delivery Stats Service:
Some example Delivery Stats queries:
When the PG Bidder is ready for integration with the Host Company, they’ll provide an authenticated secure endpoint that will answer requests from the Host Company’s General Planner. The path of this endpoint can be anything you’d like. It will receive these query string parameters:
|since||string||no||Timestamp in ISO-8601 format. For example, 2019-02-01T03:00:00.000Z. Service should respond with all meta data for active or nearly-active line items and schedules that got updated since this timestamp. Absence of this parameter signals request to return all active or nearly-active line items.|
|hours||string||no||Number of hours of plans desired i.e. provide the next 3 hours worth of plans|
Here’s an example JSON response that might come from your bidder planner.
At this point, your endpoint needs to respond quickly with the most recently calculated set of PG line item pacing plans. A
plan is a set
of instructions to Prebid Server that tells the system how often to serve
a line item in a given period. e.g. “serve LineA 50 times from noon-12:05, 55 times from 12:05-12:10, …”
The General Planner will be configured to call your endpoint every 1-10 minutes depending on the Host Company.
See PG Plan Definition for more details.
At a high level, pacing a line item seems like it might be simple:
NumberOfImpressionsEach5MinPeriod=TotalImpressionsRemaining+3percentBuffer / NumberOf5MinPeriodsRemaining
But this approach wouldn’t perform well:
Likewise, another naive approach is to try and immediately catch up to the “even delivery” line:
ImpressionDeficit=TotalImpressions+3percentBuffer - TotalImpressionsShouldHaveByNow NumberOfImpressionsThis5MinPeriod=ImpressionDeficit * NoiseFactor
Potential problems with this algorithm:
Here are some examples of desirable delivery patterns:
And these are examples of delivery patterns to avoid:
For more information, see the “Plans” section of the Intro to PG Whitepaper.
The PG Host Company may require periodic of testing with your pacing algorithm because undesirable token management from on PG Bidder could affect line item delivery from other PG Bidders.