Question about timing for newly deployed Automated Promotions

[gyutaelee]

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.

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