VidoomyBidAdapter: refactor cookie sync

[sasanfarokh]

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

Just call cookie sync urls sequentially with a 500ms delay between them.

[lgtm-com]

This pull request introduces 1 alert when merging 5f816fe into a68796a - view on LGTM.com

new alerts:

• 1 for Superfluous trailing arguments

[FilipStamenkovic]

You need to change your cookiesync logic.
Your adapter needs to implement getUserSyncs function (you can take a look how other bid adapters do it). You cannot fire cookiesync in your adapter before auction is held.

[ChrisHuie]

@sasanfarokh this was my bad when reviewing previously. Currently, this adapter is breaking a few guidelines. Can you please make the above changes requested by @FilipStamenkovic 👍

[FilipStamenkovic]

@sasanfarokh The main issue here is not that you are not using triggerPixel from utils.js, it's that you are doing cookie sync in a way that is not allowed.

Take a look at the comment made by @patmmccann: #7601 (comment)

[sasanfarokh]

@sasanfarokh The main issue here is not that you are not using triggerPixel from utils.js, it's that you are doing cookie sync in a way that is not allowed.

Take a look at the comment made by @patmmccann: #7601 (comment)

Yes, I understood that, I was trying to check the getUserSyncs method,
It is a sync method, and as you see, Cookie sync urls are fetched from a json url, could you help me to find how can I do that?

[FilipStamenkovic]

@sasanfarokh I hope this comment will help:

Steps:

• remove cookiesync that is executed before auction is held
• when requesting bids, from your backend in response return pixels you want to sync (the ones you are hosting here)
• then implement getUserSyncs method, second argument is responses
• you could utilize argument responses and retrieve pixels your backend has sent in step 2, something like:

const getUserSyncs = (syncOptions, responses, gdprConsent, uspConsent) => {
  if (syncOptions.iframeEnabled || syncOptions.pixelEnabled) {
    let pixelType = syncOptions.iframeEnabled ? 'iframe' : 'image';
    let pixels = deepAccess(responses, 'pixels') || [];

    let userSyncs = [];
    pixels.forEach(pixel => {
      userSyncs.push({
        type: pixelType,
        url: pixel + gdprConsent + uspConsent // here you need to construct url for each pixel
      });
    })

    return userSyncs;
  }
}

You don't have to do it exactly how I proposed, but something similar. If you are confused how this is working, you can use openx bidder on your local test page to see how they are syncing their cookies (it's similar to what I've proposed).

[FilipStamenkovic]

@sasanfarokh Also, when your bidder returns empty response your adapter will log error message: ERROR: vidoomy: error parsing server response to Prebid format

You should consider doing early exit in interpretResponse function so that you don't log errors when there are no errors (you simply didn't have any bid, that's not an error). Something like:

if (!serverResponse.body) {
  return;
}

[FilipStamenkovic]

You test coverage is bellow 80%. You need more tests.

[FilipStamenkovic]

While testing your bidder I found some small errors. You can see them in separate comments. From Prebid perspective, you don't have to fix those issues. But, I strongly suggest that you fix them anyway, it will make your adapter run a bit faster.

Also, why are you passing ua (userAgent string) in query params, you already have that information in HTTP header?

[sasanfarokh]

While testing your bidder I found some small errors. You can see them in separate comments. From Prebid perspective, you don't have to fix those issues. But, I strongly suggest that you fix them anyway, it will make your adapter run a bit faster.

Also, why are you passing ua (userAgent string) in query params, you already have that information in HTTP header?

Hey, About the user-agent you're right, It's already exists in HTTP headers, but currently our backend apps may read it from querystring, I want to leave it as before.

[FilipStamenkovic]

Your tests are failing, please take a look at CircleCI output.