Modeling for Search & Spotter

Column names are the first thing ThoughtSpot uses to match a user's typed query to a column. If your backend column is QTY_RETAPP_P and a user types "quantity sold", Search finds nothing. The column name is the semantic bridge between business language and database schema.

Spotter reads all column names in the model before constructing any query — like reading a schema overview first. Well-named columns let Spotter match user intent to the right column even when the user's phrasing doesn't exactly match. Spotter 3 is fully data-aware and uses names as the primary signal for column selection.

Descriptions surface as a tooltip when users hover a column in Search. They disambiguate columns with similar names and help users understand what they're filtering on — especially important in models with many revenue or date columns that look alike.

Spotter reads descriptions as inline documentation before constructing any query. A good description can encode business rules, calculation notes, and disambiguation guidance that isn't expressible in a column name alone — directly improving query accuracy without any prompting from the user.

Different teams use different words for the same thing — Finance says "Net Sales", Sales says "Revenue", the CEO says "Top Line." Synonyms let all three resolve to the correct column without renaming it. They also catch abbreviations and legacy backend names users may type from memory.

ThoughtSpot infers MEASURE for any numeric column. This is frequently wrong. ZIP codes, order IDs, phone numbers, and product codes are numeric but should never be summed or averaged. Getting Column Type wrong causes incorrect aggregations, bad chart defaults, and Spotter answers that are confidently wrong.

MEASURES are additive by default — meaning ThoughtSpot will SUM them when aggregating across rows. For ratio metrics, percentages, and averages this produces silent, confident wrong answers. A Margin % that sums to 101% across regions will be presented without any warning unless Additive = false is set.

When a user types "Revenue by Region" without specifying SUM or AVERAGE, ThoughtSpot uses the column's default aggregation. Setting this correctly means the most common query pattern returns the right answer with zero extra keywords — and tells Spotter which aggregation to assume when constructing queries autonomously.

Indexing determines whether column values (not just the column name) appear in Search autocomplete as a user types. Without indexing, users must type exact values from memory — no suggestions, no dropdown, high chance of mismatches and zero results.

Spotter uses indexed values to resolve ambiguous user input to actual data values. If a State column is indexed, Spotter can match "Pacific Northwest" to the specific state codes. Without indexing, Spotter must guess — and may generate a WHERE clause with values that don't exist in your data.

Some columns exist to support joins, formula dependencies, or RLS rules — but should never appear in Search. Hidden removes them from autocomplete and suggestions while keeping them fully active in joins and formulas behind the scenes.

Hidden columns are excluded from the schema context Spotter reads before generating queries. This reduces schema noise — a Spotter reasoning over a clean 30-column model performs significantly better than one parsing 80 columns where half are internal plumbing. Hide aggressively: expose only what users actually query.

Controls whether values for a column populate the Search bar dropdown as users type. Only available at the Model level (not Table level). Disable for very high-cardinality columns where suggestions would be overwhelming and slow — transaction IDs, timestamps, free-text fields. Enable for dimensions users commonly filter on.

ThoughtSpot is case-insensitive by default, but some databases are not. Without this setting, ThoughtSpot wraps filter values in LOWER() or UPPER() — which can prevent index usage in Snowflake, Redshift, and BigQuery, causing full table scans on large fact tables. Setting the correct casing eliminates this overhead.

Relative date keywords are resolved against the calendar type assigned to the date column. If your fiscal year starts April 1 but you use Gregorian calendar, "Q1" returns January–March — wrong for every fiscal report. This is the single most common cause of "why is my quarter number off?" questions.

Without Geo Config, ThoughtSpot treats a column named "State" as just another string attribute and defaults to a table or bar chart. With the correct Geo Config type set, Search and Spotter automatically generate geo maps when a location column is referenced — no extra keywords needed from the user.

A chasm trap occurs when two fact tables (Sales and Budget) share a common dimension (Customer) but have no direct join between them. When a user asks "Sales and Budget by Customer", ThoughtSpot must determine which shared dimensions are valid join bridges. Attribution Dimension controls this — set incorrectly it silently inflates or distorts results through row multiplication.

Model Instructions are the single highest-leverage Spotter modeling action. They encode business logic at the model level so every conversation inherits it automatically — no per-user setup, no repeated prompting needed. This is where you capture the "rules everyone knows but no one types" that determine whether Spotter's answers are business-correct or just technically valid SQL.