Feature request: restore skip enrichment flag

[patmmccann]

A publisher reports https://github.com/prebid/Prebid.js/blob/2b3a62b084b3077fde798946ada5824b14b8bb6d/src/fpd/enrichment.js#L149 is causing them a performance issue. Can we wrap this one line in additional config so they can disable it without disabling all enrichment?

[dgirardi]

We can, but it'd be better to try to address the issue, if we can get some more info on it. If by performance we mean cpu time, that line should not be particularly expensive and I'd be interested to see in what situation it is a problem - it's likely fixable.

[lilahunt]

There's a couple issues here. 1) The permission to disable the first party data code doesn't seem to work as far as we tested it. 2) Prebid isn't a bid enrichment solution. The publisher manages the relationship, contracts and DPAs with vendors who share prebid as a communication tool. The publisher should always retain control over first party data transference. 3) I prefer data transference doesn't overlap with inherent website structures like meta tags and instead a variable is assigned for the specific purpose of communicating to SSPs in the context of our agreements with them. Prebid may actually be forcing me to violate my contracts by scraping a tag that contains a data point that I'm not supposed to send because it's restricted or sensitive. My meta data use isn't designed around monetization or programmatic or data protection or pricing.

[patmmccann]

@lilahunt so you can just turn off enrichment like this

pbjs.setConfig({ firstPartyData: { skipEnrichments: true // defaults to false } });

does that work for you?

https://docs.prebid.org/dev-docs/modules/enrichmentFpdModule.html

[patmmccann]

actually nevermind, that doesnt do anything right now, retitling to restore it

[dgirardi]

All that sounds reasonable @lilahunt; it also sounds like the problem is control and not performance - unless the OP refers to something else.

As an immediate workaround, you should be able to control what gets sent in site.keywords by explicitly configuring it, e.g. setConfig({ortb2: {site: {keywords: '...'}}}) - the same applies to all other enrichments, they do not (or should not) override what's provided directly by the publisher.

We may still want to provide an option to disable enrichment more generally, but we'd need to define its scope. Enrichment used to be a separate and relatively limited module that could be disabled, but by now it includes things that most publishers would probably not want to disable, like the page URL or regulatory metadata (GDPR & co).

[patmmccann]

I am not sure who OP is, I think we can assume @lilahunt 's concerns are the only known concerns

[patmmccann]

@dgirardi how about we just make the flag do what it did in 7.28?

[dgirardi]

The issue is that since 7.28 we've encouraged or forced adapters to use FPD instead of other means. In 7.28, skipEnrichments: true would turn off:

• site.page, domain and referrer, as well as keywords (but adapters were not using ortb2 to get page & co, unlike now)
• device.sua, w and h;
• regs.ext.gpc.

Since then we've added other pieces that a publisher may or may not want to disable, like device.language or device.ua.

[lilahunt]

I am technically OP and can explain the performance piece in more detail. It supports the concerns I listed. It was unintuitive for me why data enrichment would lead to bid loss. I believe the keywords are being sent to DSPs by the SSPs and the DSPs are using them to block rather than compete for high value contextual signals. Right now, I think it's reasonable to assume buyers are more likely to indiscriminately block than target this kind of data on the open market. Their keyword block lists can be completely unreasonable, i.e. I've heard of the word "bird" being on a blocklist. If I'm correct, I suspect the keyword transference disproportionately biases news and reference publishers who are notoriously penalized by keyword blocking.

There are a couple things publisher's should do to manage transferring this data that is inline with similar industry programs via the big tech providers. We probably want to generalize the keywords to a less descriptive taxonomy so as not to leak high value first party contextual packages reserved for sales. We probably want to set floors against certain topics and can do that via Unified Floors in GAM but only if prebid is sending the same keyword data I am sending to my ad server. I don't think most publishers use keyword meta tags for monetization.

I might not want to send other enrichments. I don't know how they are being used or what the performance implications could be. It is difficult to anticipate how a seemingly innocuous signal could limit demand. For example I could see DSPs looking for utm params on page urls to try and block MFA when in reality UTM params make it very easy to digest specific articles and traffic sources in GA and lots of organic traffic uses UTMs.

Signal enrichment feels to me right now more like signal leakage. Signal management is part of the publisher data strategy and should be configurable.

[jvdcrabben]

I personally think that it makes sense for this feature to be enabled by default. However, it should only be enabled if the publisher has included the First Party Data Enrichment Module in their Prebid. It should also be easy to disable it via config. Ideally, the FPD Enrichment Module offered a config that would allow publishers to choose what exactly the module is doing.

[dgirardi]

However, it should only be enabled if the publisher has included the First Party Data Enrichment Module in their Prebid

Part of the reason it's now done by core prebid is that bid adapters, not being able to rely on the enrichment module being available, would often duplicate its logic (including sniffing for meta tags). Many of the enrichments added since are a consolidation of common patterns across bidders.

[jvdcrabben]

That makes a lot of sense. Anyone who bids would have access to that information anyway, if they choose to look for it.