Prebid.js integration options

[bwschmidt]

This is an issue to list possible Prebid.js interactions only for the purpose of discussion.

SSPs and DSPs do not require a seed per impression opportunity given the model terms and this design assumes a simplified approach of allowing the publisher to collect signatures per impression opportunity if they wish for the purposes of an ad specific audit log, but does not require it. In reality, the DSP is required to sign if they return an opportunity, regardless if they actually used the PAF data to target a campaign, and so the application of a creative level audit log does not seem to bring great value, but adds much complexity and cost for all the parties involved. This may not be the end state of PAF, but I strongly suggest it for the MVP.

Exposing PAF data to Prebid.js

The simplest option here is likely for paf-lib.js to expose a function in the window that a Prebid.js identity submodule will call to retrieve the PAD data and seed.
PAF.getDataAndSeed()
This function will return the encrypted identifiers, preferences, and a signed transmission seed. In this case the publisher can control who can read the PAF data through a Prebid.js configuration and the allowed bidders will have access to the data objects.

The data will be presented to SSPs in a similar fashion as in OpenRTB. If the bidder elects to use the bidRequest.userIdAsEids function, the output will look similar to this

{
  "eids": [
    {
      "source": "paf",
      "uids": [
        {
          "atype": 1,
          "id": "7435313e-caee-4889-8ad7-0acd0114ae3c",
          "ext": {
            "version": 0,
            "type": "prebid_id",
            "source": {
              "domain": "operotor0.com",
              "timestamp": 1639589531,
              "signature": "12345_signature"
            }
          }
        }
      ],
      "ext": {
        "preferences": {
          "version": 0,
          "data": {
            "opt_in": true
          },
          "source": {
            "domain": "cmp1.com",
            "timestamp": 1639589531,
            "signature": "12345_signature"
          }
        },
        "transmissions": [
          {
            "version": 0,
            "seed": {
              "version": 0,
              "transaction_id": "a0651946-0f5b-482b-8cfc-eab3644d2743",
              "publisher": "publisher.com",
              "source": {
                "domain": "publisher.com",
                "timestamp": 1639582000,
                "signature": "12345_signature"
              }
            }
          }
        ]
      }
    }
  ]
}

otherwise if bidRequest.userId is used, the format would be take the userId key (pafId) and return the something similar to the following

{
  "identifiers": [
    {
      "id": "7435313e-caee-4889-8ad7-0acd0114ae3c",
      "ext": {
        "version": 0,
        "type": "prebid_id",
        "source": {
          "domain": "operotor0.com",
          "timestamp": 1639589531,
          "signature": "12345_signature"
        }
      }
    }
  ],
  "preferences": {
    "version": 0,
    "data": {
      "opt_in": true
    },
    "source": {
      "domain": "cmp1.com",
      "timestamp": 1639589531,
      "signature": "12345_signature"
    }
  },
  "seed": {
    "version": 0,
    "transaction_id": "a0651946-0f5b-482b-8cfc-eab3644d2743",
    "publisher": "publisher.com",
    "source": {
      "domain": "publisher.com",
      "timestamp": 1639582000,
      "signature": "12345_signature"
    }
  }
}

Prebid.js returning data to PAF

In the return case, there are actually only 2 likely options. One where adapters interact with paf-lib.js and another where we amend Prebid.js core to accept PAF signatures and Prebid.js exposes that data to paf-lib.js.

Adapters interact with PAF lib

This design is attractive for a few reasons. Especially for MVP

• Adapters have to do work for this regardless, so them appending new data to the prebid.js response or calling a window function is the same amount of work
• Less work on Prebid.js core and quicker time to market
• Prebid.js has not yet decided on PAF or not. Keeping the code in the adapters gives much more flexibility

Any PAF participant who receives PAF data through the PafIdentityModule would be required to return signatures to the paf-lib. This would easily be done by a function call such as PAF.addSignatures([transactionId, ...], signatures) where the transactionIds represent 1 to many transactions which were sent for a given Prebid.js request and the signatures are all of the signatures the SSP received along with their own.

Prebid.js PAF

This case is very similar to the case above, however bid adapters instead of calling PAF directly would append the signatures to the bidResponse, likely in the meta object under something like paf_signatures. In this case changes to Prebid core would be required to collect all the signatures and call the paf-lib.

[broggeri]

SSPs and DSPs do not require a seed per impression opportunity given the model terms and this design assumes a simplified approach of allowing the publisher to collect signatures per impression opportunity if they wish for the purposes of an ad specific audit log, but does not require it. In reality, the DSP is required to sign if they return an opportunity, regardless if they actually used the PAF data to target a campaign, and so the application of a creative level audit log does not seem to bring great value, but adds much complexity and cost for all the parties involved. This may not be the end state of PAF, but I strongly suggest it for the MVP.

A couple of problems with this:

1. I'm kinda sad to disappoint on this as I was also hoping we could land this simplification in the first demo. Bit after reviewing internally the planning, and also with IPONWEB (DSP) and 51Degrees (Audit Log viewer) who are also helping landing the first version of the demo in Q1, we don't have the time to change the spec so that we can use 1 audit log for several impressions.

I'm still looking forward for this simplification - we have it in our Q2 plan, but we need to make do with the current one to have a chance at a timely first demo and trial

2. Even once we simplify the audit log, it still must be possible to understand which parties are involved in the generation of which ad. This is not clearly expressed in the current draft of the Model Terms, but Joshua assures me the new WIP version will cover that. We'll have to review the potential solutions when updating the spec for Q2, but it might be that even then, we'll need to know the list of ad slots the transaction pertains to when creating the seed.

[broggeri]

Exposing PAF data to Prebid.js

Because of the above, I'm thinking we should split PAF.getDataAndSeed() into

PAF.getData()

and

PAF.getSeed(impression_slot_id) or PAF.getSeeds(list of impression_slot_ids).
In the V1, getSeeds would still return a different seed for each impression slot, but in Q2 we could transition to returning a single seed (with possibly the impression slot ids as metadata).

[broggeri]

Prebid.js returning data to PAF

Regarding the "Adapters interact with PAF lib" option - I'm unsure how we would know which bidder won the auction (I think it's necessary to make sure the parties actually involved in the displayed ad are the one that make it to the audit log).
Also I fear that there might be discrepancy regarding bidder that answer too late to participate to the auction.

WDYT ?

On the other hand, I do appreciate the focus on TTM. I wonder though if we may not need to have a Prebid.js fork for the test anyway because we will need it for the id module (or first party data module ?) and for the bidder adapters