Posts

---

Admin Billing API request
• P 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.

---

Admin Billing API request
• J JasonL

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

---

Automated Promotion not associated for users already in target segment
• J 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.

---

Question about timing for newly deployed Automated Promotions
• J 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.

---

[Feature Request] Add "Open in New Window" option for Owner ID in Custom Entity view
• J 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...

---

New users are never counted — all users appear as Returning Users after launch
• J JasonL

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

---

Feature Request / Question: Selective Promotion Exclusion During App Deployment
• J JasonL

  Hi, thanks for the detailed report. At the moment, there isn’t a per-promotion exclusion toggle for deployments; the currently recommended way is to keep Preserve Products+Pricing & Promotions in the target environment. Your request for selective promotion exclusion makes sense. I’ll pass this along as a feature request for the team to consider.

---

Two Questions: Follow System & Referral Rewards
• J JasonL

  Hi @gyutaelee,

  1. For one-way follow: brainCloud doesn’t have a built-in one-way “follow” graph, so you’ll need to implement your own follower/following system using one of the user data mechanisms (e.g. global or entity data) to track who follows whom. This keeps it independent of the Friends API, which is designed around mutual relationships. GetPresenceOfUsers() works with any valid profile IDs, it does not require a Friend relationship between the players to return presence info.

  2. For the referral rewards question: I’m going to forward this to our team to review the best server-side approach for triggering rewards for both the referrer and referee once the milestone (like reaching level 3) is reached.

  Thanks for the detailed explanation of your use cases.

---

The Unreal Engine Bootcamp Suggests Storing The Secret Key In The Game Files
• P Paul Winterhalder

  Thanks @Brad-Hester !

---

New users are never counted — all users appear as Returning Users after launch
• P Paul Winterhalder

  First of all - from what you describe - you don't need to set forceCreate: true in your authentication call - because the account was already previously created via the S2S call.

  Also - since you are creating the accounts via the S2S call, then yes - when you authenticate, newUser will come back as false - since they previously existing (via the S2S call).

  That said - we'll have to look into the analytics of this a bit more. Certainly seems like a mismatch... maybe the "fix" would be to return newUser for any user account that had zero logins... and thus let the analytics take care of themselves based on that.

  I'll put this to our devs. Thanks for raising it.

  Oh - and for Q3 - certainly NOT pre-creating the accounts via S2S would make all this line up correctly.