ImproveDigital Bid-Adapter Bad-Input Error

[rmattis]

We were seeing increasing error-counter's for improvedigital for all of our prebid-server accounts that used ConsentManager as a CMP.

When sending a debug request to our prebid-server, the following error occured in the bid response:

{
  "code": 2,
  "message": "Cannot deserialize value of type `java.lang.Integer` from String \"3033~dv\": not a valid `java.lang.Integer` value\n at [Source: UNKNOWN; byte offset: #UNKNOWN] (through reference chain: java.lang.Object[][32])"
}

After some debugging, I could find a part of the string "3033~dv" in the consent.ConsentedProvidersSettings.consented_providers. For instance, we could reproduce the bug with 2~3218.1375.70.7.1317.3186.3126.1703.1669.1097.2320.1329.2016.229.229.2213.1674.1799.2745.313.326.1344.1025.1902.1127.449.2567.469.1047.494.510.2776.3033~dv. as value.

According to Google, there seems to be a new standard: Additional Consent v2 which isn't respected by the ImproveDigital Adapter so far.

At this code-point the adapter only assumes one seperator symbol "~".

prebid-server-java/src/main/java/org/prebid/server/bidder/improvedigital/ImprovedigitalBidder.java

Line 101 in f0489f6

final String consentedProvidersPart = StringUtils.substringAfter(consentedProviders, "~");

Fix

The fix on our self-hosted prebid-server, so far, was to add support also when the string contains more than one separator symbol:

final String consentedProvidersPart;
if (StringUtils.countMatches(consentedProviders, "~") > 1) {
    consentedProvidersPart = StringUtils.split(consentedProviders, "~")[1];
} else {
     consentedProvidersPart = StringUtils.substringAfter(consentedProviders, "~");
}

I can also submit the fix as merge-request myself, but I think someone from ImproveDigital should have an eye on that issue before.
IMHO it's not the best practice anyway to parse this string as part of the prebid-server adapter as it gets sent in the bidRequest anyway. This implementation would probably be better suited on the SSP's server.

[bretg]

Adding @improve-prebid-dev - we ported your adapter from PBS-Go to PBS-Java, but seems likely that the same issue will exist in Go as well.

[jbartek25]

Hi @rmattis.

IMHO it's not the best practice anyway to parse this string as part of the prebid-server adapter

You are indeed correct. The current logic comes from a legacy implementation in the SSP and the SSP devs are working on a fix. We will submit an interim fix.

[ishihanvcs]

@bretg I've already created PR #2954 with the fix for this issue. Please assign some to review & merge accordingly.

[SerhiiNahornyi]

Closed, dut to merged #2954