New Statistics: Max Num of Stats & Cost? Retrieving a Single or A Specific Set of Statistic?

[elfin matrix]

Is there a limit on the New Statistics system that how many statistics or leaderboards we can created for a title? And is it really that a leaderboard costs 0.049USD/MB (not GB) to store?

Also, currently there is only one API "/Statistic/GetStatistics" to read back the statistics for a (player) entity, and it seems to read the entire thing. Is there, or will there be, an API to read a specific statistic or a set of specific statistics in order to update client side displays without pulling down the entire thing should the statistics collection grows larger?

[strange raptor]

Where did you see the pricing 0.049USD/MB?

[elfin matrix]

@strange raptor I saw it here: https://playfab.com/pricing/
The documentation mentions that there are dedicated pricing meters for statistics and leaderboards, so I thought the pricing page must already have the pricing for those meters up. I apologize if this is actually the pricing for the legacy leaderboard.

[pearl delta]

It is the pricing for the new leaderboards and stats (also note that you have in built quota for the various pricing tiers).

For the paid tiers, the limit is 1K stats and leaderboards.

In your scenario, is there consistent grouping of the stats you would request or it can be any combination of the stats? Right now, the meter ticks wouldn't change depending on how many stats you ask (it could, in the future if you have consistent grouping that allows us to optimize querying).
We can add the selective retrieval to reduce the payload size and processing overhead on the client side.

[elfin matrix]

Hi Rakesh, thank you for your reply.

The reason that I want to pull only small set of statistics is indeed to minimize network traffic and processing load. If I really go down the route of opening a statistic for each of the hundreds of level in my game, i.e. storing the high score of the player for each level as statistics instead of read-only data, it would be a huge amount of data to refresh the client-side displays after the new score for one level is submitted if all the data is returned in a single fetch.

That being said, my question would be:

1. Is it advisable to open hundreds of Statistics and store the numerical high score of a player that way, vs storing them as User Data? The cost of statistics is much cheaper than using user data (Profile meter), so in theory this would be a very good way to save cost on storing numerical user data, like high scores and counters, but I wonder if this is the intended usage of the Statistics API?
2. Since the leaderboard is very expensive at 0.049USD per MB, i.e. 49USD per GB (assuming 1GB = 1000MB), is it likely not advisable to open a large amount of leaderboards? Say if I have 100,000 entries in a leaderboard, what would be an estimated size of it?
3. You mentioned paid tier has a limit of 1000 Statistics & Leaderboards. I assume this is a hard cap applied to all paid tiers (including Pay-as-you-go, not just the monthly commitment tiers like Standard or Premium)?

[pearl delta]

Thank you for the details, that quite helpful to know the intended use on your side. We will consider adding a property to specify the list of stats you want retrieved.

1. Statistics for **best **scores for a level (and potentially a leaderboard for that) seems natural. The aggregation of the values is built into the system so that can also be helpful here. I am not sure about generic numeric counters though.

2. The size computation is documented here - https://learn.microsoft.com/en-us/gaming/playfab/features/pricing/meters/leaderboard-meters#leaderboard-storage. A 100K leaderboard of just one numerical value and storing no metadata would be 100K * (8 +8) Bytes = 1.6MB. 8bytes each for the numerical value and the timestamp.

3. That's correct. We are still refining the limits but right now it is the same for all paid tiers. What do your needs look like? Do you have a need for more than 1000 stats?

[elfin matrix]

Thank you Rakesh for the detailed response.

For 3, while my game won't necessarily need more than 1000 at the moment, being a rhythm game, each update we will add several new songs and each song will come with 3 to 4 levels, i.e. each update we will add around 15 to 25 new levels. Currently we have about 400 levels in total. Should we start to store the player's best score for each level as statistics, that means we will hit that 1K limit much quicker than other projects, depending on our update frequencies. 1000 is certainly more than enough for us to work with for some years, but it's always good to know that there is a limit and whether there is a way to lift it, so that we can rely on this technology in the long term going forward.