When a component's visibility is configured to target specific segments, changes to a user's segment membership can take over an hour to reflect in what they actually see. This delay makes it impractical to build real-time, segment-driven user journeys.
For example, we attempted to build an onboarding flow where verified customers are shown a modal on first visit. Upon completion, we update a profile field via the API, which moves the user into a different segment — at which point the modal should no longer appear. However, because visibility changes aren't applied promptly, the user continues to see the modal long after their segment has changed, effectively trapping them in a loop.
This is impractical for us for serveral reasons such as:
- User experience degradation - Users who should be seeing onboarding content, upsell prompts, or role-specific guidance will instead see stale or irrelevant components. This undermines any personalisation effort and creates a confusing experience.
- Operational reliability - If we cannot trust segment targeting to update within a reasonable timeframe, it limits the value of segmentation as a feature entirely. We cannot build automated workflows or time-sensitive processes on top of a mechanism with an unpredictable multi-hour delay.
- Compliance and access control - Depending on the content being served, prolonged access to the wrong segment's components could have implications for data handling obligations, particularly if customer-specific documentation, pricing, or account information is exposed to non-customers.
Reducing this propagation time — ideally to near-instant — would unlock segment-based visibility as a tool for building responsive, self-resolving user experiences such as onboarding flows, first-run wizards, and conditional prompts.