bitHeads group

JasonL

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

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.

JasonL

Hi @gyutaelee,

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.
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.

Paul Winterhalder

Thanks @Brad-Hester !

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.

Paul Winterhalder

Hi - we highly recommend that you use CachePurchasePayloadContext() in all cases. brainCloud will attempt to do a best effort reconstruction of the product and price - but if you start using appStore IAP ids across products than all bets are off. We strongly recommend you add the payload cache in all cases - even for your Apple case that seems to be working so far.

Paul Winterhalder

Question 1

Let me clarify how this is normally handled.

The client app gets a list of the available items for purchase by calling GetSalesInventory(). That call take into account who the user is, what segments they are in, etc. to determine which Cash Products to return in that call.

So if you want to use segments to determine who can purchase an item, you would normally:

Set the item as "Not for Sale" as it's default price
Then in the segmented Promotions, you set the sale (in this case "Regular") price.

In that way - people normally cannot buy the product - but it the user is in the segment covered by the promotion - it WILL appear at what you call the "regular price" for that user when they call GetSalesInventory().

Do you get how this does what you are asking for?

Question 2 - How is promotionId to be passed.

The promotion is automatically taken into account when calling GetSalesInventory(). The trick is to still know a promotion is involved when we are processing the purchase receipt. That is accomplished by caching the new "payload" field.

So the client should:

Call GetSalesInventory() to determine what products to show to the user
Bring up their store UI so the user can view things. Probably involves calling the platform's store APIs to get localized prices of everything.
When the user selects an item to purchase, the client app world:
- Call AppStore.CachePurchasePayloadContext() with the "payload" field that was associated with the item the user has chosen.
- then call the platform's appstore api to initiate the purchase.

Then when brainCloud is processing the purchase it will retrieve the cached "payload" information - which includes information about the promotionId that was involved (if there was one).

So note - in this flow you don't really NEED to call GetEligiblePromotions() - though that can be handy if you need to use that to show some banners in your store or something.

Regarding counting of sandbox purchases - I don't think we include those in the stats. We record the purchase so that you can verify that it is happening end-to-end, but we now keep those totals out of the stats.

I hope that helps!

JasonL

Did you call CachePurchasePayloadContext() with the promotionId before calling verifyPurchase() ? That’s the piece that passes the promotion ID through and should trigger an increase in the maxPurchases counter.

Paul Winterhalder

Hi - I'm probably missing the subtleties of your use case.

But in your scenario, what folks would normally do is:

Set the product as NOT FOR SALE by default.
Then have Promotion set it as AVAILABLE at the STANDARD price point.

Is there a reason that you don't set the product as NOT FOR SALE initially?

JasonL

If your promotion is for a cash product and the promotional product is set to Not for Sale, you need to complete the flow by calling verifyPurchase in brainCloud with the purchasePayload from the store.

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.

Also make sure you set maxPurchases on the promotion configuration page so the system knows when to stop returning that promotion for the user.

As for your feature request to allow promotions without requiring a discount, I will forward this to our team for review.

bitHeads

Posts

Member List