Open ahmadlob opened 1 year ago
What is an example of the blocked url? Which browser blocked it?
we feel it more in Edge and Firefox
urls for example: https://trc.taboola.com/articlesmansion-hb/log/3/visible?route=AM%3AAM%3AV<i=new-test-inc-vis-2_ctrl
On Wed, Jun 21, 2023 at 2:42 PM Patrick McCann @.***> wrote:
What is an example of the blocked url? Which browser blocked it?
— Reply to this email directly, view it on GitHub https://github.com/prebid/Prebid.js/issues/10126#issuecomment-1600683301, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2BIRRBTILQYWBW6GGVMYNTXMLM3RANCNFSM6AAAAAAZOOXA2I . You are receiving this because you authored the thread.Message ID: @.***>
Is there any update or figures regarding this issue? @patmmccann
No one else has reproduced or reports this issue so far. It seems unique to Taboola.
@patmmccann I see, actually strict mode browsers distribution isn't that high. Currently we are checking if it is due to ad blockers maybe. We noticed some block prebid and some though prebid rendering iframe blocked still sent a request to our bidder service. If you have more information regarding this or any tips, will appreciate that
@ahmadlob I am not sure how to proceed on this - could you provide steps to reproduce? (for example, which browser should I use, how should I set it up, and what is the behavior I should see on the pages you gave?)
To enable Strict Mode in Firefox for desktop, you can: Mozilla Support, MakeUseOf, +1 more Click the shield icon to the left of the address bar Mozilla Support, MakeUseOf, +1 more Click "Protection Settings" Mozilla Support, MakeUseOf Under "Enhanced Tracking Protection", select "Strict"
@ahmadlob are you able to detect this mode on your requests somehow? How were you able to identify this gap?
One idea is if we can somehow detect it, we could put it in the request object or cancel all auctions as prebid ssps will not be able to pay.
@patmmccann to find a contact at mozilla
@patmmccann we noticed the gap as discrepancy between our "nurl" win count vs publishers ad server impressions. Lets distinguish between the two issues:
If you could detect it will be great
@ahmadlob to be clear, you want to detect an ad blocker, not strict mode, and append the flag to the request object?
@patmmccann exactly 100%
committee wants to allow for an api for an adblocker extension to notify prebid ads will be blocked; also to add indications of tracking pixels being unlikely to have query string parameters with bid request ids or something of that nature
Broadening the scope a little bit, I think it would be helpful for publishers and ad-tech partners to have signals that describe the ability to serve ads to the current environment. Prebid feels like the right entity to help fill this gap. A potential solution could have at three parts:
1) Detection of ad blocking at the browser level (FF strict mode, Safari strict thingy) 2) Detection of ad blocking by a browser extension or other third party (traditional ad blockers) 3) An API that allows anyone (browsers, extensions, etc) to register that ads are blocked with any metadata describing why or to what extent.
Items 1 and 2 above would be in prebid core code, would need to be updated on some cadence as browsers evolve, and would be immediately useful.
Item 3 is an API exposed by Prebid.js core and is more future looking and aimed at facilitating orderly communication between users (or the software operating on their behalf) and publishers, with the assumption that transparent communication will be more helpful than attempts at detection.
[update] Logically, I think it makes sense for the detection code implemented in Items 1 and 2 to utilize the API provided by 3. This ensures consistency.
[update] Typescript API suggestion:
// An object that describes the current ad restrictions and who is enforcing them.
// It's possible that multiple restrictions could be in place. In the case of a "partial"
// restriction, the blocked and/or allowed lists would denote which entities can/cannot
// show ads.
interface AdRestrictions {
type: "device" | "browser" | "extension" | "other",
scope: "full" | "partial",
blocked: [string],
allowed: [string],
};
function registerAdRestrictions(restrictions: AdRestrictions) {
// ...
};
Maybe @mkendall07 has some deeper insights on this?
I like the idea proposed by @JoelPM, however expecting blockers to register themselves might be a expecting too much - in my experience that's not been possible as there is no desire to register this type of behavior (for numerous reasons but mostly because of the desired not to be circumvented).
Detection could be possible way to go to basically short circuit stop the auction in those "half conditions" where the PBJS library/bidding request is not blocked but the render is. So if that condition can be detected you can simply stop before sending the HB requests.
We discussed this at the Prebid.js PMC on Nov 20. The core issue from our perspective is discrepancy between publishers and buyers when an ad blocker allows Prebid to retrieve ads, but prevents rendering. This has been a problem in the past, but not one we're seeing now. As @mkendall07 says, trying to get ad blockers to work with us is unlikely. It's our recommendation that Prebid should not work on this feature request.
Type of issue
We are suffering from significant discrepancies with different publishers, conducted analysis and noticed it looks to be a result of a certain browsers tracking prevention/protection. When browser is in strict mode, taboola tracker is blocked.
This results in discrepancy between the publisher numbers ( counting ad server impressions where taboola win ) and our impressions and visible numbers (not rendered or fired so on our side not counted)
Are you familiar with this issue? (it should affect many bidders and not just taboola) Suggested solutions are appreciable