Surfaces
Rego Analytics
Registration counts, tier demand, add-on demand, and registration risk signals.
First created Last updated
Overview
Rego Analytics is the demand map for an event. It does not change registrations by itself. It reads the event’s registration, prefill, upgrade, refund, waitlist, tier, and add-on records so an event lead can understand what people are trying to attend, what they have already completed, and which parts of the registration setup may need attention.
Use this page before changing capacity, opening more slots, ordering physical items, changing add-on availability, or reporting registration progress. The counts are useful because they separate early interest from completed registrations and separate live demand from refund or waitlist movement.
Dashboard route
/ems/manage/rego-analytics?id=:eventId
Page header and event context
The page loads the event title, event date range, and timezone from the selected event. If the page cannot find an event id in the URL, it stops with a missing event message instead of showing stale data from another event.
The header context matters because the same dashboard user may move between several events. Always confirm the title and date before sharing numbers with event leads.
Overview chips
| Chip | What it means | How to read it |
|---|---|---|
| Event | The public event name used for the analytics response. | Confirms that the page is reading the expected event. |
| Tracked tiers | Number of registration tiers included in the tier table. | If this is lower than expected, check Rego Config before trusting tier demand. |
| Tracked add-ons | Number of add-ons included in the add-on table. | If an add-on is missing, confirm that it exists and is active in registration setup. |
| Draft signal | Count of saved prefills. | Shows early intent before a person completes a registration. Prefills are not the same as confirmed registrations. |
Summary cards
| Card | What it counts | Why it matters |
|---|---|---|
| Saved prefills | Saved draft registration forms before actual registration opens or before the attendee completes the full flow. | A large prefill count can signal expected demand, but it should not be treated as committed attendance. |
| Completed regos | Successful attendee registrations, excluding cancelled and rejected rows. | This is the main operational count for attendance planning, access, and communications. |
| Finalized upgrades | Upgrade requests that completed the live upgrade flow. | This shows how many people have moved into a different tier or package after initial registration. |
| Approved refunds | Refund requests approved against attendee registrations. | This helps explain why capacity, paid counts, and finance totals may move down. |
| Waitlisted | Current waitlist rows, excluding withdrawn entries. | This indicates demand that could convert if slots open or if staff manually process offers. |
Tier table
The tier table breaks the same signals down by registration tier.
| Column | What it shows | Use it when |
|---|---|---|
| Tier | The registration tier name. | You need to identify which audience or package is creating demand. |
| Prefills | Draft interest for that tier. | You are forecasting demand before completed registrations catch up. |
| Regos | Completed registrations currently counted for that tier. | You are checking capacity, badge counts, check-in planning, or communications audiences. |
| Upgrades | Completed upgrade movement into or through that tier. | You are checking whether tier changes are affecting capacity or product planning. |
| Refunds | Approved refund activity tied to that tier. | You are explaining count reductions or finance movement. |
| Waitlist | Active waitlist rows for that tier. | You are deciding whether to process waitlist offers or increase capacity. |
If the table says no active registration tiers are configured, the event may not have registration products ready yet. Check Rego Config before treating that as no demand.
Add-on table
The add-on table tracks optional items and services selected through registration and upgrade flows.
| Column | What it shows | Use it when |
|---|---|---|
| Add-on | The add-on name. | You need to identify the physical item, service, or entitlement being requested. |
| Prefills | Draft selections before the registration is completed. | Useful for early supply planning, but not final stock commitment. |
| Regos | Add-on selections attached to completed registrations. | Use this for production and fulfillment planning. |
| Upgrades | Add-ons added through upgrade activity. | Use this to catch demand that did not exist during initial registration. |
| Refund removals | Add-ons removed through approved refund flows. | Use this to avoid overcounting demand after removals. |
Analytics note
The page displays a combined note from the analytics response explaining the prefill and registration interpretation. It also reminds staff that inventory limits still come from logistics tracking. This is important because a registration add-on count tells you what people selected, while Inventory Tracking tells you what stock exists, what has been claimed, and what can be sold through POS.
Related actions
Use Regos when a count needs attendee-level investigation. Use Waitlist when the waitlist number needs action. Use Upgrades and Refunds when movement is caused by post-registration changes. Use Inventory Analytics when add-on counts need to be compared against physical stock.
Common mistakes
Do not treat prefills as completed attendees. Do not order physical stock from add-on analytics alone without checking existing inventory and pending claim counts. Do not use tier totals as proof for a specific attendee problem; open the attendee’s actual registration record before changing anything.