Open bretg opened 1 year ago
This appears to be rather alarming at first. If a publisher sends any GPP string, PBS monetization would likely crash 70% overnight. Publishers may quickly be alienated from host companies adopting this configuration.
Discussed in the Prebid Server Committee. This configuration can apply at the host and account level. The comment above from @patmmccann provides insight into the risk of a host level config, so hosts may wish to consider account level config.
In July, new privacy laws go into effect for California and Virginia. Given this context, there were requests from the Committee to add a geo filter to provide the ability to restrict rules to just those states. This is possible, but PBS-Java resolves geo location after reducing precision making this hard to implement with confidence. PBS-Go relies on accurate user.geo information in the OpenRTB request provided by either the publisher or upstream systems with similar confidence uncertainties. As such, at this time we don't see much value in a geo filter.
Ok, here's a proposed extension to the condition to accommodate the desire to restrain this behavior to particular geographic areas:
rules: [{
condition: {
gppSid: [7,8,9,10,11,12],
geoCountry: ["USA"]
geoRegion: ["UT","VA","CT","CA","CO"]
},
allow: false
}]
We would add 2 new conditional attributes:
Notes:
If we wish to proceed this with feature, I wish to offer a proposal which combines the geoCountry
and geoRegion
filters, from the perspective that they are hierarchal.
Example:
rules: [{
condition: {
gppSid: [7, 8, 9, 10, 11, 12],
geo: ["USA.VA"],
},
allow: false
}]
Where geo
is a combination of the 3-character country code (ISO-3166-1-alpha-3) and an optional 2-character region code (ISO-3166-2, 2-letter state code if USA). This aligns with the OpenRTB 2.x geo.country
and geo.region
fields.
The following patterns are acceptable:
<Country Code>
- geo.country of the request must be in this list to match. geo.region is ignored
<Country Code>.<Region Code>
- geo.country and geo.region of the request must be in this list as a complete pair
@SyntaxNode 's proposal discussed in committee and approved. The scenario that hierarchical geo simplifies is when multiple countries with multiple regions are involved. e.g. ["USA.WA", "CAN.BC"]
The matching algorithm for when condition.geo is defined:
Another aspect of the coming legal milestone is support for taking action based on the Global Privacy Control flag. So I propose adding another straight-forward gpc
condition that would need to be implemented with the existing GPC issue
rules: [{
condition: {
gpc: "1",
geo: ["USA.VA"]
},
allow: false
}]
Processing:
gpc
exists in a condition, check regs.ext.gpc. If it exists and matches the value in the condition, return trueDiscussed in committee. The IAB hasn't yet merged regs.ext.gpc. We will monitor that part of this proposal.
Done in PBS-Java 1.122
After detailing the Activity Infrastructure in https://github.com/prebid/prebid-server/issues/2591 and the full GPP Privacy Infrastructure in https://github.com/prebid/prebid-server/issues/2686, I've started to become concerned about missing the legal timeline for MSPA/USNat enforcement. I think it will take several months to build, test, and release these features.
Here's a proposal that could utilize the Activity Infrastructure and give publishers a somewhat extreme anonymization option as way to meet the deadline while giving ourselves more time to build out the GPP Infrastructure.
The idea is to build a condition into the existing activity control infrastructure that checks the GPP SID
This new
gppSid
condition does the following:See below for additional conditions:
geo
andgpc
.