brainCloudAdmin group

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

Paul Winterhalder

Hi @dbgtdbz2 - we certainly don't have an api for that sort of thing right now.

Can you send a private chat in via the support system - addressing me - and give me a heads up of what you're up to?

Thanks!

Paul.

JasonL

I’ll forward your request to the team for review...

JasonL

Yes, the behavior you’re describing is expected with the current implementation. RefreshMySegments, RefreshPromotions, and login will not attach the promotion to users who are already in the segment, because the system is designed to only grant automated promotions when the user enters the segment (i.e., when it shows up in enteredIds). The fact that Reset Segments or Re‑evaluate All Segments fixes it is also expected, because those actions force the user back through the segment‑entry logic.

We’re working on a fix to make this smoother. The practical effect going forward will be that, when a new automated promotion is created or attached to an existing segment, the next segment refresh will automatically apply it to all currently‑eligible users in the background, without you needing to reset or re‑evaluate segments manually. This should make the behavior more predictable, especially when you have a large number of existing users already in that segment.

JasonL

Our automated promotions were designed to pull members of a segment into a promotion, which is why they can trigger notifications. When an automated promotion fires for a user, they can be notified, and that notification is intended to draw them back into the game. So startTime is effectively the wall‑clock time when the batch job processes that user, not when the user logs in. A user who never logs in will have their promotion silently expire in the background.

I’ve forwarded your request to our team to see if we can look at adding a flag that lets developers specify that an automated promotion should only trigger on login, which would likely align well with the kind of “starter‑package” use case you described.

johnh

Case 13633 - [implementing]

JasonL

Thanks for the suggestion and the explanation of the workflow benefit. I’ll bring this request to our team for review and follow up here...

johnh

Hi @gyutaelee I am bringing this to the dev team for further discussion. thank you for suggesting it.

JasonL

@noah The team is working on this, and we’ll share any progress here once there’s something concrete to report.

brainCloudAdmin

Posts

Member List