Question: How to advise users on enrich UFPD Activity Control #14427
Description
Recently, the Permutive RTD module was converted to a vendorless GVL ID (here) because Permutive acts as a processor on behalf of the publisher. We rely on the publisher's instructions to process data for them. Users of the RTD module are seeing Activity Control denied for Permutive.
Reviewing the FAQ for Prebid, the vendorless approach only allows consent for purpose 1 (access device), which is why I'm assuming transmitUFPD is blocked, as it requires purpose 4 (here). As Permutive is a processor, the IAB have advised we should only be registered for purpose 1. Our GVL ID will never have purpose 4; we rely on the publisher to have purpose consent 4. I don't think this part matters though, as our RTD module is defined with the vendorless ID.
Reviewing the Activity Controls page, should we advise users to create a rule that allows the RTD to transmit UFPD when purpose 4 is granted to them? Does this mechanism surface the publisher's consented purposes that can be used to determine this? In the realtime data module, the consent values are passed in during init.
Also, does the vendorless GVL only define purpose 1, erroneously? Rather, it should include all the publisher's purposes, as the modules process data on the publisher's instruction, which may have various uses for those purposes.