You are welcome. Thanks for the suggestion!

Hi Lee,

We hear you. I'll raise it with the devs.

Paul.

But why the random list of groups? Is this presenting a random list of groups to a player - so they can decide which one to try to join or something?

So - like GetPlayersSocialLeaderboard() - the app would provide the subset list of groups that they are interested in?

Should be simple enough to add. Curious though - what's your use case? How do the list of groups you want to see relate?

We agree with that @antony - we'll get that request to the devs.

Hi @antony - I'll send that one off to the devs and see how that would affect the implementation.

We'd likely make it a separate call - as that's a heavier operation that just returning your friends in relative order. That said - if you have to do it manually yourself that's a LOT heavier on the servers -- so I agree that this new call would be beneficial.

Stay tuned!

Hi folks,

FYI, here's one minor update regarding the Retention Analytics screen:

We have changed it to show Classic retention by default.

The reason for the change is that Rolling Retention naturally trends downward over the 30-day period of the report. That's simply due to mathematics. Rolling retention for a particular day measures whether the user returns that day - or any day thereafter. Thus - the days at the end of the calendar period have fewer days after them - and so the stat will naturally be lower.

We don't want folks to mistakenly think their retention is trending down - so we're now defaulting to Classic Retention which is more deterministic over the 30 day period. For those who wish to view the Rolling Retention - it's just a mouse click away!

Cheers!

Paul.

Right now the only valid value is "retention" - but obviously we've built that API with an eye to the future!

Well - the "owned custom entities" approach could come into play again if you want to view the matches across the system. Although owned custom entities are owned by players (and get deleted if a player account is deleted) - they are still queryable across the system... via API or the Portal (see App > Global > Global Data > Custom Entities ).

I hope that helps!

Oh - and I should note that you can retrieve the latest retention report - as well as the retention report for a specific start date...

https://docs.braincloudservers.com/api/capi/report/sysgetlatestreport

What we don't have right now is an API to list the reports that are generated and waiting for retrieval. We are working on that for a future patch.

Also note that we currently keep daily reports for 10 days - and weekly reports for 37 days.

Thanks for the feedback Christophe! We'll take a look into those requests.

Hi,

Users with LIVE apps on brainCloud's Public BaaS (i.e., https://portalx.braincloudservers.com) should now have access to our Retention Analytics. (You can find the numbers on the App > Reports > Analytics > Retention screen.).

So - any questions on these numbers? What they mean? How they are calculated? We are happy to clarify any questions you may have.

We are also interested in your overall feedback regarding the feature.

We've already had the question of whether we could calculate the numbers on a per app-version basic... (i.e. according to the gameVersion passed into the Authenticate call). We're going to look into that. That said - the whole reason we did Retention Analytics was so that we could integrate it with a new LiveOps Events feature we're working on -- so we'll probably tackle those scenarios at the same time.

Anyway - your feedback is invaluable. So look up your numbers and hit us up with questions and/or feedback!

Paul.

Hi @tlim and @devsleeper ,

Player stats are definitely useful for keeping all-time stats.

If you want to limit stats to recent matches - you might consider using "Owned Custom Entities" for each match result. You can set a TTL for the objects so they don't stick around too long - maybe 90 days?

And then just retrieve the last 20 match results (if they exist) to sum up the totals and produce the stats.

I hope that helps!

Paul.

Hi @tlim ,

What sort of match history?

What sort of game are we talking about? Which multiplayer APIs are you using?

Paul.

Hi @LEE-JONG-GUN ,

Thanks for the feedback.

This is admittedly a tricky one.

The best route I've seen to handle it is to use our shared (i.e. parent-child) accounts feature - which involves using a parent app for the player account - and a child app for the character accounts.

Note that it does involve two live apps - but we can put your parent app on a special plan with no live fee (you just pay for API calls) - and there won't be a ton of API call from that app - cause 99% of all calls will be against the child app.

There is more info here - https://docs.braincloudservers.com/learn/key-concepts/authentication/shared-accounts/

I hope that helps!

Paul.

Ah - perfect. Yeah - that sounds like a better option given the full requirements.

Glad you found it... and welcome to brainCloud!

Hi @devsleeper ,

I think I'd recommend you model "Location" as a Custom Entity collection. You can use the "entityId" as your shareable id... and include custom attributes in the "data" section of the object - like "data.includeInMatchmaking", etc...

It would probably best be an "Owned" entity - so if the user account that owns it is deleted - it is deleted as well.

I hope that helps!

Paul.

Update - we've confirmed with the server team that we believe we are all set.

We'll perform some tests when the Sandbox servers cut over the week of Jan 20th to confirm.

Paul.

Hi @Darren-Wood,

Thanks for reaching out. I'll pass this through to the devs to investigate.

Here's the developer bulletin for those following along: https://developer.apple.com/news/?id=09za8wzy

My first thought is whether you need to regenerate the SSL certs that are used for generating the necessary push notification tokens. But that last line seems to confirm that that is NOT necessary:

"At this time, you don’t need to update the APNs SSL provider certificates issued to you by Apple."

This part does imply a potential server-side change:

To continue using APNs without interruption, you’ll need to update your application’s Trust Store to include the new server certificate: SHA-2 Root : USERTrust RSA Certification Authority certificate.

The quick reading I've done says it's likely that our servers already support that trust store. It's been available since 2015 - and we update our base images regularly.

And to confirm - everything I've read says that you shouldn't need to change anything in your app's client-side.

That said - we'll be sure to test it out.

Thanks for bringing this up! Our team will be looking into this as soon as they return from holidays - which is the week of January 6th.

Cheers!

Paul.

Resources:

• https://stackoverflow.com/questions/79256876/action-required-apple-push-notification-service-server-certificate-update
• https://medium.com/@musmein/apple-push-notification-service-server-certificate-update-a58dee70f9f8