-
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
Feature request: reuse GVL ID of the original adapter with an optional flag #10759
Comments
You can specify gvlid in the options of Note that the alias/gvlid behavior was not changed, we just added a warning. As far as I know your aliases would have failed consent checks all along - but up until 8.11, bidders often did not actually need consent (only purpose legitimate interest). With that fix a missing gvlid is more of a problem, that's the reason for warning about aliases. I think we can improve the message to make it clear that you can still re-use the gvlid, it just won't default to it. |
To extend on that, it would be very helpful if the |
That's a good suggestion - tentative name for the option: |
This strikes me as in the 'i have no idea if this complies with the law but let's just try it bc yolo' category of options. I'm not sure if this is wise to facilitate, as publishers will just see it as button to press to get everything working even if it puts them at rather high risk of sharing data with a non-consented party. We're not trying to make the project a series of legal landmines, but rather a place where one has to rather intentionally make effort to side step legal compliance. |
Is the risk of using the wrong gvlid not higher, than using the base gvlid incorrectly with an alias? If an SSP wants an alias set, they also share the gvlid. If I want to use a simple alias, I have to look up the gvlid with the risk of finding the incorrect one. How likely is it that a gvlid of a bidder changes? And how do you keep track of it when using aliases to separate multiple placement ID's? |
note that built-in aliases in bid adapters that don't have a gvlid set also need to be manually configured with gvlMapping for them not to be disabled in the EU, and those don't even trigger a warning like the custom aliases do (#10716) |
after chatting with @dgirardi live; I'm convinced it is reasonable to have |
Type of issue
bug
Description
I wanted to update my prebid.js from 8.2 to 8.20 and doing so I now have the following kind of warning in the console :
Alias '${alias}' will NOT re-use the GVL ID of the original adapter ('${spec.code}', gvlid: ${spec.gvlid}). Functionality that requires TCF consent may not work as expected.
I've seen it's related with issue #9717 but I haven't found the logic behind this discussion. Here is my use case (since prebid 1.11) : We are working with more than one appnexus seat on the same adunits. For instance, if for my adunit I have the following bidders :
With placementId 12345 related to one appnexus seat and placementId 67890 related to another appnexus seat, then appnexus adapter will make one unique call for both of these placements and will rejected it because one call must be about only one seat. Response from appnexus would be :
{"error":"Could not parse valid tag in request"}
So I am using aliases like this :
and adunits conf :
This makes that I have two appnexus calls, one for each seat. For these aliases, it seems to me like it is legitimate to use the original bidder GVL ID.
Unfortunately now I no longer can. It looks like a breaking change, and I actually don't really understand the logic behind the fact that aliases could not re-use the original bidder's GVL ID. Isn't it the responsability of the who configures it ?
The text was updated successfully, but these errors were encountered: