Add unique playcount metric to maps
Unique playcount metric would show how many unique players played the map. This is important because players forget or don't bother rating maps, and this would enable passive gathering of map popularity. Even more, if this is applied to all submitted maps, this can be used as a key metric in determining loved status eligibility or determining map status in an automated system.
Saw that https://github.com/ppy/osu-web/issues/3359 got done today, as well as clayton's comment. Want to see how doable something like this would be, if at all. Alternatively, what is the possibility of a "unique downloads", or just "downloads" counter in general? Can see that sorta thing being a bit easier to develop/maintain
Currently best way of gauging how many people have played/looked at a map is by submitting a score yourself, and looking at the amount of submitted scores on a given scoreboard - obviously not good indicator when a) some people don't submit scores and b) certain skill groups may only play specific difficulties / difficulty ranges.
Also agree with abraker95 that, if implemented, this could be good criteria for loved status eligibility.
- downloads are not and will not be tracked, nor is it a good metric.
- unique players is hard to track and likely won't be added.
- you can check play count by looking on the beatmap details page. you don't need to play the beatmap.
isn't this what already exists in osu_user_beatmap_playcount? there's a row per player per beatmap
for what I want to look into, it'd be helpful to be able to query this by beatmap or beatmapset id
that table cannot be accessed by beatmap ids. it would absolutely destroy file size and performance.
would require more implementation and static caching
"you can check play count by looking on the beatmap details page. you don't need to play the beatmap."
I've played the game more than long enough to know that hahahahaha. I'm on about the fact that maps considered 'pp farm' end up with retry-spamming, which artificially inflates the playcount, making it less representative of the actual popularity / amount of unique players playing a given map. In that case, tracking when a player first plays, or possibly completes, a map is much more accurate.
That said, I totally get the other points, and judging by your response to clayton it's prolly a nightmare to implement other shit hahahaha.
I'm on about the fact that maps considered 'pp farm' end up with retry-spamming, which artificially inflates the playcount, making it less representative of the actual popularity / amount of unique players playing a given map. In that case, tracking when a player first plays, or possibly completes, a map is much more accurate.
These 'pp farm' maps also end up with a significantly higher number of unique plays on them as well. If your intention is to weed out maps like that, unique play count is not the answer.
These 'pp farm' maps also end up with a significantly higher number of unique plays on them as well. If your intention is to weed out maps like that, unique play count is not the answer.
Think you've misunderstood. I don't want to 'weed out' anything, I just want (if possible) a more easily accessible, more accurate way of determining how popular a map is than a map's playcount hahahaha.
that table cannot be accessed by beatmap ids. it would absolutely destroy file size and performance.
would require more implementation and static caching
by file size and performance do you mean an index? ~~there already is an index on beatmap id for it, at least in the migrations here.~~ (edit: totally misread the file, there is no index in migration either, oops) "unique players" should still be cached too if that were a stat shown on all maps
if it's at all possible I feel like there's more info to gain from exposing the whole table to an API though, and not only the player count-- for random example you'd be able to look at the stats of users who played the map most to see what kind of audience the map has, instead of just how large the audience is
maybe I'm getting ahead of the point of this issue, but in context of project loved im really just looking for as much info as I can get. abraker and I are trying to experiment with different models that would pick out loved-worthy maps from unranked, primarily to aid the captains in choosing maps for loved, but also keeping in mind a good system here could be the groundwork for overhauling Loved into something that better represents what the community wants to see
There's no index on production, and it's already one of the (actually, the second) hottest and largest tables. Adding it would likely double the size and reduce insert performance to a point it may become an issue.
Would require a considerable amount of effort to make this happen. I'm not strongly against it but it's more a matter of priorities.
would it be possible to get a regular export of osu_user_beatmap_playcount on https://data.ppy.sh? that would be a huge help if querying the live table by beatmap ID is never possible
For the same top users? I can look at doing that, sure.
abraker and I are trying to track popularity of unranked & loved maps, or all maps if possible, using "unique playcount" and the distribution of players from this table (+ some other stats already available via API). for that purpose, it'd need to be filtered by beatmap if at all... forgive me if this is a ridiculous request cuz idk what the costs look like on your end, what would help us is a dump of the full table, all rows. if that's not possible, these are the filters I can come up with that would still allow our main goal:
- only with beatmap_id that aren't ranked/qualified
- only with beatmap_id having a playcount of >=100 or so, probably depends on the game mode for what a good cutoff is
unfortunately these both still wouldn't be using the table's current index

It's unfortunately not simple.
Is there a reason you need this on a beatmap basis, not set? Can you not just look at set playcounts then retrieve data for beatmaps?
we want to lookup how much playcount each player has on given map(set)s, so it'd have to go through this table either way. we already have the total playcount per-map and per-mapset, those are on API. not sure if I understood your question correctly
and lol alright I see why uploading all of it is not an option. without a query doing a full table scan, I don't think I can get a smaller portion of what I want from it either =(
Thinking about this, I believe there is a solution which could introduce the statistic, but it will require a bit of work (and support at the point of setting scores).
- Populating existing stats can be done using the
user_beatmap_playcounttable (will be a huge process, but not impossible). - Moving forwards, the stats can be incremented when a user records their first play on a beatmap (should be a very quick/free check at this point).
Will bump this up to priority 3 since it seems like a nice stat to be able to display. Maybe something we can tackle after lazer is integrated into the scoring ecosystem.
is the unique_users column in the osu_beatmap_mode_stats table still being updated? I didn't know about this until just now seeing it removed from osu-web for another feature (https://github.com/ppy/osu-web/pull/11305/files#diff-4865810ba40ea2890904652797e8e412407ea6c472df309a61af2872049f9208) but it seems relevant here