Questions on updating from legacy native fields to ortb native fields

[jsnellbaker]

Type of issue

Question

Description

I'm working on updating the appnexus adapter to no longer rely on the convertOrtbRequestToProprietaryNative() by reading the ortb native information from the bidRequest.nativeOrtbRequest.

But while going through the changes and comparing the fields, I noticed some gaps from the legacy native setup to the ortb native setup.

I was hoping for some feedback about how to address these gaps, in the case that someone might have been using them with their legacy native adUnits and I don't break part of their setup. See below:

• the privacyLink, privacyIcon, and clickUrl fields that were present in the legacy native setup don't have a home in the ortb native spec and are simply not included in the converted nativeOrtbRequest object.
• in the legacy, the sizes and aspect_ratio fields for images and icons could support an array of sizes or aspect_ratio objects; however in the nativeOrtbRequest only the first value from the sizes or aspect_ratios array is carried forward and the rest of the values are simply dropped. The native ortb spec implies it should be one set of values for each image asset (from what I understand), so I think this is why it's currently happening.

[dgirardi]

the privacyLink, privacyIcon, and clickUrl fields that were present in the legacy native setup don't have a home in the ortb native spec and are simply not included in the converted nativeOrtbRequest object.

those are response (not request) fields, right? I'm not sure what they'd mean in a request. privacyLink and clickUrl do have a place in ortb responses; privacyIcon doesn't afaik.
(edit: I think I understand - in legacy they were treated as an asset, so you could choose to request them or not; in ortb, they have their own "top level" spot in the response, it should be safe to always set them, the template can decide whether to render them).

Prebid.js/src/native.js

Lines 762 to 763 in a318783

	legacyResponse.clickUrl = ortbResponse.link.url;
	legacyResponse.privacyLink = ortbResponse.privacy;

The native ortb spec implies it should be one set of values for each image asset (from what I understand), so I think this is why it's currently happening.

Correct. Looking at what we do now however, it doesn't quite match your description IMO:

• we pick the first aspect_ratio to fill out hmin/wmin, but also try to condense all other aspect ratio into something like ['3:2', '16:9'] and shove it in ext (this was plucked from what was initially implemented for Prebid Server)
• we fail if there's more than one size.

It may make sense to accept any number of sizes, pick the first and put the rest under ext as well - not sure.

[jsnellbaker]

For 1, I meant for the request. For example, if I had a setup like:

mediaTypes: {
       native: {
              title: {
                required: true,
                len: 50
              },
              body: {
                required: true,
              },
              image: {
                required: true,
              },
              sponsoredBy: {
                required: true
              },
              privacyLink: {
                required: true
              },
              icon: {
                required: true,
                aspect_ratios: [{min_width: 1, min_height: 1, ratio_width: 1, ratio_height: 1 }, {min_width: 20, min_height: 20}],
              }
      }
}

Prebid makes a nativeOrtbRequest like:

{
    "ver": "1.2",
    "assets": [
        {
            "id": 0,
            "required": 1,
            "title": {
                "len": 50
            }
        },
        {
            "id": 1,
            "required": 1,
            "data": {
                "type": 2
            }
        },
        {
            "id": 2,
            "required": 1,
            "img": {
                "type": 3
            }
        },
        {
            "id": 3,
            "required": 1,
            "data": {
                "type": 1
            }
        },
        {
            "id": 4,
            "required": 1,
            "img": {
                "type": 1,
                "wmin": 1,
                "hmin": 1,
                "ext": {
                    "aspectratios": [
                        "1:1"
                    ]
                }
            }
        }
    ]
}

In this case, the privacyLink field isn't listed so I don't know it's a required field to pass along for the outgoing adserver request.

[dgirardi]

It looks like privacyLink does have a spot in the request that the conversion logic could fill:

for clickUrl, the ORTB spec requires it in responses, so I think it makes sense for adapters to always consider it required.

privacyIcon is tricker - maybe we should generate an icon asset with something under ext to signal that it's about privacy?

[musikele]

After reading Demetrio's analysis, probably we may want to:

• set this privacy integer to 1 if privacyLink is present
• create an image icon for privacyIcon with some ext value (which one?)

We all agree that requesting clickUrl doesn't bring anything to the table so nothing to be done for this one. If clickUrl is not present the response is discarded...

Regarding aspect_ratios, yes, the spec says that it must be just one value, so prebid was actually allowing more of what the spec allows.

[jsnellbaker]

As a slight related tangent, while I was looking a bit further at the bid response conversion logic that would be needed in the appnexus adapter, I noticed that there was a reference for a native.video field in the created appnexus bid response. This field doesn't seem to have a corresponding entry to the list of supported native fields documented for the adunit. That said, I noticed in the native ortb spec there is support for video fields in the request and the response parts.

While I'm not sure if someone could be using this native video field from our existing code, would it be possible for us to add support for the video part of the native ortb spec to the project just in case?

It seems like it's not there currently, from what I saw in the native.js conversion code (unless I missed something?).

[musikele]

@jsnellbaker , previous version of native didn't have video support (you can find previous docs here), so when this rewrite was planned, we decided to cover only the already implemented requirements. Video is definitely a TODO item. But I would create a separate issue to track that.

[dgirardi]

@jsnellbaker - is #10271 (and #10275) enough to close this? Or should we try to deal with privacyIcon as well?

[jsnellbaker]

@dgirardi I think we should either make a change to handle the privacyIcon field properly in the ortb conversion functions, or consider this other PR (#10259) as a temporary measure to properly suppress it.

Atm if you include that asset in the adunit, the conversion functions make a 'blank' asset field in the nativeOrtbRequest object, which could skew what adapters do if they're not expecting that.

Additionally, I think we need to come to a resolution about the multiple aspect_ratios behavior that Prebid allows but isn't properly handled for the native ortb spec. Should we pass along the other ratios to the ext field or just ignore them? I think those we the mentioned options.

I think between all these changes, we could then close this issue.

[patmmccann]

Options include: ask iab to mainline privacyLink in the response provisionally; or deprecate support.

[patmmccann]

It seems I wrote the wrong thing in the last note? Reading the thread in more detail it seems only privacyIcon is an open question?

[patmmccann]

@jsnellbaker We're hoping to just eventually delete support for privacyIcon in the request? If this field disappeared from the request, would it present any problems for your exchange? If so, can Microsoft propose a home for it in the ortb2 request object?

[jsnellbaker]

TMK we don't actively use the field as of today nor have we in the past. What I reported with respect to the privacyIcon was meant to be a general issue for prebid as a whole. I'm sorry if the wires were crossed somewhere or if I gave indication that we (appnexus) needed the field to make our transitions. We don't and the PR I created does not intend to include the privacyIcon field.

If removing the field overall is the best course of action that the community decides to better align with the ORTB native spec (or for any other valid reasons), I'm not opposed so long as the proper deprecation warning for other bidders is given for them to potentially react.

[patmmccann]

@jsnellbaker apologies for the confusion, just attempting to do my part to drive this to resolution. Is there remaining work to do other than find a home for privacyLink in the request object?

it seems Criteo uses this field in their responses https://publisherdocs.criteotilt.com/openrtb/#native-ads-using-lazy-native-mechanism- Tagging @FlorentDancy who might be able to speak to the need in requests.

[jsnellbaker]

I understand @patmmccann

I think there's still an open question about prebid's ability to support multiple sizes/aspect_ratios (min height/width) in the legacy native setup, whereas in the native ortb spec it is expected to pass one set of sizes (either normal sizes or min sizes). I'm not sure if there's a plan to pass additional sizes to native ortb ext or possibly ignore them/drop the extra sizes to force just one set to be used.