/deepline-analytics

name: deepline-analytics
description: "Use this skill when answering business analytics, RevOps, GTM metric, pipeline, revenue, funnel, customer, or warehouse questions with Deepline. Triggers on phrases like 'query Snowflake', 'analyze pipeline', 'total ACV', 'break down by quarter', 'use the semantic layer', 'run a semantic query', or any use of snowflake_get_semantic_layer / snowflake_run_semantic_query. Skip prospecting, enrichment, contact finding, outbound, or personalization workflows; use deepline-gtm for those."
disable-model-invocation: false

Deepline Analytics

Quick Start

npm install -g deepline
deepline -h

CLI resolution

Run `deepline` when it is available. If the shell reports that command is missing, use `<workspace-root>/.deepline/runtime/bin/deepline` (or the npm-created `.cmd` shim on Windows). If neither exists, follow `https://code.deepline.com/INSTALL.md` to set up Deepline.

Use this skill to answer customer analytics questions through Deepline's warehouse and semantic-layer tools. The goal is to preserve the customer's business definitions by starting from the semantic layer, validating the query path, and reporting exactly what metric definitions and filters were used.

Before You Start

Use `deepline-gtm` instead for prospecting, enrichment, contact finding, outbound sequencing, personalization, or row-by-row lead/account research. Analytics questions ask about existing customer data: revenue, pipeline, funnel, conversion, retention, usage, calls, accounts, opportunities, or warehouse tables.

If Snowflake credentials or a semantic layer are missing, stop and report the setup blocker. Do not guess table names or fall straight to raw SQL; both usually produce incorrect business definitions.

Deepline Internal Analytics Sources

For Deepline's own product, usage, and operational analytics, choose the source by question. Do not assume every Snowflake metric is dbt-modeled.

| Source | Tables / dataset | Use for | Caveats | | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | | Convex replica raw ledger | `AERO_DB.CONVEX_RAW.*`, especially `PLAY_RUNS` and `INGESTION_PLANES` | Persisted app state, play-run status, prebuilt/custom play identity, customer database inventory/state | Authoritative historically, but can lag same-day activity. Raw tables may include sensitive app/customer fields. | | Convex replica reporting views | `AERO_DB.CONVEX.USAGE_EVENTS`, `BA_USER`, `BA_MEMBER` | Tool/enrich calls, Deepline credits, user/org identity | `USAGE_EVENTS` is the primitive billing/usage ledger. Never expose provider spend. Some views are published selectively; verify freshness first. | | Axiom production logs | Dataset `vercel` | Real-time play/run failures, CLI outcomes, provider/tool errors, log-message failure classes | Log-shaped. Deduplicate run/request ids and compare against Snowflake when accuracy matters. | | RudderStack product events | `RUDDERSTACK.EVENTS.*` (`TRACKS`, `PAGES`, `IDENTIFIES`, event tables) | Product journey, page views, signup/auth lifecycle, attribution | Not the operational ledger. Some browser events may be missing from Snowflake. | | dbt / transformed analytics marts | `AERO_DB.ANALYTICS*` schemas, for example `ANALYTICS.FCT_CUSTOMER_JOURNEY`, `DIM_ACCOUNT`, `CUSTOMER_STREAM`, and dbt views such as `STG_*` | Modeled business metrics: GTM, customer journey, CRM, TAM | Not the default source for play-runtime health unless a modeled table is explicitly known to cover it. |

Current product usage dashboard source of truth:

• Play runs: Snowflake `AERO_DB.CONVEX_RAW.PLAY_RUNS` plus Axiom `vercel` logs with `[sdk-cli-observability] kind: 'play_run_completed'` and `[cli-failure-report] failure_kind: 'play_run_failed'`.
• Legacy workflow runs: Snowflake `AERO_DB.CONVEX_RAW.WORKFLOW_RUNS` joined to `AERO_DB.CONVEX_RAW.WORKFLOWS`.
• Tool/enrich calls: Snowflake `AERO_DB.CONVEX.USAGE_EVENTS` plus Axiom `vercel` logs with `[integrations.execute.outcome]`.
• User/org dimensions and internal filters: prefer Snowflake `AERO_DB.CONVEX_RAW.BA_USER` and `AERO_DB.CONVEX_RAW.BA_MEMBER` for freshness; use reporting views only after checking freshness.
• Customer database: Snowflake `AERO_DB.CONVEX.USAGE_EVENTS` for customer-db usage and `AERO_DB.CONVEX_RAW.INGESTION_PLANES` for table/plane inventory.

That dashboard does not use `AERO_DB.ANALYTICS*` dbt/transformed models. If you add dbt-modeled metrics, document the model names, freshness, and grain next to the raw/Axiom parity