TAG Product Specification
for Payment ID System
The Payment ID System is designed to reduce the volume of illegitimate ad
inventory sold by enabling media buyers to identify and avoid untrustworthy
parties in the supply chain; and take effective remedial action if some party issupplying illegitimate inventory. Building atop earlier versions, this productspecification describes the mechanisms for transferring Payment IDs, how to
implement Payment Identifiers, and how to utilize resulting data.

Version 2.0
Released June 2017

Table of Contents
Background ...................................................................................................................... 3
Scope and Applicability .................................................................................................... 4
Ad Tech Supply Chain ...................................................................................................... 6
Terminology ...................................................................................................................... 7
Technology-Neutral Product Requirements ..................................................................... 9
Identifiers..................................................................................................................... 10
Payment ID Nodes ...................................................................................................... 10
Mapping Payment Identifiers to Accounting Records ................................................. 12
What are the systems involved for linking? ............................................................. 12
Generating New Identifiers ...................................................................................... 13
Intermediaries Not Handling Financials ...................................................................... 13
Payment ID Data Governance .................................................................................... 13
Supply Side Implementation ........................................................................................... 15
OpenRTB Implementation........................................................................................... 15
Attribute - Type - Description ................................................................................... 15
Flow of Inventory ......................................................................................................... 16
Flagging Events .......................................................................................................... 17
Missing Identifiers Where One is Expected to Exist ................................................ 17
Incorrect identifiers / Spoofed Identifiers ................................................................. 17
Mapping Payment Identifiers to Accounting Records ................................................. 17
What are the systems involved for linking? ............................................................. 18
Relevant scenarios...................................................................................................... 19
Redirects .................................................................................................................. 19
Widgets and other Embedded Content Providers ................................................... 19
Demand Side Implementation ........................................................................................ 20
Recognize Payment ID chains in bid requests............................................................ 20
Identify segments of the chain for pre-bid decisions and any pertinent chain
investigation ................................................................................................................ 20
Consume the Payment ID chain for recording ............................................................ 20
Recording ................................................................................................................ 20
Opportunities for Capturing the Payment ID Chain ..................................................... 21
Win Notification and Macros .................................................................................... 21
Appendix A: Examples of Acceptable Identifiers ............................................................ 22

2

Background
Transparent practices enable principled actors to differentiate themselves from sources thatgenerate or trade in poor quality or fraudulent traffic. Principles that achieve this, in addition toother tools and resources available to the market, allow companies across the industry to take
important strides towards fraud-detection and fraud-resolution.
Consider a case where certain ad impressions have been confirmed as having been
fraudulently hidden. If some party has gone to the effort of deliberately hiding ad slots, then thisparty is likely to be defrauding media buyers in ways that have not yet been confirmed. This
party should not be trusted by media buyers. Unfortunately, because it is currently not possible
to identify all the parties in the supply path of any individual ad impression, it is not possible toidentify and isolate this untrustworthy party. This makes it difficult for media buyers to avoid
buying inventory from this untrustworthy party in the future.
The lack of transparency into the supply path of any individual ad impression also makes
effective remedial action more difficult. If a media buyer makes a valid claim for a refund
because illegitimate inventory has been supplied, then it is currently difficult to propagate thisclaim back to the party ultimately responsible for supplying the illegitimate inventory. It is also
currently difficult to pass on recommendations of corrective action to the appropriate parties.

3

Scope and Applicability
Automation of the buying of media has led to the evolution of a very complex advertising supply
chain. In any given set of transactions (which combined, result in the purchase of an ad slot andthe delivery of an ad) each member of this supply chain has knowledge only of the business
entity directly adjacent to them. In many cases, this knowledge is itself limited or false. It isnearly impossible for any entity on that supply chain to trace a piece of media back to an actual
source, and know who will ultimately benefit monetarily from the transaction. The opaque natureof the supply chain has been a contributing factor to increased abuse of the ad ecosystem.
For the buying of media to reach its full potential as an important component of the advertisingindustry, it needs more transparency. This document seeks to address the transparency issue
as it relates to the flow of money. Adoption of the proposal detailed herein by a significant
portion of the programmatic industry will make it possible for any buyer and/or their agent, to“follow the money” back through the supply chain to the original source of inventory. The
benefits of which include but are not limited to:•••

The ability to identify and stop buying from suppliers engaged in the transaction of NonHuman Traffic (NHT) or otherwise Invalid Traffic (IVT).
The ability of an exchange, or network to in turn stop buying or brokering in IVT and NHT
based on knowing the source.
To provide recourse to a buyer who programmatically purchases media that has been
misrepresented by a seller.

In short, this proposal represents a major step toward limiting the proliferation of fraud in the ad
ecosystem.
The buyer of any non-blind ad slot should be passed a chain of unique, persistent supplier
identifiers with each purchased impression. Any full chain of payment IDs comprises a set of IDs
that distinctly identifies the publisher and each intermediary involved in the transaction.
•••

We strongly encourage (but do not require) that a “centralized” identifier be adopted byeach and every intermediary who is either paid to supply the ad slot (e.g. exchange,
network, sell-side platform) or in some way handles the inventory during the transaction(buy side ad server, sell side ad server, etc.). Centralized in this case simply means,intermediary ids do not collide.
At the point of the chain creation, downstream intermediaries assign and issue a“decentralized” identifier for the source of the inventory they are representing.
Decentralization means the IDs could indeed collide as they will be issued at thediscretion of each intermediary.
Any identifiers created by prior intermediaries passed to a given intermediary are also
passed forward to the purchaser of any given impression.

Taking the perspective of the inventory, the most upstream entity is the end publisher, while themost downstream entity is the advertiser. Illustrations in below sections flow left to right toreflect this. Every intermediary must maintain the chain and add their own intermediary ID(optional) and a unique, persistent supplier identifier, as follows:
1. Intermediaries issue persisting supplier identifiers for each entity (intermediary source orsource publisher) that they pay, meaning that the supplier identifier should map 1:1 with4

the supplier entry in the intermediary’s accounting system.
2. The first intermediary in any path includes the appropriate supplier identifier (inventory
source) with each ad slot received from upstream publishers (or, in the case of arecognized intermediary selling owned-and-operated inventory, the intermediary
includes an identifier for themselves). Details of each ad slot together with the newly
included supplier identifiers are then passed to downstream parties.
3. The second intermediary in any path appends the appropriate supplier identifiers (fortheir own source of the inventory) to the identifiers received from the first intermediaries.
Details of each ad slot, together with supplier identifiers provided by both the first andsecond intermediary, are then passed to downstream parties.
4. Intermediary N in any path appends the appropriate supplier identifiers to the identifiers
received from intermediary (N-1). Details of each ad slot together with supplier identifiers
provided by intermediaries N through 1 are then passed to downstream parties.
5. The chain is created and added to when an impression is put out to bid, such thatbidders/buyers can use the chain as input when deciding whether to bid/buy or not andhow much to bid. The chain will be ‘recorded’ when there is a buyer who bought the
impression.
Note:• There is deliberately no requirement that some entity will be given the same supplier
identifier by two distinct downstream intermediaries.
• Identifiers are not necessarily globally unique. Each intermediary is required to assign
distinct identifiers to each upstream party that is paid. However, there is nothing toprevent overlap in identifiers assigned by different intermediaries

5Ad Tech Supply Chain
The ad tech supply chain can have many nodes as it passes through systems. The following
diagram is an attempt to simplify the various diagrams in the TAG document.
Entities vested in the workflow:0) Content: Some digital content such as a video (vimeo.com) website (cnn.com), app (CNN for
iPhone) or embedded content inside of some other app or webpage (cnn’s instant articles within
Google News or Facebook)1) Seller Technology: Some SDK, content management system, ad server or header- bidding
container that coordinates the advertising in real-time either via some completely server-side
technology or hybrid server and client side tech.
2) Exchange: The technology that offers the impression for auction, generally via an ad tag orother HTTP GET request (for header bidding). There is an emerging class of server-sideconnections between the "Seller Tech" and the "Exchange" that may be one of:• Ad Tag via HTTP
• HTTP GET or POST API (header bidding for instance) ● Server-side custom protocol(JSON in a few variants)
3) Buyer Technology: This could be a legacy ad network using ad tags, a DSP that serves aredirect to an agency/advertiser ad server, or a "native ads system"
4) Advertisement: Some technology that supplies the ad creative itself via some mechanism.
Delivery maybe via redirect in a web view, or some server-side ad-content stitching. Generally,an ad server, but may vary in the case of video or native ads which function differently.

6Terminology
Intermediary ID: The optional, self-assigned global identifier for the entity appending a newnode to the chain, as an act of self-signing.
Inventory Source ID: This required identifier is appended by the intermediary to the full chain torepresent the immediate preceding upstream entity that sold the impression opportunity.
Node/ID pair: A single segment of the Payment ID chain, separated by dashes, and appended
to the full chain. A node presents itself in the form of a pairing of the Intermediary ID and an
Inventory Source ID. Nodes must be appended by each relevant intermediary before passing onto the next downstream entity.
Chain: A series of linked nodes denoting the flow of inventory originating from an end publisher,where each node represents either a transaction or redirection by a downstream entity. This
captures all varying scenarios in chain structure resulting from won bids, forms of resale, or
redirects.
Intermediary: Any business which represents/sells programmatic inventory that is not their own
or any party involved in redirection of a programmatic impression.
With the exception publishers, each type of company listed in the table below will fall into
the intermediary categorization dictating the guidance it should follow throughout thepresent document.
Typical intermediaries include entities that are party to the financial transaction to theextent that they either represent or sell media inventory.
Atypical intermediaries, like buy-side or sell-side ad servers, are classified as suchwhen their functions are limited to facilitating a redirection of an impression and do not
act as the buyer or seller of that opportunity.
This distinction is made to provide guidance on who should append to the chain andwhat they are appending. Typical intermediaries are required to append at least theInventory Source ID to the chain and pass along the existing chain. Atypicalintermediaries have the option of appending only their Intermediary ID to the chain andnot the Inventory Source ID (unless they are explicitly party to the transaction). Allintermediaries that receive a payment ID chain are required to pass along the complete
payment ID chain to the next downstream party. Publishers are the most upstream party
so they do not initiate chains and would not append any IDs.
Further descriptions on industry stakeholders:Type
Publisher

Description
Owns and operates the media property and offers their own ad
placements to buyers.

7Embedded Content
ProviderA third-party content component embedded on media properties
which incorporates paid advertisements

Publisher Network

Represents a group of publishers, typically in a vertical, for purposesof acquiring advertisements

Ad Network

Aggregates supply and fills advertisements for Publishers andPublisher Networks based on their own demand relationships

SSP/Exchange

Marketplace connecting publishers and networks with ad buyers

DSP

Marketplace providing media buying opportunities for advertisers
and their trading desks.

Buy-Side Ad Server*

Hosts Advertising Creative on behalf of Agencies and Advertisers

Sell-Side Ad Server*

Delivers an Ad to the Publisher's Site where the Ad Server accountholder is the publisher.

*Atypical intermediaries

8Technology-Neutral Product Requirements
With the exception of a publisher, each type of company listed in the table below will fall into theintermediary categorization dictating the guidance it should follow throughout the present
document.
Typical intermediaries include entities that are party to the financial transaction to the extent
that they either represent or sell media inventory. Atypical intermediaries, like buy-side or sellside ad servers, are classified as such when their functions are limited to facilitating aredirection of an impression and do not act as the buyer or seller of that opportunity.
This distinction is made in order to provide guidance on who should append to the chain andwhat they are appending. Typical intermediaries are required to append at least the Inventory
Source ID to the chain and pass along the existing chain. Atypical intermediaries have theoption of appending only their Intermediary ID to the chain and not the Inventory Source ID(unless they are explicitly party to the transaction). All intermediaries that receive a payment ID
chain are required to pass along the complete payment ID chain to the next downstream party.
Publishers are the most upstream party so they do not initiate chains and would not append any
IDs.
Further descriptions on industry stakeholders:Type

Description

PublisherOwns and operates the media property and offers their own ad placements
to buyers.

Embedded Content
ProviderA third-party content component embedded on media properties which
incorporates paid advertisements

Publisher Network

Represents a group of publishers, typically in a vertical, for purposes ofacquiring advertisements

Ad Network

Aggregates supply and fills advertisements for Publishers and Publisher
Networks based on their own demand relationships

SSP/Exchange
DSP

Marketplace connecting publishers and networks with ad buyers
Marketplace providing media buying opportunities for advertisers and theirtrading desks.

Buy-Side Ad Server*

Hosts Advertising Creative on behalf of Agencies and Advertisers

Sell-Side Ad Server*

Delivers an Ad to the Publisher's Site where the Ad Server account holder
is the publisher.

*Atypical intermediaries
This section will expand on the fundamental concepts underlying any Payment ID build.
Requirements described below are technology-neutral and apply to all entities developing
Payment ID systems.

9

Identifiers
A Payment ID chain is a series of identifiers that provides information about a particular
impression opportunity’s financial record. Two types of identifiers may appear in a Payment ID
chain:••The Intermediary ID, and,The Inventory Source ID

Individual companies are responsible for using these two identifiers in order to create a piece ofa Payment ID chain. The Intermediary ID is an optional, self-assigned and persisting global
identifier that a company uses to represent itself across all of its Payment ID activity throughout
the supply chain.
Companies that are TAG Registered may opt to use their TAG-ID as the Intermediary ID within
a Payment ID segment and are strongly recommended to do so.

Since the Intermediary ID is optional and self-assigned (as opposed to originating out of acentralized environment), companies that decide to use a different global identifier should be
advised that they risk operating under a colliding identifier.
Given the significance that intermediary IDs may carry across partnerships, it is problematic forthe market if there are sets of duplicate Intermediary IDs existing at the same time (even if they
never collide in reality). Colliding Intermediary IDs can only be discovered by an upstream party
possessing the duplicate so it is the responsibility of every intermediary to call attention tocolliding sets of IDs. TAG will host an internal volunteer registration of Intermediary IDs in orderto keep track and for reference when a resolution is needed.
Intermediary IDs provide significant value in “signing” the required Inventory Source ID. An
intermediary company must append the Inventory Source ID to the full chain in order to identify
the immediately preceding, upstream entity that sold them the impression opportunity. Note that
the Inventory Source ID does not always refer to the end publisher.
The only scenario in which the Inventory Source ID will refer to the end publisher is when thecompany has a direct relationship with the publisher and is the first party to offer up the
impression opportunity and so creates a Payment ID chain from scratch.

Payment ID Nodes
Within any single node in a payment ID chain, the ID pairs should not be conjoined and should
be separated in order to easily determine the ID type. Additionally, when separating the two
identifiers, the Intermediary ID should exist to the left of the separator, leaving the Inventory
Source ID to be located at the right side.
10

Core differences between the two identifiers:
Intermediary ID

Inventory Source ID

Optional

Required
Identifies the adjacent source of the soldimpression opportunity
Rightmost ID in a single node
Can be appended by only typicalintermediaries

Identifies the intermediary appending
Leftmost ID in a single node
Can be appended by any intermediary type

Examples in which the identifiers are easily distinguished by a colon demarcating them (angle
brackets included for ease of reading):<IntermediaryID>:<InventorySourceID>
Figure 1

Each ID type is easily recognized so long as there is a separator between the two ID pairs. A
different example with sample identifiers divided by a colon:
XYZ01234:ABCD56789
Owing to the optional nature of the Intermediary ID, nodes in payment ID chains that only
contain a single identifier must include the colon in order to signal its position relative to thedelimiter. An example in which the identifier is located to the right of the colon, indicating that itis the Inventory Source ID::ABCD56789
If the node is being appended by an atypical intermediary choosing to self-identify, the identifier
needs to sit at the left of the colon to show that it is the Intermediary ID:
XYZ01234:
Appending to the chain should be a function of adding a unique separator like a hyphen,allowing you to distinguish your ID pairs as a separate piece from the other nodes received in11the chain. Companies must always pass along the preceding chain as they received it, without
any modifications to the original nodes within the chain.
For instance, multiple nodes separated by a hyphen (note: “IntermediaryID” and“InventorySourceID” shortened to “IntID” and “InvSoID,” respectively, to avoid confusion due toline breaks):<IntID>:<InvSoID>-<IntID>:<InvSoID>...
Figure 2 with three chains, each containing three nodes:

Note: The first chain contains three full nodes. The second chain contains a node (Node 2) with
only the Inventory Source ID, appended by a typical intermediary choosing to not self-identify.
The third chain contains a node (Node 2) with only the Intermediary ID, appended by an atypicalintermediary choosing to self-identify.
In the first two chains, the Inventory Source ID in each node subsequent to the initial node
(Node 2 and Node 3) refers to the adjacent intermediary that received payment for the soldimpression opportunity, and not the end publisher. In the first hop, the Inventory Source ID (i.e.
ABCD56789) is the identifier assigned to the publisher by the first intermediary. In the secondhop, the Inventory Source ID (i.e. AA111) is the identifier assigned to the first intermediary(existing at Node 1) by the second intermediary (existing at Node 2).
In the final chain, the Inventory Source ID located at Node 3 (i.e. FY1398) refers to theintermediary in the first node that received payment for the sold impression opportunity. This
chain is different from the two chains above it in that it contains two typical intermediaries andan atypical intermediary (e.g. an ad server). The first two chains contain nodes all appended bytypical intermediaries.

Mapping Payment Identifiers to Accounting Records
Existing internal IDs may be used as payment identifiers for the inventory source provided theseIDs meet the identifier requirements detailed in the section above. If existing internal IDs do notmeet the requirements, inventory source IDs must be generated anew and linked 1:1 to each
inventory source. Successfully mapping Payment identifiers to individual inventory sources
enables the company offering the impression for auction to generate a new Payment ID chain
using the syntax.

What are the systems involved for linking?
Technology platforms should ensure that supply sources have an identifier that is associatedwith their inventory and with their accounting information.
12

Figure 3

Generating New Identifiers
A company should have one Intermediary ID that it consistently uses across the supply chain.
Additionally, a company should have one inventory source IDs mapped 1:1 to the supply
source. These Inventory Source IDs must also be consistently used within the company’s
platform.
When deciding what identifiers to use for partners, the company should consider whether their
existing ID system meets the below requirements. There is no explicit need to generate an
entirely new set of IDs provided the requirements for what are considered acceptable Identifiers
are met. At a minimum, an identifier within a single segment of a chain must be:••

Alphanumeric (A-Z; 0-9); and contain only URL-friendly characters (with no special
characters), andCase sensitive,

See Appendix A for enumerated examples and further guidance on how identifiers should look.

Intermediaries Not Handling Financials
Only intermediary systems that handle and transmit money from payers to payees should
assign IDs. For instance, an ad/content server (and associated vendor) automates the processof serving ads for supply creator X. It doesn’t handle the money. An Exchange Y that gets theimpression from the ad server for auction handles the money. A Bidder Z that wins animpression from Exchange Y typically handles the money for Buyer Q. If Bidder Z is nothandling the money to pay Exchange Y, the Bidder Z should not append its own ID and simply
append the ID of the buyer that is directly paying the Exchange Y.

Payment ID Data Governance13Companies should ensure that the Payment ID chains are being captured upon the sale of animpression opportunity such that they are recording their segment in the transaction. Thesemight live in the markup or in a separate database where the company regularly keeps track oftransactions occurring through their platform.
In terms of how long a company must keep these records - this is ultimately up to thecompany’s data governance policies. Ideally, payment ID chains should be kept for a longenough period of time such that a company can begin to accumulate patterns.
The point at which the payment ID chain can be recorded will most likely depend on how thecompany defines the billing event.
Figure 414

Supply Side Implementation
OpenRTB Implementation
We are recommending that OpenRTB represent the Payment ID chain as single string. Bidders
will be able to create easy-to-define logic that blocks bidding on any bid request that contains an
Inventory Source ID or Intermediary ID that is on their blacklist. Bidders can also record thechain for post-buy analysis.

The below table demonstrates how Payment ID should be expressed in OpenRTB v2.5. The“pchain” attribute is added to the Source object (referenced in section 3.2.2 Object: Source of
OpenRTB 2.5).

Attribute - Type - Description
pchain - string; recommended - Logical Payment ID chain string containing embedded syntax
described in the TAG Payment ID Protocol document version 1.0
Logical Payment ID chain string containing embedded syntax described in the TAG Payment ID
Protocol document version 1.0
To use it in prior v2.x versions and stay compliant, the “pchain” field would need to be added as
an extension, “ext”, within the top-level bid request object rather than directly.
Example chain containing one node"pchain": "XYZ01234:ABCD56789",
Example of a chain containing two nodes"pchain": "XYZ01234:ABCD56789-STUV543:AA111",
Example of a chain containing two nodes with missing information
Note the intermediary is not provided in the second node.
"pchain": "XYZ01234:ABCD56789-:AA111",
Seller technologies representing or selling media inventory must be able to execute on threemain tasks:
1. Operate a working system whereby payment identifiers are mapped to the accounting
records of partners.
2. Generate and append new Payment ID chain segments where a chain does not exist
when:
3. The Exchange/SSP has a direct relationship with the end publisher and is initiating thechain, or,
4. A previously existing Payment ID chain has been compromised and lost.
5. Pass forward a Payment ID chain to the next downstream party without modifications toany preexisting nodes within the chain.

15

Flow of Inventory
In the diagrams below we illustrate how identifiers should be assigned by upstream
intermediaries and passed along to downstream parties.
With transparency into these supply paths, media buyers can take effective proactive remedialaction (blacklisting problematic paths where fraud has been detected) and effective reactive
remedial action (requesting refunds for inventory previously bought from these paths). Each
entity passes on the information it gets, its understanding of where the inventory is coming from,as well as the self-issued Intermediary ID. If used correctly, you can see when fraud appears
and cut it off.
Figure 5

Figure 6 with a highlighted redirect scenario:

Companies in the supply paths in the above figures and their identifiers:
Name

ID

NY Times (Inventory Source ID from SSP-D)UQMR883

CNN (Inventory Source ID from SSP-V)

VEG11101

SSP-D (Intermediary ID)

RES123

SSP-D (Inventory Source ID from Exchange E)

713KRBBZZ

SSP-V (Intermediary ID)

QAY234

SSP-V (Inventory Source ID from Network X)

98GFnDJ16

Network X (Intermediary ID)

GBC345

Network X (Inventory Source ID from Exchange E)

901JFVIQY

Exchange E (Intermediary ID)

LMZ456

The two complete supply paths for inventory sold through Exchange E are uniquely identified
with the following concatenated identifiers forming unique payment ID chains:
1.
2.

RES123:UQMR883-LMZ456:713KRBBZZQAY234:VEG11101-GBC345:98GFnDJ-LMZ456:901JFVIQY

Flagging Events
Missing Identifiers Where One is Expected to Exist
If a publisher network starts the chain; any intermediary that does not have a direct relationshipwith the publisher will append to the chain (unless it was missing). Once a relationship isestablished, if you start noticing inventory missing identifiers, this should be a flagging event.
This requires some mechanism where the system is able to recognize that the network
participates and should send an id. So, knowing that a specific network is supposed to initiate achain is crucial. When a chain was expected to exist and has disappeared the exchange/SSP
has to create anew.
“-XYZ01234:ABCD56789”“:XYZ01234:ABCD56789” (one missing node)
Example of a chain containing two nodes with missing information
Note the intermediary is not provided in the second node.
"pchain": "XYZ01234:ABCD56789-:AA111"

Incorrect identifiers / Spoofed Identifiers
If spoofed (someone pretends to be someone they are not) you can see the inconsistency in thepattern of IDs, traffic, etc. to identify a spoofed source.
Self-issued IDs can be spoofed -- TAG is recommending that intermediaries use their TAG-IDs
and established links to internal systems for monitoring consistencies in IDs and payment
information.

Mapping Payment Identifiers to Accounting Records

17

Existing internal IDs may be used as payment identifiers for the inventory source provided theseIDs meet the identifier requirements detailed in the section above. If existing internal IDs do notmeet the requirements, inventory source IDs must be generated anew and linked 1:1 to each
inventory source.
Dependency: Successfully mapping Payment identifiers to individual inventory sources enables
the company offering the impression for auction to generate a new Payment ID chain using thesyntaxWhat are the systems involved for linking?
Seller technology should ensure that supply sources have an identifier that is associated with
their inventory and with their accounting information.
Compare Figure 7 and Figure 8 below:
Figure 7

Sell-Side Platform D (SSP-D) is offering two impression opportunities for sale to Exchange E
and Exchange F. SSP-D provides both exchanges with the same Payment ID chain where theirself-assigned Intermediary ID is “RES123” and their Inventory Source ID for NY Times“UQMR883.”

Figure 8

Sell-Side Platform D (SSP-D) is offering two impression opportunities for sale to Exchange E
and Exchange F. SSP-D provides each exchange a variable Payment ID chain where they do
not use a consistent Inventory Source ID for NY Times (“UQMR883” vs. “GFL774”).

18

Relevant scenarios
Redirects
This section concerns passing along Payment ID chains across server-side connections
between a seller technology and exchange. The main challenge facing companies in this
scenario involves maintaining the chain and passing forth data up towards the buyer.

Widgets and other Embedded Content Providers
The publisher has a relationship with the advertising widget and is paid by the widget provider.
In scenarios where there is no way to know from payment ID if something is an ad injector,
companies will have to build up reputations for ID chains in order to assess the quality of
inventory.

19

Demand Side Implementation
On the opposite side of seller technology is buyer technology. Bidders that enable advertisers
and agencies to connect to ad exchanges in order to purchase impression opportunities must
be able to:1.
Recognize Payment ID chains in bid requests.
2.
Identify segments of the chain for pre-bid decisions and any pertinent chain
investigation.
3.
Consume the Payment ID chain for recording, making sure to append their own ID pairto the end of the chain.

Recognize Payment ID chains in bid requests
To recognize Payment ID information in OpenRTB v2.5, the bidder should be able to recognize
a pchain attribute within the Identifier object at the bid request level. This field is delivered as astring so a DSP should treat this as a parsable string with distinct parts to it.
In order for the segments of the chain to contain meaning, the DSP must have an existingaccounting system that maps Intermediary IDs to their internal partner records.

Identify segments of the chain for pre-bid decisions and any pertinent
chain investigation
Successfully mapping Payment identifiers to individual inventory sources enables the company
buying the impression for auction to enable for pre-bid decisions whereby a buyer on a DSP
platform can modify their buying practices. This may entail bid prices, blacklists, etc.

Consume the Payment ID chain for recording
When the bidder wins the auction for the impression opportunity, the chain should be ‘recorded’
with the bid response logs. The chain should be closed by the Intermediary ID belonging to thebidder that won the impression opportunity.

RecordingCompanies should ensure that the Payment ID chains are being captured upon the sale of animpression opportunity such that they are recording their segment in the transaction. Thesemight live in the markup or in a separate database where the company regularly keeps track oftransactions occurring through their platform.
In terms of how long a company must keep these records - this is ultimately up to thecompany’s data governance policies. Ideally, payment ID chains should be kept for a longenough period such that a company can begin to accumulate patterns.

20

Examples of this in practice my entail assessing for the presence of any deltas in ID chain
presentations. These can be used to create aggregated reputation models to ingest and flag
data on changes in Payment ID chains.
A reasonable starting point for Payment ID chain storage may be 180 days. For purposes
related to building reputation, it may not be necessary to keep the chains for as long a period.
Companies may consider building data models that utilize the data to act on it. For purposes
related to billing, it may be necessary to reference the chains and history of impression
opportunities attached to them (e.g. for referencing with law enforcement).
The point at which the payment ID chain can be recorded will most likely depend on how thecompany defines the billing event.

Opportunities for Capturing the Payment ID Chain
Additional points for capturing Payment ID chains may be at the point of the bid request or via
an optimization utilizing win notifications and the existence of a defined macro. Depending on aparticular organization’s practice for defining the billing event - recording payment ID chainsshould at least be tied to these events. Both of these use cases for capturing the chain can
support efforts to assess quality of inventory and performance (e.g. “win rate by pchain”),
amongst others.

Win Notification and Macros
In order for the winning bidder to consume the Payment ID chain, a Payment ID macro should
be supported in the “nURL” and “adm” parameter.
${PAY_ID} – Full Payment ID Chain
Prior to calling a win notice URL, search the specified URL for the defined macro and replace itwith the appropriate data.

21

Appendix A: Examples of Acceptable Identifiers

22