Skip to content
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

Allow More Expressive Scoring and Sorting: Two (or N) Tiered Scoring by Score Ad #1073

Open
thegreatfatzby opened this issue Mar 4, 2024 · 4 comments

Comments

@thegreatfatzby
Copy link
Contributor

Given the current structure of the scoring process, in which each bid is evaluated independently by user space code, and then the Chromium code sorts and returns the highest scoring bid based on the doubles returned byi scoreAd (i.e. if we don't shift to something like this), it would be very helpful if we could score and sort in a more expressive way. Ideas include a) return multiple doubles, i.e. a tuple (x,y) where the Chromium space code would rank first on x and then on y or even b) allow any return value and then a sort function (although I think that basically gets us to #773 ).

This would be helpful for supporting cases where ranking can occur within priority groups or private marketplaces. An example from our sell side tech is that a seller will set priorities on various demand sources, and if an otherwise higher scoring ad from a group with a lower priority is submitted, the higher priority one still wins (see here).

Today we can accomplish this by doing some tricks with multiplying the "more important" value, x in the tuple above and priority from the example, by some large number (say 1,000,000) and then adding the "less important" value in without a multiple. However, the dimensional reduction comes at more than just a philosophical cost: a) this requires constraining the rest of your scoring to accommodate that multiple and b) can lead to an escalating series of tricks to try to express a priority in a given situation (i.e. you can't just say "make this one win by scoring it to 10,000, b/c now 10,000 may not be a large number".

Absent scoreAds, a user space sort function would be ideal...but since I think that will be seen as the same privacy model violation as scoreAds, I'll go with the Double Tuple for this issue. Ideally the number of dimensions expressed would be more than 2, although I don't think it needs to be unlimited, could probably cap at 5 and give a lot of flexibility for expressing priority, "win now", etc.

@michaelkleber
Copy link
Collaborator

I agree that the desirability returned by scoreAd() could be a tuple with lexicographic order, instead of just a number. Right now, though, desirability <=0 means "will never win", and it's not obvious to me how to translate that into your tuple-based approach.

But have you considered using Math.atan() to achieve your goal? The arctan function takes any number as input, is monotonic (that is, bigger input produces bigger output), and returns a value between -π/2 and +π/2.

So if you wanted to sort ads based on tuple<x,y>, where x is an integer and y is any number, then you could use desirability 4*x + Math.atan(y) and get the same thing as lexicographic sort of your tuple.

@thegreatfatzby
Copy link
Contributor Author

I have to admit I hadn't thought about trigonometry here. I agree that, or something like it, can likely work for a two-tuple-double. I do think being able to express scores in a way more meaningful to the domain will be helpful for development, debugging, etc.

For the immediate exclusion aspect a couple of options could be:

  • The return value can still be a single number < 0 to indicate exclusion. If it's a single number >= 0, then we can talk through it but the framework could require consistency between the return values for anything other than < 0.
  • Any < 0 value in the tuple could indicate exclusion.
  • The object returned by score ad could support an additional field to express "exclude now".

@michaelkleber
Copy link
Collaborator

I have to admit I hadn't thought about trigonometry here. I agree that, or something like it, can likely work for a two-tuple-double. I do think being able to express scores in a way more meaningful to the domain will be helpful for development, debugging, etc.

My inclination here is to say that we shouldn't try to build something new for a use case that can already be handled by a one-line JS conversion utility function. The goal "more meaningful to the domain" unfortunately seems like it might be too much to ask, since every user of the API might have a different domain model in mind.

@MattMenke2
Copy link
Contributor

While you could squeeze in as many values as you want (without arctan, if you know the base range already), it does require discrete ranges for all but the last digit, and the more values each position can have, the more roundoff potentially depends an issue. How much resolution do you need in each of the numbers?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants