Hi Francesco,

Thanks for reaching out. Certainly our screens and documentation for Promotions could use some more love - we are working on that.

To answer your questions:

Can Users have more than one promotion active at the same time?
Yes. And in that case, the "lowest" price for an item wins.

In the case of automated promotions, what products count towards the "max purchase" limit? If I have a product with the price left "as is" in the Prices list inside that Promotion, does it get counted? More info on this max purchase field would be appreciated.
Hmm - I'm putting a question into the devs on this one.

I have two automated promotions enabled and a User is in the segments used by both, but I don't see them when using the GetElegiblePromotions call. Is this a refresh issue? And if so how do I force a refresh to see them immediately?
Automated promotions are tricky - as a user must "ENTER" the segment to trigger the promotion. If they are already a member of the segment at the time the promotion is created, the automated promotion will not trigger. We are currently improving the user promotions screens to better communicate this behavior - and make it easier to test.

If I have a promotion active where a product is set "not for sale", I don't see that product in the app store, which is the expected behaviour. What if I have another promotion active at the same time where that product is set as available?
What do you mean "as available" - with a particular price? If you mean "as is" I'm pretty sure that "Not for sale" will win - and the product will not being shown.

What if the same thing happens but in promotion #1 the product is "as is" and in promotion #2 it's set with another price value?
Lowest price wins. If promotion #2 is less than the "as is" price than it should be the one shown.

I hope that helps - we'll chime in with more clarifications once I have them from the devs.

Paul.

Okay - cool!

The time format is "epoch millis". (At the lowest levels that's how brainCloud's API deals with time).

An example would depend upon the client library you are using? Unity? Unreal?

I'll let the client team chime in with the details once we know what you are using.

Cheers!

Paul.

สวัสดี ต้องขออภัย แต่เราให้บริการช่วยเหลือเป็นภาษาอังกฤษเท่านั้น

[Hi. Apologies - but we only provide support in English.]

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!