-
Notifications
You must be signed in to change notification settings - Fork 2.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
updated logic for userSync - new field filterSettings #2499
Conversation
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. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we should have a default for filterType. probably 'include'. Also rather than doing ['*']
we should just do '*'
, I think that's a little less confusing.
I'm guessing more often than not people are just going to be enabling or disabling all pixels for a bidder, so it might be worth adding a 'all'
or(*, but I kind of like 'all' better) option for the filterSettings
keys, along with iframe
and image
@snapwich To clarify on your feedback, the new config could look like the following:
If so - in the case someone sets up a config with the same bidder in both |
I don't like the
Unless we disallow |
@mkendall07 I agree there can be some ambiguous cases. Perhaps they should throw errors? I'm just thinking from the perspective of this being used, It's most likely to just enable/disable pixels for bidders as opposed to types of pixels (although it's nice to have that fine control if needed). If someone wants to enable/disable all pixels for rubicon (I'm guessing will be a common use case), w/o an I don't think it needs to be a blocker for me, but it makes sense I think. It's also something that could be added at a later point. |
@snapwich As you may have seen, I've updated the code in this PR with an overall refactor as well as some of your points (the I've talked further with @mkendall07 on the As I noted earlier, if the logic of the config is invalid - I am planning to throw a warning and revert to the old userSync logic (allow image pixels, block iframe). This is the current behavior if other parts of the |
I have just pushed in some changes to support the In lieu of adding complexity like that, I talked with @jaiminpanchal27 and we thought to implement the Please let me know of any thoughts, comments, feedback on this new addition. Thanks. |
Does this need to be updated as part of this pull-request? Lines 6 to 13 in 24e6a1d
|
@snapwich No - that config will still preserve the native functionality of the userSync feature if you don't declare the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Is this a breaking change? Does it change default behavior for pixels?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great! Nice code.
@jsnellbaker Sorry to reopen this topic but I can't find the answer anywhere. Why is iframe sync disabled by default? It seems that most bidders are encouraging publishers to enable them, so why not enable them by default? Thanks. |
Hi @EskelCz I believe the historical reason is that iframe usersyncs offer a lot more complexity and chance to run more sophisticated code that the publisher may not always be aware of up-front. Publishers should understand what a particular bidder's iframe usersync should be doing (in a high level at least) before giving them permission to run that code; which is why the default for iframe syncs was keep them disabled. Adding @bretg @patmmccann @mkendall07 for any other reasons that may be relevant here. |
Of course bidders encourage publishers to enable -- it's a super-hypercharged open code block on the page. Prebid is doing the right thing by making publishers think about who they trust with this privilege. |
Type of change
Description of change
This set of changes introduces a new field for the userSync API, called
filterSettings
. This field allows the publisher to configure independent filtering rules against a defined list of bidders (or all bidders) with a specified white-list/black-list filter option. These rules are configurable for both iframe and image pixels, so that you can have a white-list for bidders A, B, C for iframe pixels and a black list for bidder A for image pixels.These changes are part of an intermediate step to deprecate several userSync API fields; specifically
iframeEnabled
,pixelEnabled
andenabledBidders
. While these fields are not fully deprecated and can still be used after this PR, the newfilterSettings
field will trump those settings if the new field exists (and is properly configured). As a contrived example, ifpixelEnabled
was set tofalse
, but there was afilterSettings.image
config object - the image pixels would be dropped as per the latter logic.So long as the
filterSettings
iframe
orimage
object config is defined and valid, it effectively the same value aspixelEnabled
oriframeEnabled
set totrue
. If the config options are invalid, then we fallback to the default config logic where all bidders can dropimage
pixels and no bidders can dropiframe
pixels.Below is a copy of the config object with all its possible fields/options:
update usersync documentation with new filterSettings config object prebid.github.io#747
Other information
PR for #2386