brainCloudAdmin group

johnh

@Ali-Raza could you let me know your Team ID and the AppIDs you would like this increase for? thanks

johnh

Added case 14121

johnh

Hi @Omar-Alzayed When apps have millions of users, browsing all users can have poor performance.
If you have a smaller number of users, it can be useful.
There is a way to create a segment so you can browse all your users.

Go to App > Design > Segmentation > Segments
Create NEW SEGMENT

There's a couple different ways you can return ALL users. The one I like is to use the criteria A/B Testing ID 0-99 which will return all your users.

Looks something like this:

Segments are automatically run nightly at around 3am but you can press REFRESH SEGMENTS to run it immediately.

Note that the refresh will take time to complete according to your user count, you may wish to do this during low player traffic.

In the case of this particular segment, I believe the Refresh will need to run TWICE to capture all your users. (I think the AB code needs to be initialized in the first pass, and then it can be read in the second pass, capturing all of your users.)

Please take care not to launch the second Refresh before the first one completes. (If you have 10,000+ players then wait about 30 minutes or so)

Once you have players in the Segment, you can browse by Segments. Go to
User > User Browser

Choose BROWSE, then check the box to browse within a segment. Choose the segment.

Reminder, once you have millions of users, this can be very slow. But you can create more refined Segments to filter to just the interesting users, such as Has Bought Something, Is at Least Level 10, and so on.

Segments allow compound conditions so you can really filter to exactly who you want.

Segments can also be used to target Sales and Promotions to specific player groups. For example you could create a $0.99 one-time, loss leader promo that is available to only those players who have not bought anything in your game yet. It's a very powerful system.

Could you let me know if this helped you?
Thanks
John

JasonL

Yes, your current design matches the recommended pattern: Redemption Code is a one-way gate for “has this user consumed this shared code?”, while your claim entity is the authoritative state machine for fulfillment, retries, and audit (Redeeming → Redeemed → Granting → Granted / GrantFailed), with Granted as the idempotency guard for duplicate grants. The main thing to watch is call ordering: it’s preferable to write the claim to Redeeming first as an intent record, then call redeemCode(), so any Redeeming with no further progress is detectable and recoverable by your server without depending on the Redemption Code record.

Consolidating the brainCloud-side claim init + redemption into a single CloudCode script is a good fit, provided the script is strictly idempotent and fulfillment stays in your server pipeline. The script should read the claim state, upsert to Redeeming if needed, call redeemCode() (skipping if already Redeemed or beyond), update the claim to Redeemed, and return rich state (claimState, claimId, rewardDataId) so your server can then perform fulfillment and issue a final Granted / GrantFailed update. This gives you a clean two-call pattern from the server to brainCloud on the happy path, while the script’s state checks make retries safe even though CloudCode itself is not transactional.

JasonL

For a shared/multi-use Redemption Code, a specific user’s redeemed record can only be reset or deleted through the tester-only deleteRedemptionForTester() flow, so there is no supported production operator/API path for non-tester accounts, and the tester reset should be treated as a QA/dev tool rather than a live recovery mechanism.

If reward fulfillment fails after redemption, it does not provide an automatic recovery or re-execution path that restores the same user’s redemption state in production; synchronous failures record a failed attempt, async flows can end in Failed on timeout, and any retry is only possible if the code type’s maxRetries still allows another user-initiated redeemCode() attempt.

customRedemptionInfo can be used as a persistent per-user audit field if your fulfillment script writes it back, since it stores the script response on the user’s code record. However, it is not designed to be updated later through a direct external API after the fact.

The tester reset is explicitly intended for testing/cleanup only, not as a production recovery operation.

For production operational rewards, the safest pattern is a shared Redemption Code for claim detection, plus a separate Custom Entity for the fulfillment state, which provides auditable handling of pending/fulfilled/failed/retrying without relying on the Redemption Code record as the source of truth.

Paul Winterhalder

Hi @moondory77 ,

Yes, you observed correctly.

During the data migration portion of the deployment (which occurs after the system has done a bunch of validation and consistency checks), the system temporarily disables your app to do the actual data migration.

This is to protect the data integrity of your app - as your app's metadata, reference data and cloud code scripts are all changing underneath it. So we disable the app, make the changes, and re-enable the app.

All of this normally takes just a few seconds - though it does depend upon the number of changes being made.

I hope that helps to clarify things!

Paul.

johnh

Submitted case 14062, case 13344

Thanks @noah I will keep you updated

johnh

Hi @noah thank you for your help explaining your needs.
I think I have a better understanding of your request.

I have redone the mockups so it is clearer the materials will be consumed. I think these new mockups are closest to the feature set you are requesting. Could you let me know?

ITEMS
In this mockup, the player would need to pay 10 coal, plus the required components to get the Trusty_Steel_Sword.

The operator can specify a mix of Virtual Currencies, and a count for each component.

CASH PRODUCTS
In this mockup the player can make a cash purchase provided they have the required materials, which will be consumed to issue a Premium Steel Sword.

Upon choosing to edit the Required Materials, the operator would be presented with edit panels that follow the existing Cash product functionality.

Pressing the edit pen would look like this

Once I have your confirmation, I will present your request to the team at the next Product Design meeting.

Let me know,
Thanks
John

Paul Winterhalder

Hi @noah,

I agree that this would be a good feature.

I've been doing some thinking on it...

What if we could restrict an S2S server to only being able to call a specific set of scripts? That way you would be in full control as to the scope of the API that you are making available.

Would that work for your use case?

Paul.

johnh

@noah I wish to be careful to deliver the feature as you need it. Could I ask you more questions about Prerequisites?

Let's return to the mockup for ITEMS. I am showing a Deluxe Hat Rack.

In this mockup, setting a Prerequisite only means: "Does the player possess these items in their inventory?"

In the illustrated case, if the player has John's Hat and Mark's Hat in their inventory, then they can successfully attempt a purchase of this item.
It will cost them 1,234,234 COINS and 5,345 Credits to receive the item.

In this example, after paying the COINS and Credits to receive the Deluxe Hat Rack, the player still has John's Hat and Mark's Hat in their inventory at the end of the transaction.

So could you verify that when you said, "We had only one step in mind. Consuming items I own while purchasing items" did you mean:

A) prerequisites are not consumed when making an item purchase
OR
B) that you are seeking a system where ITEMS can be included in the List Price of an ITEM?

I have a follow-up question: When the client calls Service ItemCatalog, Operation: GetCatalogItemsPage, would it be your preference that:
Items with prerequisites that the player does not posses should be:
A) Not returned
B) Returned with an attribute, like "CannotBuy"
C) Returned normally?
(Because in a case where the player does not meet the prerequisites they will not be able to successfully purchase the item.)
Could you provide some guidance here.

Thank you for your help and advice,
John

brainCloudAdmin

Posts

Member List