Thank you for your kind response.

Hello BrainCloud team,

I previously posted a question about when the timer starts for users who already meet the conditions of a newly deployed Automated Promotion.

After testing this again, we found that if a user already satisfies the Promotion conditions, the Promotion duration appears to start counting from the deployment time, even if the user does not log in. In other words, the Promotion timer seems to be based on backend timing, regardless of whether the client has connected.

Our desired behavior is that, for offers such as starter packages, the Promotion duration should start only after the user actually logs in. For example, even if a user already meets the conditions, we would like the Promotion to remain active for 24 hours, or for the configured duration, starting from the user’s first login after the Promotion is deployed.

The solution we are currently considering is to refresh or reset the Promotion duration from the client when the user logs in. However, based on what we have checked so far, there does not seem to be an API available for this.

Is there any recommended way to support this use case with Automated Promotions?
If there is a better approach than refreshing or resetting the Promotion duration from the client, we would appreciate your guidance.

Thank you for your help.

@Paul-Winterhalder , could you please respond to @noah 's inquiry?

Thanks for the reply.

I checked the Deployment settings and tested the behavior, but it looks like there is currently no option to prevent Promotions from being overwritten during deployment.

The available “Do Not overwrite product/pricing information” option does not seem to apply to Promotions.

Thanks again for checking this.

Thank you for your kind response as always.
Have a great day!

Hello,

We're currently using the Deployment feature to propagate configuration from our dev environment to staging and production. We noticed that the deployment options allow us to exclude certain categories (e.g., Item Catalog, Leaderboards, Global Entities), which is very helpful.

However, we ran into an issue: a "Remove Ads" promotion that only exists in our dev environment was accidentally deployed to staging, and it immediately triggered a popup for users because the promotion conditions were met right away.

We'd like to ask:

1. Is there currently any way to exclude specific promotions (by name or ID) from a deployment, similar to how individual Custom Entities can be controlled per-record?

2. If this is not currently supported, would it be possible to add a per-promotion deployment toggle — similar to the Custom Entities behavior — as a feature request?

As a workaround, we're manually deleting the unwanted promotion from staging/production after each deployment, but this is error-prone and easy to miss.

Thank you!

Hi BrainCloud team, we have two questions about features we're trying to build.

1. One-Way Follow

We want Player A to follow Player B, but B doesn't have to follow back.

The Friend API requires both players to agree, so it doesn't work for us.
Is there a BrainCloud API designed for one-way follow relationships?

Also — can GetPresenceOfUsers(profileIds[]) fetch profile data for any player,
or does a Friend relationship need to exist first?

2. Referral Rewards for Both Players

Our referral flow:

1. Player A shares their referral code
2. Player B enters the code
3. When B reaches level 3, both A and B receive a diamond reward

The challenge is rewarding A (the referrer). We store A's profile ID in a
Custom Entity when B registers the code, so we always know who referred whom.

Two questions:

a) Does BrainCloud support running a CloudCode script when a Milestone is
completed? If yes, we could use a Milestone to reward B automatically at
level 3, and use that script to look up A's profile ID and reward A as well —
no client-side trigger needed.

b) If not, is there any other server-side mechanism in BrainCloud that can
reward a different player when a specific event occurs?

Thanks!

Thank you for your helpful response. I will proceed as you suggested.

Thank you for your response.

How will I be notified of the development team’s response after I forward this to them? (Will I only be able to find out through the update log later?)

Our Authentication Architecture

We use BrainCloud External Authentication (AuthenticateExternal) as our primary auth method.
We do not use AuthenticateAnonymous at all.

Our flow is:

1. Client calls our own backend server with a device identifier (SystemInfo.deviceUniqueIdentifier)
2. Our server creates/finds an account in our own identity provider using a deterministic anonymous ID derived from the device identifier
3. Our server then calls BrainCloud S2S API (SYS_CREATE_USER_EXTERNAL_AUTH) to create a BrainCloud profile before returning a response to the client
4. Our server returns a user ID and access token to the client
5. The client then calls AuthenticateExternal(userId, accessToken, externalAuthName, forceCreate: true)

The relevant server-side code (Step 3):

public async Task<AccountData> EnsureExternalAccountAsync(string externalId)
{
    var account = await BrainCloudS2SClient.CallAsync<AccountData>(
        "friend", "GET_PROFILE_INFO_FOR_EXTERNAL_AUTH_ID_IF_EXISTS", ...);

    if (string.IsNullOrEmpty(account.BrainCloudProfileId))
    {
        account = await BrainCloudS2SClient.CallAsync<AccountData>(
            "user", "SYS_CREATE_USER_EXTERNAL_AUTH", ...);
    }

    return account;
}

The Problem

Since launch, zero users are counted as New Users in the BrainCloud dashboard.
Every user appears as a Returning User.

Questions

Q1. When AuthenticateExternal is called and the profile already exists (created earlier via SYS_CREATE_USER_EXTERNAL_AUTH S2S), does BrainCloud return "newUser": "false" — even if the user has never called AuthenticateExternal before?

Q2. Does BrainCloud's New User analytics (retention cohorts, DAU new/returning breakdown) rely on the newUser flag from AuthenticateExternal, on the profile's createdAt timestamp, or something else?

Q3. If the S2S pre-creation is the cause, what is the recommended pattern?

• Should we remove the S2S pre-creation and let AuthenticateExternal(forceCreate: true) be the sole profile creator?
• Or is there a way to mark an S2S-created profile so BrainCloud still counts the first AuthenticateExternal call as a New User event?

Thank you for the responses. Based on the discussion, we've implemented the following:

• Product default price: standard App Store price
• Promotion price override: "Not for Sale" (priceId: -2) — workaround to pass console validation requiring a price difference
• Purchase verification: server-to-server (S2S) VERIFY_PURCHASE, no explicit promotionId in the request
• Promotion gating: via GetEligiblePromotions() on the client

We're observing that the purchased counter increments correctly after purchase, and the promotion does not reappear after app restart.

We believe the reason automatic attribution works without calling CachePurchasePayloadContext() is that we set Apple's appAccountToken (a UUID embedded in the StoreKit 2 signed transaction) to the brainCloud profileId before initiating the native IAP purchase. When brainCloud receives the JWS receipt during S2S VERIFY_PURCHASE, it can extract the appAccountToken, identify the user, look up their active promotions, and increment the counter automatically.

Two quick questions:

1. Is this understanding correct — does brainCloud use the appAccountToken in the StoreKit 2 JWS to perform automatic promotion attribution, making CachePurchasePayloadContext() unnecessary in this flow?
2. When we extend this to Android (Google Play), there is no equivalent of appAccountToken in the receipt. What is the recommended approach to ensure promotion attribution works correctly in that case — should we call CachePurchasePayloadContext() before the purchase, or is there another mechanism?

Following up with an additional question related to this thread:

We're testing the promotion and purchase flow in the iOS Sandbox environment, and we're not seeing the Purchase Count increment after a successful sandbox purchase — even when calling verifyPurchase with the promotionId included.

Is purchase count tracking supported in the iOS Sandbox environment, or is it only tracked for real (production) purchases?

If sandbox purchases are not counted, is there a recommended way to test the maxPurchases limit before going to production?

Any guidance would be appreciated. Thank you!

Thank you for the responses. I'd like to clarify my situation and ask more specific follow-up questions.

My current setup:

• Product default price: Standard price (normally available for purchase)
• Promotion price override: Not for Sale (priceId: -2)
  • Reason: The console requires the promotion price to differ from the default price, so this is used as a workaround to pass validation
• Actual purchase price: Provided directly by Apple App Store / Google Play
  In other words, I'm using promotions not to change the price, but to control access for specific user segments and track purchase counts.

Question 1: Is using "Not for Sale" as a promotion price override a supported pattern?

With the setup described above — where the promotion price override is set to Not for Sale (priceId: -2) — does BrainCloud's purchase counter and maxPurchases limit work correctly? Is this a supported use case?

Question 2: How exactly should promotionId be passed during purchase?

JasonL mentioned:

"As long as that payload contains the promotionId you received from GetEligiblePromotions, the promotion will be correctly attributed and the server-side flow will reach the counter increment logic."

However, in a standard IAP flow:

1. Call GetEligiblePromotions → receive promotionId
2. User completes payment on Apple App Store / Google Play → store returns a receipt (binary/base64 data generated by Apple/Google)
3. Call AppStoreVerifyPurchase (or equivalent) with that receipt
   The receipt from step 2 is generated by Apple/Google — I cannot inject custom fields like promotionId into it.

So my question is: in which parameter and in what format should promotionId be passed in the verifyPurchase call? A concrete example of the API call with promotionId correctly included would be extremely helpful.

Summary:

• Question

1. Is setting the promotion price override to Not for Sale (priceId: -2) a supported pattern, and will the purchase counter work correctly?
2. In the verifyPurchase API call, which parameter carries the promotionId, and in what format?

Hi BrainCloud team,

We're implementing Automated Promotions to gate specific products behind user segments and time windows — but without any price discount. The goal is simply to make a product available (at its regular App Store price) for a limited time to eligible users, not to offer it at a reduced price.

The console constraint we ran into:

When setting up a Cash Product in an Automated Promotion, the dashboard enforces that the promotional price must differ from the default price. Since we don't intend to offer a discount, we can't configure a valid second price tier.

Our current workaround:

We set the promotional price to "Not for Sale" (priceId: -2). This lets us pass validation and receive the itemId in the GetEligiblePromotions response, which we use to look up the product. The actual purchase goes through the App Store at the product's standard list price — our client ignores the priceId and referencePrice entirely.

Our question:

With this "Not for Sale" workaround, does the Promotion's purchased counter increment correctly when a successful IAP purchase is verified via verifyPurchase?

We're relying on purchased >= maxPurchases to prevent the promotion from re-appearing after a user has already bought the product. If the counter doesn't increment in this setup, we need to handle purchase tracking ourselves.

Feature request:

Is there a plan to support promotions that sell products at their default/list price without requiring a discounted price tier? For use cases like timed exclusives or segment-gated access (rather than sales), this would remove the need for workarounds.

Thanks in advance!

It's been resolved. Thank you for your response!

We have an Automated Promotion tied to a segment condition: experienceLevel >= 4.

Our flow is:

1. Server calls incrementExperiencePoints() via CloudCode → player reaches level 4
2. Client immediately calls GetEligiblePromotions (client-side CAPI)
3. The promotion is not returned

However, if the player restarts the app and logs in again, GetEligiblePromotions does return the promotion correctly.

Questions:

1. Does GetEligiblePromotions evaluate segment conditions in real-time against current player state, or does it rely on a cached/pre-calculated segment membership?
2. If there is a delay between incrementExperiencePoints and when the promotion becomes available via GetEligiblePromotions, how long is that delay typically?
3. Is there a way to force immediate promotion triggering when a player's level changes mid-session?