LKQD: update adapter to include new parameters

[david-carver]

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

Add accepted parameters c1...c40 and coppa.

• 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 devops@nexstardigital.com
• 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

[robertrmartinez]

Hi @ndxcarver

Prebid has a standard way of passing through the coppa flag.

#3852

You can use the following bit of code to pass it through:

const coppa = config.getConfig('coppa');
if (coppa != null) {
   sspData.coppa = config.getConfig('coppa');
}

many ways to do so,

But if you only want to pass it if it is true, perhaps:

if (config.getConfig('coppa') === true) {
  sspData.coppa = true;
}

[robertrmartinez]

I do not think this is the most efficient way to do this. It does not seem likely that you will have all 40 or even close to that of these in each bidRequest.

I would think simply looping over each param and adding it is the right thing to do.

Object.keys(bidRequest.params).forEach(param => {
   if (/c\d{1,2}/.test(param)){
     sspData[param] = bidRequest.params[param];
   }
});

With the above code, we only loop as many times as needed.

[david-carver]

We do not require c numbered data to be sent in sequential order and is passed along only if it exists. Your code would also iterate over all the parameters passed in and not our selectively targeted version. My for loop only looks for c1...c40 because all other known accepted data has been picked out.

[robertrmartinez]

Right, but it is not common for a bid adapter to take in 40+ bidParams.

Looks like 2 params are required for your adapter.

So in what seems to be the usual case, it seems as though looping over the params which the pub set is more efficient on average.

Unless your bidder is unique and you make publishers set 40+ unique LKQD params each time.

Another option is to filter the params looking for the c params, then add those.

Also, regarding the logic of a bunch of if / else's for each bid param. Looks like each bid param name directly maps 1:1 to the associated SSPData name as well.

So why can we just not loop over bid params and just add them?

[david-carver]

At this time the correction of my predecessor's code regarding the if statements are out of scope and of course needs to be done. For this particular task, I have to minimize changes to the addition of coppa and c1...c40. So this is why I chose the for loop that limits the count to 40 instead of doing the generic loop, that is something that can be adopted in a future revision.

For some context on the c data, it is custom data that we allow publisher partners to put into our system and pass along. For better or worse they can put whatever string they want. Custom Parameters Doc

[robertrmartinez]

Ok sounds good.

Not meaning to be too combative. Just wanted to double check!

[david-carver]

No worries, constructive help is always welcomed and I will try to do my part and explain as best I can. This was my first encounter with this code as a result of client requests, the code base along with its companion test is now on my growing list of things to change/improve. Have a good one!