Databricks is the product-analytics, data-pipeline, and warehouse-telemetry layer. It complements Datadog. Datadog is the *infra/runtime* view, Databricks is the
-**Silent instrumentation changes.** A step function in event volume may mean a new event started being logged, not that user behavior changed. Check for instrumentation PRs in the same window before reading the ramp as a feature-launch signal.
-**Schema drift.** Event properties evolve. A column on the typed dbt model today may not have existed when the target was written. Older data may carry the property only inside raw
-**Company-specific tables.** Experiment, feature-flag, billing, and usage tables vary. Reporting a result from a table whose existence you never confirmed is a classic failure mode. Probe with
- Relevance + strength: direct / circumstantial / weak
*
product/data
*
view (what users did, which experiments ran, how feature usage evolved, where a threshold constant came from).
`
your_warehouse.events.analytics_track_event
`
(raw) and typed, deduplicated per-event dbt models in
`
<your_analytics_db>.<schema>.<table>
`
. User behavior: feature invocations, clicks, accepts/rejects, submissions, client-reported errors.
`
your_warehouse.events.usage_event
`
/
`
<your_analytics_db>.<schema>.stg_usage_events
`
,
`
your_warehouse.events.raw_model_event
`
/
`
<your_analytics_db>.<schema>.stg_raw_model_events
`
. For cost- or volume-driven decisions.
**
Schema is company-specific.
**
Probe with
`
SHOW TABLES
`
before assuming names.
`
system.query.history
`
,
`
system.compute.warehouses
`
,
`
system.billing.*
`
,
`
system.access.audit
`
. Answer "was this query expensive?", "how often did anyone run this?", "when did warehouse load spike?"
`
<your_analytics_db>.<schema>
`
reveal what pipelines depend on a table/field. Upstream changes frequently motivate consumer-code changes.
**
Not queryable via the SQL MCP.
**
If you suspect the rationale lives in a notebook, name it as a gap.
`
poll_sql_result
`
rather than re-running.
LIKE
'
*<keyword>*
'
;
.stg_
<
event
>
;
_timestamp
`
(events) or
`
start_time
`
(
`
system.query.history
`
) with a window bracketing the ship date, typically ~30 days before and after, wider only for strong reason.
`
is deduplicated, typed, and liquid-clustered.
`
your_warehouse.events.analytics_track_event
`
has duplicates and untyped
`
properties_json
`
. Model-name pattern:
`
stg_<source>_<event_name_with_underscores>
`
, where
`
<source>
`
is
`
app
`
,
`
backend
`
,
`
website
`
, or
`
cli
`
. Confirm the exact model name with
`
SHOW TABLES
`
when the pattern alone doesn't resolve it. Drop to the raw table only when there's no dbt model yet, or you need events from inside the dbt refresh lag.
`
round-trip):
`
_auth_id
`
,
`
_request_id
`
,
`
event_name
`
. Standard on every model
`
properties_size_bytes
`
, …)
`
context_country
`
,
`
context_client_os
`
. Pre-extracted client context
`
stg_*
`
model across a ±30d window around the PR merge. A step function from zero to steady volume within a day or two of the merge is strong circumstantial evidence the PR launched the feature. A decay to zero suggests a deprecation or deletion.
`
properties_<name>
`
column in the 14 days
*
before
*
the PR. A p99 that matches the target's threshold constant suggests the number was chosen from data.
`
SHOW TABLES ... LIKE '*experiment*'
`
to find the exposure table, then pull exposure counts by variant for the relevant flag key near the PR date.
`
system.query.history
`
filtered by
`
statement_text ILIKE '%<table_or_symbol>%'
`
with a tight
`
start_time
`
window surfaces the expensive queries that likely motivated the change (sort by
`
total_duration_ms
`
or aggregate
`
SUM(read_bytes)
`
,
`
COUNT(*)
`
).
`
<your_analytics_db>.<schema>
`
model, the model's own git history (in this repo) often carries the rationale. Hand that lead back to the git investigator rather than chasing it yourself.
*
because
*
of it. Pair with a PR/commit citation from the git investigator before claiming causation.
`
properties_json
`
.
`
<your_analytics_db>.<schema>.*
`
is rebuilt on a schedule (often hourly/daily). For events from the last few hours, fall back to
`
your_warehouse.events.*
`
and deduplicate by
`
_id
`
.
`
SHOW TABLES
`
/
`
DESCRIBE TABLE
`
first.
*
gap
*
, not a null result. Name it explicitly so the synthesizer doesn't read "no results" as "no activity."