30% Revenue Drop when upgrading from .34 to 2.16

[millieone]

Type of issue

Description

We finally decided to upgrade. We were hesitant to upgrade above .34 as we had heard of revenue drops from people upgrading to 1.X. Upgraded from .34.16 to 2.16 yesterday on part of the site. Only one day of data but a 30% drop in revenue. Should this correct itself over time?

Would like tips on what to do to optimize. We are getting bids from all our partners. 8 bidders. Doing some sizemapping but nothing else unusual. No GDPR.

Our new timeout: var PREBID_TIMEOUT = 1000; | var FAILSAFE_TIMEOUT = 3000;

Previous: PREBID_TIMEOUT=900;var MAX_RETRIES=15;

There was a previous post on here where people upgrading to 1.X suggested adding this: pbjs.setConfig({ userSync: { syncsPerBidder: 50 }, maxRequestsPerOrigin: 1, timeoutBuffer: 400 });

Should we do something like that? Do we have too many bidders for 2.X? Not to sound like a jerk, but what's the point of upgrading if revenue doesn't go up?

Here's a test page: https://www.letsrun.com/archive/2019/05/24/?testpb=yes

Test page

Here's link to what we have up: https://www.letsrun.com/archive/2019/05/24/?testpb=yes

Expected results

Actual results

Platform details

Other information

[headerbidding]

My Chrome HeaderbidExpert plugin found 11 bidders on your test page and reports:

Under Monetized Problem: Rubicon, Openx, Pubmatic, Criteo had less time to bid, because they loaded much later than the other bidders. How to fix: Load all bidders together. Problem: AppNexus, Rubicon, Pubmatic, Criteo's bids did not count, because they responded later than the ad server request was sent out. How to fix: Load these bidders earlier, or experiment with extending the timeout without causing impression loss.

[millieone]

Thanks for the info @headerbidding The headerbidding expert tool is picking up partners that are from the waterfall. You said, "Rubicon, Openx, Pubmatic, Criteo" all were late bidding but none of them are in the HB setup.

I may try adjusting some of the setting that some people did when upgrade to 1.X

pbjs.setConfig({ userSync: { syncsPerBidder: 50 }, maxRequestsPerOrigin: 1, timeoutBuffer: 400 });

[headerbidding]

As far as I know, the defaults currently are:
syncsPerBidder: 5, syncDelay: 3000, maxRequestsPerOrigin: 4, enableSendAllBids: true, timeoutBuffer: 400

User syncing default behavior If you don’t tweak any of the settings, the default behavior of Prebid.js is to wait 3 seconds after the auction ends, and then allow every adapter to drop up to 5 image-based user syncs.

(I am not an expert. Let me know if you come across anything. What is your reason for letting each adapter drop up to 50 cookies?)

[millieone]

@headerbidding as for letting them drop 50 cookies, we have not implemented that. But there was this thread: https://github.com/prebid/Prebid.js/issues/2648#issuecomment-401735019 which talked about a revenue drop from going to 0.x to 1.X And that was a suggested solution. Also it is discussed here: https://www.reddit.com/r/adops/comments/9tcgwm/upgrading_to_prebid_1x_leads_to_20_drop_in/

Perhaps this issue got sorted out?

With a week+ of data now I don't think revenue is down 30%, but we're still looking for ways to optimize and we don't see an uplift.

[headerbidding]

Perhaps someone more experienced here can help? By the way, why do you have prebid header bidding AND a waterfall?

[donthexyz]

We had similar issues of loss in revenue when upgrading from Prebid 0.34. The only reason we did upgrade is that Amazon AUM more than made up the loss from Prebid so our overall Revenue even increased slightly.

See here: https://www.reddit.com/r/adops/comments/a42ki1/prebid_1x_upgrade_ab_test_with_aum_amazon_prebid/

We did initially have maxRequestsPerOrigin : 1 but after A/B testing saw no performance difference compared to the default of 4.

[headerbidding]

@donthexyz: Have you done the "AUM Parallel Integration alongside Prebid" per the Amazon suggested script or did you "tweak" it?

[donthexyz]

Amazon actually did it for me and yes it was the parallel integration. I have not tweaked it.

[millieone]

@donthexyz did you do anything with the { syncsPerBidder: 50 }, or timeoutbuffer? or just leave at defaults?

[donthexyz]

we left it at defaults

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bretg]

Re-read last year's impression thread. It boiled down to:

1) everyone's a little different -- folks will need to try various parameter settings, preferably with A/B testing 2) maxRequestsPerOrigin:1 seemed to help some 3) raising the timeoutBuffer helped others. The default in recent versions is 400ms. (This essentially gives bidders more time, so makes sense that bid rates would go up) 4) make sure you're not setting the Prebid Timeout and the Failsafe timeout to the same value. (see http://prebid.org/dev-docs/getting-started.html) 5) geographic location matters

FWIW - I think syncsPerBidder is a red herring.

[bretg]

@millieone - any update on your experience here?

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[bretg]

@millieone - going to let stalebot close this one out if we don't get an update. Or anyone else having issues after upgrade and tuning.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.