Appnexus bid adapter add ortb2 device

[jwrosewell]

Type of change

• Feature
• Updated bidder adapter

Description of change

This PR enhances the AppNexus bidder request by incorporating device data from the global ORTB2 object. Existing values in the AppNexus device object will be overridden if they are also present in the global ORTB2 object. However, values unique to AppNexus or not found in the global ORTB2 object will remain unchanged.

Motivation

The device object has previously been populated by simplistic parsers, if at all, and was inaccurate as a result. Prebid now benefits from RTD modules such as 51Degrees that enrich all the device object fields including Apple iPhone model category and device ID. The PR enables AppNexus’ users to benefit from device object improvements.

Other information

cc: @jsnellbaker @jaiminpanchal27

[jsnellbaker]

Hi @jwrosewell

Unfortunately, these changes will not work as is. Our endpoint does not follow the ORTB2 schema and data fields like in the ORTB device object need to be properly mapped with the device fields our endpoint currently supports.

I can submit an internal ticket for us to look at this at a later time and properly implement the changes. But as is, most of the device data here would just be ignored by our endpoint despite trying to set it in the request payload.

Please let me know if you'd like close this request and we'll revisit this when there's time, or if you have another thought in mind. Thanks.

[justadreamer]

Hi @jsnellbaker! Thanks for taking a look at this PR. We'd be happy to actually map these fields for you if you provide the details / docs on the data format and field names your server endpoint expects to see. We can arrange a quick call to discuss. Let us know what would work for you.

[jsnellbaker]

@justadreamer

Below is a markup of the device field for our endpoint. All of these fields are optional, so if there's no matching field from the ortb object, then they can be safely left out.

device: {
	useragent: string,
	geo: {
		lat: double,
		lng: double,
		loc_age: int,
		loc_precision: int,
		country: string, // two digit code
		region: string,
		city: string,
		zip: string
	},
	ip: string,
	devicetype: string,
	make: string,
	model: string,
	os: string,
	os_version: string,
	carrier: string,
	connectiontype: int,
	mcc: string,
	mnc: string,
	limit_ad_tracking: bool,
	device_id: {
		idfa: string,
		aaid: string,
		md5udid: string,
		sha1udid: string,
		windowsadid: string,
		rida: string,
		ifa: string,
		ifa_type: string
	},
	w: int, // physical width of the screen in pixels
	h: int, // physical height of the screen in pixels
	ppi: int, // screen size as pixels per linear inch
	pxratio: double, // the ratio of physical pixels to device independent pixels
}

[justadreamer]

Hi @jsnellbaker

This is great, thank you. Just a few clarifications needed before we can apply this schema:

1. We noticed you have devicetype: string, while oRTB follows devicetype: int defined by AdCom spec here:

Value	Definition
1	Mobile/Tablet - General
2	Personal Computer
3	Connected TV
4	Phone
5	Tablet
6	Connected Device
7	Set Top Box
8	OOH Device

What values does your server expect to see as devicetype? Do you have a list of possible values that we should pass that we could map to the oRTB's device types?

2. What will happen if device object contains any extra fields that are not present in this schema, f.e. if we copy the oRTB and replace osv with os_version and map devicetype to correct values, then oRTB device object will still contain f.e. sua and potentially ext and some other fields - will server simply ignore those and work with the ones it recognizes as per schema, or will it discard everything / fail to process the entire device object? If the latter - then no problem we can sanitize the whole object and make it strictly correspond to the schema.

3. Question related to the above: 51Degrees provides device.ext.fiftyonedegrees_deviceId field which is not an individual device identifier, but an identifier of a device profile that takes into account 4 components (hardware, software, browser, is crawler/bot) - that would identify a device profile in 51Degrees DB and can later be used on the backend to do the lookups of over 250 properties (f.e. price range, device launch year and many more etc.). We could include that field as a device_id.fiftyonedegrees field in the request to your server, unless it would break things - then we better not add this extra field.

Thanks.

[jsnellbaker]

Hi @justadreamer

1. the string values from that chart would go into the devicetype field.
2. it should just ignore the extra fields/values it doesn't recognize tmk
3. as above, I believe attempting to add a new value there would just be ignored. If you want have that custom data read by the endpoint, you should reach out to your Xandr business contact to start a discussion around that topic so they can include the appropriate people.

[justadreamer]

Hi @jsnellbaker

One last clarification to make sure we send the correct values for devicetype:

Value	Definition
1	Mobile/Tablet - General
2	Personal Computer
3	Connected TV
4	Phone
5	Tablet
6	Connected Device
7	Set Top Box
8	OOH Device

Please confirm that f.e. for 3 Connected TV - you would like to receive the value:

"devicetype": "Connected TV"

not

"devicetype": "3"

correct?

Also does capitalization matter - should we preserve the same capitalization as in "Definitions" column in the table above?

Thanks

[justadreamer]

Hi @jsnellbaker we've updated the implementation in the latest commit. Please review.

[jsnellbaker]

@justadreamer Sorry I was ooo last week and have been catching up on some things.

For your question about the device type - the Definition value string would be the value to use. Capitalization does not matter, they should be fine as written there.

[justadreamer]

Hi @jsnellbaker thanks for getting back to us. Sounds good: re device type - this is how we have implemented it in the latest commit - ready for review. Thanks.

[jsnellbaker]

Thank you for putting these updates together. LGTM