Intent To Implement: Transaction IDs Community Extension

[robhazan]

IAB recently approved a new Community Extension to communicate transaction IDs in OpenRTB bid requests: https:/InteractiveAdvertisingBureau/openrtb/blob/master/extensions/community_extensions/per-imp-tids.md

We propose to make a schema change to the ortb object in Prebid 7 to add imp[].ext.tid, which a number of adapters will begin to consume, to send per-impression-opportunity transactions IDs to bidders.

[patmmccann]

Let's go ahead and copy transaction id into source.tid as well while we're at it

[bretg]

Interesting. Here's some context that may be helpful.

Prebid.js currently supports the following:

• bidrequest.auctionId is a UUID
• bidrequest.transactionId is a UUID

The PBS Bid Adapter sets:

• $.id to be bidrequest.auctionId
• $.imp[].id to be the AdUnit.code
• $.source.tid as a random UUID not connected to anything else

Is the thinking that PBJS-core (or the FPD Enrichment Module) would automatically add the PBJS transactionId to imp[].ext.tid?

[shahinrahbariasl]

Hey @patmmccann and @bretg , I'm helping with implementing this extension and I actually have the same question as Bret. When exactly do we want to add tid? If ortb configs are configured by pubs? Or by default when PBJS core creates the transactionId and adds it to the adUnit? (https:/prebid/Prebid.js/blob/master/src/prebid.js#L614).

I also see there are two objects in bidderRequest, ortb2 and ortb2Imp. Would this tid be in of one these objects? (eg. bidderRequest.bids[0].ortb2Imp.ext.tid). They can be empty though in case there's no FPD defined?

[patmmccann]

This is quite related to #8562

I think it should actually be in both, source.tid in openrtb and the new location in the latter object

@dgirardi does this interplay with what you are working on?

[dgirardi]

• It makes sense for Proposal: pbjs-ortb conversion library #8562 to put adUnit.transactionId into imp[].ext.tid;

• it may make sense for core or enrichmentFpd instead to put adUnit.transactionId into adUnit.ortb2Imp.ext.tid. I don't think we have a precedent for this; it would help adapters that are currently copying adUnit.ortb2Imp verbatim into their request - which should all eventually be using Proposal: pbjs-ortb conversion library #8562 anyway. Other adapters would just see it as redundancy - they can pick it from either bidRequest.transactionId or bidRequest.ortb2Imp.ext.tid

• I don't think it makes sense to set source.tid. Which one of the transactions should we put in it? From the ORTB spec:

  Transaction ID that must be common across all participants in this bid request (e.g., potentially multiple exchanges).

  In general any ortb request generated by pbjs can contain multiple impressions. I don't understand how for example the one currently set by the PBS adapter would work - it must mean that the backend is ignoring it, or that it refers to another type of transaction.

[shahinrahbariasl]

Went through #8562 and I think it makes sense for the "ortb validations and setting defaults" logic to be in one place. In my opinion, If the goal is to move enrichmentFpdModule.js logic to PBJS-core, it makes sense to set non-bidder specific fields such as transactionId and device info there. Would be happy to help with #8562.

Regarding source.tid, I don't think we should copy imp level tid into it since as Demetrio mentioned, each imp can have different tid. source.tid can stay at bidRequest level and only be used as fallback if bidRequest.ortb2Imp.ext.tid is not set. What do you guys think?

Also, I think if we always set bidRequest.ortb2Imp.ext.tid by default, then some of the validation logic for adUnits need to be updated as well since ortb2Imp object would never be null anymore https:/prebid/Prebid.js/blob/master/src/prebid.js#L171

[dgirardi]

What is the meaning of source.tid? the proposal in the OP suggests that it's the default value for imp[].ext.tid, if that's the case, I think it's correct for core to leave it blank. (in cases where we "know" all the imps, like it'd be in #8585, we could do things like extract a single imp[].ext.tid into it, but it does not seem that useful to me).

I agree it makes sense to populate ortb2Imp - since I believe this is the first instance where core manipulates that, I'd keep it simple and do it right where we generate the transactoinId - which is after validation.

[bretg]

@robhazan - why does the proposal not go so far as to recommend different imp.ext.tid values? Isn't that more useful than the buyer receiving the same imp.ext.tid across multiple imps?

Prebid could just use bidrequest.transactionId as separate UUIDs for each imp.

[robhazan]

My thinking was to allow the flexibility for multiple items in the impression array to be related to the same impression opportunity. So for a seller that doesn't support banner.format (for example), they could send an impression array with 2 items, each with different sizes, and the same tid. It's a 2.X community extension, so I didn't want to assume anything around the sophistication of the seller.