[ACT-97] Support IAD SDA test in Permutive module

[desbo]

Updates the Permutive RTD module to support a test for segmentation with
the new IAB standard data taxonomy.

Initially we are mapping a small selection of Permutive to IAB cohort
IDs and including these in the ORTB2 object. We also set the segtax
value appropriately for the Index exchange, which we're using for this
test.

Type of change

• Bugfix
• Feature
• New bidder adapter
• Code style update (formatting, local variables)
• Refactoring (no functional changes, no api changes)
• Build related changes
• CI related changes
• Does this change affect user-facing APIs or examples documented on http://prebid.org?
• Other

Description of change

• test parameters for validating bids

{
  bidder: '<bidder name>',
  params: {
    // ...
  }
}

Be sure to test the integration with your adserver using the Hello World sample page.

• contact email of the adapter’s maintainer
• official adapter submission

For any changes that affect user-facing APIs or example code documented on http://prebid.org, please provide:

• A link to a PR on the docs repo at https://github.com/prebid/prebid.github.io/

Other information

[desbo]

Currently this only includes standard cohorts (to be transformed to IAB IDs later) but I don't know if this is right. Maybe it should also include the cohorts from _ppam and _pcrprs (the same as ac)?

[Mullefa]

Some initial 'feedback' (mainly questions). I'm hoping I will be able to give a more insightful review in a second round one my understanding improves. But everything looks good so far!

[Mullefa]

(not introduced in this PR) @dreischer why did we called these segments legacySegs? Would standardCohorts not be a more indicative name?

[desbo]

@Mullefa thanks for the review so far, I've just found quite a major bug in that the transformations aren't being applied for index because I missed the fact that the getSegments call always loads the ac segments so isn't applying the transformations for ix.

I'm looking at this now but it makes me think that I haven't quite modelled it right and instead of thinking in terms of per bidder we should be thinking about different taxonomies that we want to support and how to build segment IDs appropriately for each one.
There will definitely be some more changes resulting from this so it might be worth pausing on any other reviewing until I push these up.

[desbo]

@Mullefa have applied the changes we discussed, think it's a real improvement 👍
David and Franz were on board with this idea, Franz is now checking with Steve on the topic of getting Hearst to make the config change.

[Mullefa]

Are the transformations intended to map standard cohorts to different IAB taxonomies, or something more generic?

[desbo]

For the parameter I've modelled it very generally, as any transformation on the user.data object without saying anything specific about what the transformation would do. WDYT?

[Mullefa]

I think it's essential to document the different transformations available, so that people can effectively use the module.

My preference would be to have something less general:

{
  "iabTaxonomies": {
    "<taxonomyId>": {
      "<standardCohort>": "<iabCohort>"
    }
  }
}

I think this would simplify the implementation, and support other IAB taxonomies out-of-the-box. It would also be easier to write documentation for.

That being said, main emphasis of this comment is +1 for documenting each transformation, rather than the configuration specifics (which is more just another approach for you to weigh up).

[desbo]

I was thinking about it differently: I don't think it's guaranteed we're going to stick with this approach beyond the Hearst test (e.g. if we want to run this properly for all standard cohorts, I doubt we'll ask publishers to include the full list of cohorts in their config) and I'm expecting us to provide some specific documentation to Hearst (separately to this readme) that includes the config code they need to include as well as mentioning that this will apply to all bidders.

I totally agree that we should document the transformations we support but wonder if it's appropriate to add something that might only be accurate for the short duration of the Hearst test?

[Mullefa]

Ok, but I'm not sure Prebid will see it this way. My guess is that they will want functionality merged into the SDK to be general and not tied to a specific use case. But happy to raise as is and not speculate.

That being said, if we don't want to document the IAB taxonomy transformation, what is the point of documenting transformations?

If we did want to the document the IAB taxonomy transformation, we could mark it as alpha in the docs and subject to change.

[desbo]

I agree it's not that useful to have an entry on transformations when we don't say much about how to use it. But let's see what Prebid say.

[Mullefa]

I don't think this is precise enough; there are multiple IAB taxonomies

[desbo]

only 1 Audience taxonomy I think?
https://iabtechlab.com/standards/

[Mullefa]

Sorry for not being clear -- I was thinking perhaps a user of the module should be able to configure the version used?

[desbo]

Yep, fair enough

[Mullefa]

I think it's essential to document the different transformations available, so that people can effectively use the module.

My preference would be to have something less general:

{
  "iabTaxonomies": {
    "<taxonomyId>": {
      "<standardCohort>": "<iabCohort>"
    }
  }
}

I think this would simplify the implementation, and support other IAB taxonomies out-of-the-box. It would also be easier to write documentation for.

That being said, main emphasis of this comment is +1 for documenting each transformation, rather than the configuration specifics (which is more just another approach for you to weigh up).

[Mullefa]

Let's see what people far more qualified than me say 😅