TS: AI and BI Stats
TS: AI and BI Stats is the system Model that reports product usage, adoption, and credit consumption across all Orgs on a cluster. This page explains why to use the Model, how it is populated, how often each type of data refreshes, what it excludes by design, and how to read it correctly.
The Model is enabled by default. The AI and BI System Liveboard is built on it.
Why use this Model
The TS: AI and BI Stats Model moves system Liveboard reporting to the more robust Query Stats data source. It lets you build your own Answers and Liveboards on detailed product usage, using query performance metrics for every query run against your external databases. The same data source is used for billing.
- Usage translation
-
The Model links query activity directly to business context, capturing the creation of Answers, Liveboards, and Models, and providing a clear lineage from user action to business outcome.
- Broader tracking
-
It covers more user actions, including Spotter interactions, index queries, and Analyst Studio activities, for a more complete view of product engagement and adoption.
- Reliable data
-
Query Stats delivers a stable and trusted data pipeline, minimizing disruptions and ensuring consistent reporting.
- Improved accuracy
-
By tying metrics directly to query logs, the Model removes ambiguity and supports precise, fact-based reporting.
- Audit trail
-
You can validate ThoughtSpot usage data against your own databases, which provides transparency and prevents issues like double counting.
- Data quality
-
Query Stats addresses earlier data quality issues, such as the incorrect association of Models and Liveboards, by mapping product usage more accurately.
- Group privileges
-
The Model includes privilege information for each group, giving administrators a single place to review what each group is permitted to do in ThoughtSpot.
How the Model is populated
The Model is built on Query Stats. Every time ThoughtSpot runs a query against your cloud data warehouse (CDW), one row is recorded. That row captures the user, the object (Liveboard, Answer, or Spotter conversation), the connection, latency, and credits. That row is joined to daily snapshots of metadata (object names and types), group membership, and Analyst Studio activity.
The Model is populated by a telemetry pipeline, not read live from the cluster. Each stage adds time, which is why the Model is a day or two behind, and why a number visible in the Admin Console can differ from the Model on the same day.
Pipeline stages
| Stage | What happens | Cadence |
|---|---|---|
1. Collection on the cluster |
Query stats and request logs are gathered continuously. Metadata reports (Liveboards, Answers, users, groups) are generated once a day because they scan the cluster’s metadata store. |
Minutes to hourly for stats; once a day for metadata |
2. Upload |
Files land in a per-cluster landing zone in cloud storage. |
As generated |
3. Processing |
An orchestrated pipeline picks up files, queues them, and loads them for all clusters. |
Every 2 hours |
4. Metrics store |
Loaded tables are read by TS: AI and BI Stats, TS: BI Server, and the other system Models on the cluster. |
As processing completes |
The D-1 to D-2 rule
Activity appears in the Model between one and two days after it happens. The raw query stats are polled frequently, but the final rows depend on the daily metadata reports, and the loading pipeline serves every cluster in a shared queue. There is no fixed refresh hour, and the schedule cannot be changed for an individual cluster.
|
Source of truth
For usage, adoption, and credit reporting, TS: AI and BI Stats is the trusted source. It is derived from Query Stats and filters out ThoughtSpot’s own system activity. TS: BI Server remains available for request-level questions (see TS: AI and BI Stats vs TS: BI Server) and is not deprecated. Only the older Product Usage system Model is deprecated.
Refresh cadence by data type
Different columns come from different collectors, so parts of a single row can be fresher than others. A query from yesterday can appear with today’s group membership still missing.
| Data | Columns it feeds | Collected | Visible in Model | Notes |
|---|---|---|---|---|
Query stats (each CDW query) |
User, Object, Connection, latency, credits, Queries, Impressions |
Continuously |
D-1 to D-2 |
The primary fact table. A row exists only when a query was fired. |
Metadata reports (Liveboards, Answers, Models, users) |
Object Name, Object Type, Model |
Once a day |
Next day |
Liveboard Name is reliable only for events after February 26, 2026; earlier rows show NULL. |
Group and group membership |
Group, Group ID, Group Privileges |
Snapshot at midnight (cluster time) |
Next day |
A group created, or a user added, at 5 PM is not visible until the following day’s snapshot. |
Analyst Studio activity |
Analyst Studio credits, dataset refreshes |
Daily |
Next day |
Joined into the same Model. |
Request logs (every backend API call) |
TS: BI Server only |
Continuously, in batches |
D-1 to D-2, often sooner |
Not part of AI and BI Stats; shown for comparison. |
|
What the Model excludes by design
The Model shows consumption of your own data warehouse. Several kinds of activity are intentionally absent. None of these are defects.
| Excluded or blank | Why | What you see |
|---|---|---|
Queries through ThoughtSpot system connections: Metrics Connection, TAP, Demo |
Browsing the stats Liveboards themselves would otherwise count as CDW usage. The rows are captured but filtered out when the Model reads them. |
A user who spent the day in TS: BI Server or TS: AI and BI Stats shows no rows for that day. |
Non-query actions: login, home page, object lists, downloads that do not fire a query |
Query Stats records CDW queries only. |
Visible in TS: BI Server, absent here. |
Users with no group in the selected Org, when Group is in the search |
Activity is joined to the group-membership snapshot; no membership, no match. |
Rows disappear when Group is added and return when it is removed (see Read the Model correctly). |
Liveboard Name before February 26, 2026 |
Historical metadata gap. |
NULL object names on older rows. |
Model name in some scenarios |
Known limitation. See Model name appears as NULL in query stats. |
NULL in the Model column. |
Provisioned users by Org |
Known limitation: the KPI does not honor the Org filter alone. |
Cluster-wide count regardless of Org filter. Use TS: Provisioned Users for per-Org counts. |
The Is Billable and Is System columns show how each row was classified, and you can add them to any search.
Read the Model correctly
The Model is a join of several snapshot tables, so the columns in a search determine which rows survive. The following four patterns account for most "the numbers look wrong" questions.
- Group
-
Group and Group ID come from the midnight snapshots. Adding Group to a search drops every user who had no group membership in the selected Org at the last snapshot. Using User and Group together is valid; results are simply a day behind group changes.
- User versus User ID
-
The User ID (GUID) is the same across all Orgs on a cluster, so filtering on User ID is the safest approach for cross-Org questions. If a count looks wrong when you search by name or email, re-run the search with the columns named explicitly before assuming data is missing.
- Org
-
Filter on Org or Org ID to scope a search. Cluster administrators can access every Org by product design, so the Model cannot distinguish an "authorized" from an "unauthorized" cluster administrator. To restrict administrators to specific Orgs, use Org administrators, not an alert on this Model.
- Object Type and time columns
-
Object Name mixes Liveboards, Answers, and other objects; always pair it with an Object Type filter. Use TS Query Start Time for query-centric views and User Action Time for action-centric views. The two can fall on different calendar days around midnight.
Example searches
| Search | Returns |
|---|---|
|
All queries by one user on one day, filtered by GUID so the result is the same in every Org. |
|
Query volume per user per Org. The basic adoption view. |
|
The same view broken down by Group. Users with no group in the Org do not appear; remove Group to see them. |
|
Monthly usage per Liveboard. Names before February 26, 2026 are NULL. |
|
How rows are classified and which connections drive credit consumption. |
|
TS: AI and BI Stats vs TS: BI Server
Use TS: AI and BI Stats for usage, adoption, and credit reporting. Use TS: BI Server for questions about individual requests: downloads, the latency of one call, or activity that does not fire a query. Row counts between the two never match, because they count different things.
| TS: AI and BI Stats | TS: BI Server | |
|---|---|---|
Source |
Query Stats joined with metadata, groups, and Analyst Studio |
Backend request logs |
One row is |
One query against your data warehouse |
One backend API request |
Refresh |
D-1 to D-2 |
D-1 to D-2, often a little fresher |
System-connection activity |
Excluded |
Included |
Non-query actions (login, browse, download) |
Excluded |
Included |
Noise |
Low |
High: most rows have User Action = |
Group and Org dimensions |
Both (snapshot-based) |
Org only |
Credits, billable flag, DB latency |
Yes |
No |
URL, response size, HTTP status |
No |
Yes |
Best for |
Adoption, active users, credit consumption, per-object usage, leaderboards |
Request-level audits, download tracking, performance troubleshooting |
When you compare the two, filter TS: BI Server to User Action != invalid and to query-related actions.
Totals still differ, but query-related activity should align directionally.
User actions
The User Action column exists in both Models but means different things.
In TS: AI and BI Stats, it is the action that caused a query (search, Liveboard view, Spotter).
In TS: BI Server, it is a classification of the raw request, and many requests are invalid or blank because they could not be mapped.
For the list of user action codes, see User action code reference.
Downloads and exports
-
Download tracking is a TS: BI Server question, not an AI and BI Stats one.
data_exportcovers Liveboard exports and Answer chart image (PNG) downloads only. -
Answer table downloads (CSV, XLSX, PDF) carry no user action. Find them by filtering URL contains
data/answerbook/export. On those rows, Answer Book Name and Answer Book GUID are blank. See Tracking Answer downloads. -
Security audit logs do not record downloads or exports.
Frequently asked questions
| Question | Answer |
|---|---|
Data for yesterday is missing. |
Expected. The Model is D-1 to D-2; check again after two days. |
My activity is missing, but I used ThoughtSpot all day. |
If the activity was on the stats Liveboards or system Models, it ran through the Metrics Connection and is excluded. If it was login, browsing, or downloads, no query was fired. |
Adding Group makes rows disappear. |
The user had no group in that Org at the last midnight snapshot. Wait a day after group changes, or remove Group from the search. |
Can the refresh time be changed? |
No. There is no fixed time, and it is not configurable. Design reports for a two-day lag. |
Why don’t AI and BI Stats and BI Server match? |
Different sources and units (queries vs requests). They are not designed to reconcile. |
Can we alert when an unauthorized user is active in an Org? |
Define "unauthorized" first. Cluster administrators can access every Org by design, so an alert on this Model cannot enforce it; use Org administrators instead. |
Which Model is the source of truth for usage? |
TS: AI and BI Stats. Use TS: BI Server only for request-level questions. |
Can I see which table a download came from? |
No. Neither Model records the underlying data source of an export, only the object (Liveboard or Answer). |
Troubleshooting
Model name appears as NULL in query stats
Symptom: The TS: AI and BI Stats Model shows NULL for Model names in query stats, and no Model details are displayed.
Cause: This can occur in the following cases:
-
A Liveboard or Answer has been shared with a user who does not have access to the underlying Model. In this case, Model name fields are empty by design.
-
The Answer was edited in a way that changed the query object from a Model to a table. This is expected behavior.
-
The system cannot resolve the Model reference from the query specification. This is a known issue addressed in ThoughtSpot Cloud 26.7.0.cl.
-
If multiple models are selected for a single object.
Resolution:
-
Verify that the user viewing the Liveboard has access to the underlying TS: AI and BI Stats Model.
-
If Model names are missing for a specific Answer, check whether the Answer references a Model or a table.
-
If the issue persists after confirming access, it may be the known issue fixed in ThoughtSpot Cloud 26.7.0.cl. Contact ThoughtSpot support if you are on an affected release.
Get help
If the Model appears empty, returns data older than the refresh windows described on this page, or a column named here is not present, contact ThoughtSpot support and include the cluster name, the Model name, the user GUID if the issue is user-specific, and the date range.