brainCloudAdmin group

johnh

Regarding your question: "Has the LiveOps feature been removed or deprecated? I can no longer find any documentation for it, and it seems to be missing from the dashboard as well."

I am not 100% sure which feature you are referring to. But maybe you are referring to a feature in our upcoming 6.0 release?

In brainCloud6.0, we will be moving Promotions and Redemptions to a new Braincloud Category called Live Ops.

We will also be introducing a new feature called Campaigns. (In some previews we may have described it as Live Ops Campaigns).

Campaigns are a major showcase of the 6.0 release and will enable Scheduled Limited-Time Game Modes and A/B Scenarios (w/ built-in promotions)

Additional features being released in 6.0 will compliment the development of Promotions and Campaigns making them incredibly easy to develop and powerful.

Could it be possible you saw a sneak peek at the Live Ops Campaigns feature?

Let me know,
Thanks
JH

johnh

@moondory77 Hello,

Regarding your question: " I can easily attach Items and Bundles to it. I am wondering if there is a way to achieve this programmatically via a Cloud Code API?"
The calls you referred to (SysCreatePromotion and SysUpdatePromotion) can be used to attach Items and Bundles to promotions.

Could you to check the example script in API explorer to see if it provides what you need?

The devs use the API Explorer to test the new/updated calls during development - and so the JSON there is always up-to-date.

JasonL

Hi @gyutaelee ,

Thanks for the detailed questions.

1. Friend Relationship Direction - Yes, bidirectional

AddFriends: When user A calls AddFriends([B]), both A and B see each other in ListFriends("brainCloud")
Both A and B will appear in each other's GetSocialLeaderboard results (if they have scores)
RemoveFriends: Removes the relationship from both users atomically

2. Idempotency - Yes, both are idempotent

Calling AddFriends([B]) when already friends: No-op, no error thrown (skips DB write)
Calling RemoveFriends([B]) when not friends: No-op, no error thrown

3. Consistency and Caching - Immediate

Friend changes are persisted immediately to the database (no write-behind caching)
ListFriends("brainCloud") and GetSocialLeaderboard reflect changes immediately after AddFriends/RemoveFriends
No eventual consistency or caching delay

4. Friend Count Limits - No hard cap

No code-enforced limit on brainCloud friends per user
Practical consideration: Friend IDs stored as array on UserProfile; very large arrays (>10K) may impact read/write performance

5. `GetSocialLeaderboard` Behavior - Returns all friends + self + pacers, no limit

Returns all recognized friends + self + pacers
No hidden maximum result count
Pacers are included (if leaderboard has pacers configured)
Warning: Response payload grows linearly with friend count

6. Recommended API for Top-N - Yes, use `GetMultiSocialLeaderboard`

GetMultiSocialLeaderboard with a single leaderboard ID is a correct approach for top-N results
leaderboardResultCount is applied after social filtering and score sorting
leaderboardResultCount is capped by maxMultipleLeaderboardScoreLimit app property (default 10, can be raised in app-basis)
Preferred over GetSocialLeaderboard for top-N because it has built-in truncation

7. Social Leaderboard Pagination - Not supported

No GetSocialLeaderboardPage API exists (only GetGlobalLeaderboardPage for global leaderboards)
Social leaderboards always return the full friend set (potentially truncated by leaderboardResultCount only in the multi variant)
I will forward your pagination request for team review

8. Billing and API Counts - 1 API call per request

GetSocialLeaderboard = 1 API call regardless of friends/entries returned
GetMultiSocialLeaderboard = 1 API call even with multiple leaderboards
AddFriends/RemoveFriends = 1 API call even though they modify both users' profiles

9. Recommended Usage - Yes, your design aligns perfectly

JasonL

Hi @gyutaelee,
Currently, brainCloud blocks unique indexes on all custom collections as a blanket safeguard. The check happens unconditionally before the system even evaluates whether your collection is owned or sharded, so it rejects the unique option with that error.

We can manually add the unique index for your FOLLOW collection on our end. Please send us a request with:

Your appId
The entityType (is it FOLLOW only?)
The field name(s) that need uniqueness
The desired index name (e.g., test_index)

Once we receive your request, we'll add the uniqueness constraint for you directly.

Paul Winterhalder

Ah - great to hear @jongdae-won . Thanks for the update!

Paul Winterhalder

That patch has been deployed @jongdae-won - give it a try!

Paul Winterhalder

Hi @jongdae-won,

We have a patch being deployed today that will allow you to create promotions that will allow you to target both existing and new members of a segment. We plan to have that deployed by the end of the day.

We hope that this will address the primary issue.

Your latest message seems to indicate that even new users to a segment are not getting the promotion offer... that does seem odd. I will point out that segments only get refreshed nightly and upon login - so if a new stat meant that they should be added to a new segment - the new segment and/or promotion wouldn't be refreshed until they logged back in again...

Unless... your app is making this call before it brings up the store:
https://docs.braincloudservers.com/api/capi/appstore/refreshpromotions

Could that be [that specific] issue?

In any event - we are hopeful that the patch should address your primary concern. We'll post here once it has been deployed.

Paul.

johnh

Added the additional details to 13660

johnh

@gyutaelee I will investigate the Per Promotion Deployment option you requested.

As I was working on this I thought there may be a workaround for you that you would like. This could work for your team with minimal effort and on your current version of brainCloud portal.

My solution hides the promotion so that only users you flag as TESTERS will see it.

This would let your PROD testers gain the benefit of the no-ads promotion without disrupting your monetization.

Within Automatic Promotions, there is the option to Target members of any of these segments.

Within Scheduled Promotions, there is the option to Offer this promo to: Only users in:

Advancing to App > Design > Segmentation > Segments we can create a segment that filters to players that are flagged as Testers.

Now, segments need to have at least one more criteria, so let's choose something like has logged in at least 1 time.

Save this Segment

IMPORTANT! Add the segment to your Promotion
This will limit the promo to only eligible users. Noone else sees it!

Next we will need to flag some users as Testers. For a DEV app, the easiest way to do this is to go to the User Browser, RECENTLY ACTIVE and pick players (your testers) with recent activity.

GO TO USER to bring up their user summary and check the IsTester checkbox.

Testers get a special icon

Next, we will return to Segments.

Segments are automatically processed overnight, but you can Refresh Segments immediately with the REFRESH SEGMENTS button. Please note: refreshing segments processes every player so this process can take a while and preferably left to low-traffic times of day.

After processing completes, we can check the cohort of testers by returning to the User Browser choosing BROWSE, and Browse Within A Segment.

These are my Testers, so everything worked.

Since only testers are eligible for the promotion, you are free to deploy it to PROD without affecting your monetization. And the PROD Testers you select will be able to gain the workflow benefit of no ads.

Could you let me know if this solution solves your problem?

Let me know if you have any questions,
Regards
John
-Design

johnh

Case 13660 - investigating