FTRACK USER ID MODULE: tweaking the createEidsArray() method to accept two schema patterns

[ftxmoJason]

Type of change

• Bugfix
• Refactoring (no functional changes, no api changes)

Description of change

A partner was attempting to use the FTRACK User ID module and they were getting errors in the createEidsArray method. The issue was the JSON schema being passed into the method did not match the schema we wrote the code for. The change this PR addresses is the JSON parsing logic was tweaked to accept both schema patterns while also checking value type (string|array) before pushing to the eids array that is returned

[ftxmoJason]

To whom it may review.

1. The original logic expected bidRequestUserId.ftrackId to be the following schema.

ftrackId: {
  HHID: ['household_test_id'],
  DeviceID: ['device_test_id'],
  SingleDeviceID: ['single_device_test_id']
}

2. But during testing, we actually were seeing:

ftrackId: {
  uid: 'device_test_id',
  ext: {
    HHID: 'household_test_id',
    DeviceID: 'device_test_id',
    SingleDeviceID: 'single_device_test_id'
  }
}

This code change allows both JSON schema's to work correctly, but its not clear to me if both are needed. Do we know why the schema's are different and/or if one is incorrect?

Thanks!

[dgirardi]

The ftrack ID module is what wraps the result in ext:

Prebid.js/modules/ftrackIdSystem.js

Lines 59 to 64 in d8f25b9

	return {
	ftrackId: {
	uid: value.DeviceID && value.DeviceID[0],
	ext
	}
	}

#8678

To me that looks odd, maybe unintentional - it'd make more sense to return {ftrackId: {hhid, deviceId, singleDeviceId}}; but in the end what matters is that the callers (including the eid conversion logic) know what to expect.

[ftxmoJason]

Thanks, that is intentional. Thanks for connecting those dots for me.

[dgirardi]

then I think you can simplify this to E_ID.ext = bidRequestUserId.ftrackId.ext; I don't see a need to handle other cases.

[ftxmoJason]

Thanks @dgirardi , I concur. Our decode method is already doing that work so its def redundant at this step. I'll make those changes and ping when they are up. Thanks

[ftxmoJason]

@dgirardi @mmoschovas This PR has been updated. Thanks

[dgirardi]

I think it's better to keep the short circuit (if (!value) return). From what I understand value should always be present here, but if it isn't, it's not correct to default to {}: it will cause this logic to return an incomplete object, which would then be translated to essentially gibberish in eids.

If this returns undefined, the caller will filter it out from the userID map.

[ftxmoJason]

Thanks @dgirardi reverted this code

[ftxmoJason]

@patmmccann @mmoschovas @dgirardi I forget, do I need to do something now or is the next step on your side? Thanks

[ftxmoJason]

Thanks @patmmccann @mmoschovas @dgirardi