question

robert avatar image
robert asked

Store Segment Override, delay?

When using segment override for a store, is there any delay before the new store gets returned?

For example:

Statistic - UserLevel

SegmentBeginner = UserLevel == 0
SegmentPro = UserLevel == 1

Lets say a store "Coins" is configured to be overriden with store "CoinsPro" when a user is in segment SegmentPro.

Lets assume this cloud script method:

server.GetStoreItems("Coins") ---> store.StoreID = Coins
server.UpdatePlayerStatistics( UserLevel, 1);
server.GetStoreItems("Coins") ---> store.StoreID = Coins (still returns the old store)

only after a few seconds GetStoreItems returns the override store:
server.GetStoreItems("Coins") ---> store.StoreID = CoinsPro (only new returns the new store)


Is this by design? If so, is there any way to know when the store gets overriden internally so we can display/show the new store correctly? (in our case this is especially required then switching from the First User Time Experience store to the normal store, and switching stores after ranking up, etc..).

Without being able to use a pattern like:

Player completed game
Game calls cloud script to handle game result
Rank statistic is increased
Store configuration is returned (this is more or less random, sometimes the new, sometimes the old is returned)
Game shows new store

It is very complicated to make sure the store displayed is the actual one in use (without periodically triggering an action/server call to check for an updated store)

10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

1 Answer

·
brendan avatar image
brendan answered

The key to understanding PlayStream Rules (like user segmentation or your own custom-defined rules) is to think of it in the context of what's commonly referred to in cloud services as a "serverless" model (which I believe is a silly term, since the whole process is made of servers, but ce la vie). In that model, actions (like setting a statistic) generate events. Those events go to a stream (PlayStream). PlayStream Rules "hook" onto the stream to monitor for the things they're interested in, so that they can take action on them.

In your case, you have a segmentation Rule that when the player's UserLevel hits a certain amount, they are pushed into a user segment that has a store override. When you make the API call to update their VC, that fires the event into the stream, but since we're talking about Cloud Script, your latency is in milliseconds. So the event has been injected into the stream, but because you're immediately querying, the logic to use it to update the user segment hasn't completed yet. Depending on the user's latency, if the calls are all coming from the user's device, that latency may take care of that "wait" time, but it is a good best practice to pause a second before doing something that is dependent on PlayStream having fired a Rule.

To be clear, I would not recommend doing any kind of "sleep" in a Cloud Script. Once the script has updated the statistic, I'd return to the caller so that it can query the store. Or, if the store needs to be queried in a script for some reason (filtering, etc.), have it be a follow-up script the client calls.

4 comments
10 |1200
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

robert avatar image robert commented ·

Thanks, this is exactly how we thought how playfab handles the "change segment event" and the delay comes from. We already prepared to have a delay in the client (something like a match end animation which will introduce an additional artificial delay), but can we be 100% sure that calling cloudscript again after 1 second with GetStoreItems will definitely return the new store in this case already?

0 Likes 0 ·
brendan avatar image brendan robert commented ·

Sorry, no. It will be the case that it'll be updated after a second the majority of the time. However, there may occasionally be delays in the PlayStream system that cause this to be a bit longer. We're continually working to improve PlayStream to prevent those delays, but at least for the near-term, you should assume they can happen.

0 Likes 0 ·
robert avatar image robert brendan commented ·

Hmm, I see.

The problem here is, on Login or after a Match we query the current store and depending on store custom data or store item custom data we build quite a few details about the items and store itself it in the player data. This details (e.g. various logics how to display items, logic which random content an item contains (much more complex than what a drop table allows)) are linked to the store item itself. We need to find any way to make sure that the store and its player data details still match the store which will be used when we call PurchaseItem.


What would be the recommended way to make sure that when we purchase an item which is displayed to the user is still the same as in the current used store? We are aware that a purchase would fail it the price or currency will not match, but in our case the price and currency could be the same whereas the dynamic content could be different already.

Unfortunately at the moment we can not think of any way to archive this. I guess there isn't something like a "Re-evaluate a possible segment change right now" server call? (which would solve all problems)

0 Likes 0 ·
Show more comments

Write an Answer

Hint: Notify or tag a user in this post by typing @username.

Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.