No user.buyeruid in request

[jdalia001]

Hello,

I have a problem with user.buyeruid in request sent to bidders. The buyeruid parameter is never added to the bidders requests, i don't know why, i try with different CMP, check the consent who is correct ... The user_sync and setuid are called correctly.

I see that prebid.js call cookie_sync after the auction, so how the prebid server can got the cookie data ?

I don't really understand what's happened, someone already got this problem ?

Thanks in advance for your help.

[spormeon]

i think this is also related to my same/ similar problem, that is on https://github.com/prebid/Prebid.js/issues/6684 the bidder in question on mine is also on s2s and telling me they are hardly ever getting an buyeruid ( they do get a few), which they say is the most important thing to them. They bid at present but its basically never above 0.01

i only have the gdpr consent module and tried adding the enforce module as well, incase that had anything to do with it but it still seems the same on a test page

@mouchii did you find a fix being as your closed it?

[patmmccann]

@mouchii did you close because you solved? Is there a place we can make doc more clear?

If not, this likely requires a test page

[spormeon]

here is a test page: https://cheftalk.com/ads/final/ this one has the GDPR enforcement module added, the main domain has the live scripts without the GDPR enforcement module included, as I'm down the road of seeing if its this module that changes anything

[bretg]

Is this site AMP? I see 'AMPvideo', but the page itself doesn't look very AMP-y. So I'll assume not, but if so, the problem is lack of load-cookie.html.

Here's how usersync/cookiesync works in Prebid Server -- https://docs.prebid.org/prebid-server/developers/pbs-cookie-sync.html. Once the bidder's ID is in the uids cookie, PBS adds it to user.buyeruid and sends it to the

Unfortunately the debug output for the /video endpoint isn't as comprehensive as the /auction endpoint, so we can't see what's actually being sent to the bidder. @SyntaxNode - perhaps that would be a worthwhile improvement?

Which bidder is having trouble? I've found that bidders sometimes misunderstand what sync endpoints are supposed to do and implement it incorrectly. However, on this test page, the 9 bidder syncs happening do seem to complete. I do notice that 4 bidders are consistently in the second batch of syncs though: emx_digital, 33across, ix, and smartadserver. If that's true in the wild, then those bidders wont have buyeruids until the user's 3rd page turn.

[spormeon]

its not AMP, The bidder telling me they have a problem is improvedigital

So in effect this doesn't happen on the first page load? So in effect we are "msising out" on "up to 10 slots" X amount of users X amount of first page loads?

[bretg]

So in effect this doesn't happen on the first page load?

Of course not. The nature of header bidding is that we have about 1 second to respond with bids before the ad server is called. There's no way we can do both a cookie-sync AND an auction in 1 second. PBJS initiates the /cookie_call right after parsing the s2sConfig entry, but then there's a long process of calling PBS, getting URLs back, dropping the pixel/iframe into the page, the browser initiating those requests, hitting the bidder endpoints, which redirect to PBS server. By that time, the page will have most likely initiated the auction.

Did you change the test page? It's using the /openrtb2/auction endpoint, but thought it was the video endpoint? Anyhow, at this point I see that improvedigital is getting the buyeruid on the 3rd page load.

                "improvedigital": [
                    {
                        "uri": "http://ad.360yield.com/pbs",
                        ... "user\":{\"buyeruid\":\"a416b7c5-097c-4c35-8776-b07539fb91d1\",\"ext\":{\"eids\ ...

I also see that their bidder is by far the slowest on multiple page loads. Thats not helping their bid rate.

        "responsetimemillis": {
        "responsetimemillis": {
            "33across": 358,
            "appnexus": 182,
            "districtm": 96,
            "emx_digital": 208,
            "gumgum": 173,
            "improvedigital": 1086,
            "ix": 64,
            "openx": 33,
            "rhythmone": 394,
            "smaato": 70,
            "smartadserver": 214
        },

[spormeon]

nope, not changed anything, its the same as it was before. So how do we get them on at least the 2nd page load? The slowness is their problem, nothing I can do about that, other than moan at them for/ about it?

This is my setup, unless changing some of these is gonna help?

[bretg]

Actually I see their sync going out first, and is reliably having an ID on the 2nd page load. The 4 bidders that often seem to miss the first page are emx, ix, 33across, and smart.

[bretg]

@spormeon - any update here? I'm not seeing a problem that can be solved here.

[spormeon]

I gave up on it to be honest, if they "can't" fire on the first page load then improve aren't gonna be a "big" bidder for me in effect, I've just left them running "as is", if they "re-work" their stuff to be able to compete at a similar level to others, up to them

[bretg]

Understood.