> For the complete documentation index, see [llms.txt](https://kbase.whitelabel-loyalty.com/product/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kbase.whitelabel-loyalty.com/product/loyalty-engine/audiences/audience-refresh-rates.md). # Audience refresh rates An audience’s refresh rate dictates how often it updates to evaluate which users meet its criteria and should be included. * **Initial assessment:** When an audience is first created, all user profiles in your loyalty tenant are evaluated against the criteria, and matching users are added. * **Ongoing refreshes:** After the initial assessment, the audience refreshes at the selected interval, ensuring its membership remains up-to-date. {% hint style="info" %} Audience calculations are designed to segment users based on historical activity and other data, rather than occurring in real-time. * **Batch calculations:** Initial, manual or daily re-calculations can take several hours to complete. * **Reactive calculations:** Typically near-instant, processing within a few minutes during normal traffic. However, during peak traffic, processing may take up to several hours. {% endhint %}

Audience refresh rates can be found in the create and edit audience screens of the Loyalty Console

*** ## Calculate on User Registration (Sync)  Each audience has a Calculate on User Registration toggle, found alongside the refresh rate settings in the create and edit audience screens. **When disabled (default)**: New user registrations are processed asynchronously. The user’s eligibility for the audience is evaluated shortly after their profile is created, and they will be added to any matching audiences within a few minutes. This is suitable for most audiences. **When enabled**: The user’s eligibility for the audience is evaluated synchronously — as part of the registration request itself. The user will be a member of any matching audiences the moment their registration completes. * **Use case**: Audiences that are critical to the initial user experience, such as those controlling which program elements are visible or which earning mechanisms are active from the start. * **Example**: An audience that determines a user’s membership level at registration, where the level controls which rewards and content are displayed. {% hint style="warning" %} Enable this setting only for audiences where immediate membership is essential to program functionality. Each synchronous audience calculation adds processing time to the registration request. Enabling it on too many audiences can slow down registration and lead to timeouts. For most audiences, the default asynchronous behaviour is recommended. {% endhint %} *** ## Refresh rates ### Manual With a manual refresh rate, the audience must be **refreshed manually using the “Refresh” button** on the audience’s info page in the Loyalty Console. This triggers a full reassessment of all user profiles, similar to the daily refresh process, which may take a few hours. * **Use case:** When the audience is used for reporting and doesn’t affect the day-to-day loyalty program behaviour. * **Example:** Audiences used solely for reporting purposes that don’t need constant updates. ### Daily With a daily refresh rate, **the entire audience is recalculated once per day,** starting at around midnight in the [tenant’s configured timezone](/product/loyalty-engine/loyalty-console.md#scheduling-timezones). All user profiles are reassessed, adding or removing users based on the criteria. This process may take a few hours. * **Use case:** When eligibility is determined by non-event-based criteria. * **Example:** Users whose birthday is today. The audience refreshes daily to identify users with a birthday on the current day. ### Reactive With a reactive refresh rate, an individual user’s eligibility is **reassessed every time an event is reported in their event stream**. As mentioned above, this is typically near-instant, processing within a few minutes during normal traffic. However, during peak traffic, processing may take up to several hours. * **Use case:** When eligibility is determined by event-based criteria. * **Example:** Users who have purchased a reward. The audience refreshes within seconds of the reward purchase being recorded. When an event is triggered, the Loyalty Engine processes it by firing all configured reactions first. After these reactions have completed, the user’s reactive audience memberships are recalculated. This sequence ensures that any changes in audience eligibility (based on the event) take effect only after the **event *****and***** its reactions** have been fully processed. This order is essential to ensure accurate processing, as it prevents premature audience updates that might affect other reactions tied to the current event. ### Daily Reactive The daily reactive refresh rate **combines both daily and reactive refresh rates**. The entire audience refreshes daily, and individual user membership is reassessed each time an event is reported in their stream. * **Use case:** When eligibility is based on both event and non-event-based criteria. * **Example:** Users who haven’t purchased a reward in the last 7 days. The audience refreshes as soon as a reward is purchased and also daily to check when 7 days have passed since the last purchase. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://kbase.whitelabel-loyalty.com/product/loyalty-engine/audiences/audience-refresh-rates.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.