LLMs.txt directory

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 how the Model is populated, how often each type of data refreshes, what the Model excludes by design, and how to read it correctly.

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.

  • Expect one to two days of lag. Treat same-day data, if visible at all, as partial.

  • Do not schedule reports or alerts that assume a specific refresh hour. Design for the two-day upper bound.

  • When you join several system Models, for example in a custom monitoring Liveboard, assume they may be on different days of the refresh cycle.

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 (26.5.0.cl).

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.

  • Group changes reach the Model the next day. A search that includes Group does not show a user’s rows until the first midnight snapshot after they were added to a group in that Org.

  • Liveboard names for events before February 26, 2026 are NULL. Totals are still correct, but per-Liveboard breakdowns start from that date.

  • Same-day rows can be partial. An early batch may have loaded while a later batch is still queued.

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

user id = '<guid>' ts query start time = yesterday queries

All queries by one user on one day, filtered by GUID so the result is the same in every Org.

user org queries ts query start time last 30 days

Query volume per user per Org. The basic adoption view.

user group org queries ts query start time last 7 days

The same view broken down by Group. Users with no group in the Org do not appear; remove Group to see them.

object name object type = 'LIVEBOARD' impressions active users ts query start time monthly

Monthly usage per Liveboard. Names before February 26, 2026 are NULL.

connection is billable is system queries credits ts query start time monthly

How rows are classified and which connections drive credit consumption.

  • A user whose only activity was on TS: BI Server or TS: AI and BI Stats legitimately shows zero rows. Those searches run through the Metrics Connection and are excluded (see What the Model excludes by design).

  • The same GUID identifies a user in every Org. User names and emails can resolve differently in search, so prefer User ID when a count is disputed.

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 = invalid and must be filtered out for reporting

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_export covers 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).

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.