You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
While digging in on prevWins for #852 , the idea of allowing the previous wins being "aggregated" but still only available in browserSignals came back to me. It would be useful regardless of the answer to #852 , but especially so if my updated understanding is confirmed.
Goal
The goal would be to allow some transformation to run that would take the IGs auction win history and output a more convenient (possibly also more concise, though not necessarily) version of the data that the generateBid function will need, rather than having to do that at auction time.
For instance, given my old understanding that the ad is the renderURL, a super basic thing that could be done would be:
[[t1, ad1], [t2, ad2], [t3, ad1], [t4, ad2], [t5, ad1], [t6, ad2]...]
---->
{
ad1: [t1, t3, t5...],
ad2: [t2, t4, t6...]
}
In this case it wouldn't be more concise (maybe a bit) but it would be more convenient for lookups at auction time.
It would be great if this transformation could be "guaranteed" to run on some regular basis (say once an hour) which would allow the transformation to output more meaningful capping information, something like:
{
ad1: {frequencyType: hour, frequencyValue: 2, mostRecent: t5}...
}
Could We...
So kind of thinking out loud here, could we do something like:
Interest Group can define a prevWinsTransformer, that takes in the previous wins of the IG and outputs a serializable thing.
Each IG now has a new dictionary, prevWinsTransformed with two fields prevWinsTransformed and updatedSinceLastWin which defaults to false.
A call to the prevWinTransformer results in the prevWinsTransformed being set to the output and updatedSinceLastWin to true.
In addition to prevWins the browserSignals of BiddingBrowserSignals gets the prevWinTransformed dictionary.
After an IG finishes winning (render of the renderURL and calling of report*), updatedSinceLastWin is set to false.
The browser tries to run the transformer of the winner after win.
Some periodic process runs to ensure that any IG with prevWinsTransformValue.updatedSinceLastWin has it's transformer run.
Priority: Low I think
I don't think this is the highest, or likely even medium'est, priority, but if indeed what is passed into generateBid in browserSignals.prevWins is the full ad blob from the previous win, I could see it being more important as there will likely be more done than just capping for a renderURL.
The text was updated successfully, but these errors were encountered:
While digging in on
prevWins
for #852 , the idea of allowing theprevious wins
being "aggregated" but still only available inbrowserSignals
came back to me. It would be useful regardless of the answer to #852 , but especially so if my updated understanding is confirmed.Goal
The goal would be to allow some transformation to run that would take the IGs auction win history and output a more convenient (possibly also more concise, though not necessarily) version of the data that the
generateBid
function will need, rather than having to do that at auction time.For instance, given my old understanding that the ad is the
renderURL
, a super basic thing that could be done would be:[[t1, ad1], [t2, ad2], [t3, ad1], [t4, ad2], [t5, ad1], [t6, ad2]...]
---->
{
ad1: [t1, t3, t5...],
ad2: [t2, t4, t6...]
}
In this case it wouldn't be more concise (maybe a bit) but it would be more convenient for lookups at auction time.
It would be great if this transformation could be "guaranteed" to run on some regular basis (say once an hour) which would allow the transformation to output more meaningful capping information, something like:
{
ad1: {frequencyType: hour, frequencyValue: 2, mostRecent: t5}...
}
Could We...
So kind of thinking out loud here, could we do something like:
prevWinsTransformer
, that takes in the previous wins of the IG and outputs a serializable thing.prevWinsTransformed
with two fieldsprevWinsTransformed
andupdatedSinceLastWin
which defaults to false.prevWinsTransformed
being set to the output andupdatedSinceLastWin
to true.prevWins
thebrowserSignals
ofBiddingBrowserSignals
gets theprevWinTransformed
dictionary.Priority: Low I think
I don't think this is the highest, or likely even medium'est, priority, but if indeed what is passed into
generateBid
inbrowserSignals.prevWins
is the fullad
blob from the previous win, I could see it being more important as there will likely be more done than just capping for arenderURL
.The text was updated successfully, but these errors were encountered: