Skip to main content
This example walks through a complete, realistic session: you have raw web analytics events landing in Nightshift, and by the end you’ll have clean reusable views, a saved notebook, a KPI dashboard, and a live app your team can open. Every step is a prompt — the agent does the work.

​
The starting point

Say your site’s page-view events land in a table called site_events — one row per event, straight from your tracker: How the data gets there doesn’t matter for this example — a streaming connector, a batch load, or just asking Claude to load a CSV export all end at the same place.

​
Step 1 — Look around

You: What analytics data do I have in Nightshift, and what does it look like?
Claude lists the objects in your warehouse, describes the schema of site_events, and runs a few exploratory queries — row counts, date range, top paths. This is read-only work, so it’s a good first prompt in any session: it grounds the agent in your real schema before anything gets built.

​
Step 2 — Organize it into views

Raw events are the wrong shape for most questions. Ask for the shape you want:
You: Organize this into clean views: daily page views, sessions with duration and entry/exit pages, and a referrer summary. Don’t copy any data — I want views over the raw events.
Claude creates views like:
Views are the key move here. They cost nothing to store, they’re always current as new events land, and they become the shared vocabulary for everything downstream — the next conversation (yours or a teammate’s) starts from daily_pageviews, not from re-deriving it.
Creating tables and views requires the objects:create capability. If Claude is authenticated as you, you have it; a scoped token needs it granted explicitly. See Policies.

​
Step 3 — Save the analysis as a notebook

You: Save the interesting queries from this session as a notebook called “Site traffic — weekly review”.
Claude creates a notebook whose cells hold the SQL — weekly trend, top landing pages, referrer mix, mobile share. Each cell it runs gets its result snapshotted, so the notebook in the console shows both the queries and the numbers as of today. Next week, open it and hit Run all to refresh.

​
Step 4 — Get a dashboard in chat

You: Show me a traffic dashboard for the last 30 days.
Claude renders a live dashboard right in the conversation — KPI tiles for views, sessions, and mobile share; a trend line; ranked referrers; a device breakdown. Panels run real queries against your views at render time. This is great for right now questions; it isn’t saved anywhere, which is exactly why the views and notebook from the previous steps matter.

​
Step 5 — Ship it as an app

When the dashboard is worth keeping, make it permanent:
You: Turn that into an app called “Site Traffic” with a date-range filter and a country filter, and publish it.
Claude writes a small React app with the Fiber SDK, publishes it through Nightshift’s remote build system, and gives you back a URL like apps.nightshift.sh/<app-id>/. The published app carries a frozen manifest of its queries — viewers see the traffic numbers without needing any access to site_events itself. See Apps for how that works.

​
Step 6 — Share it

From the console, open the app and Share it with your team, or share the notebook with an analyst who wants to poke at the SQL — sharing a notebook can even invite someone into your org automatically. See Sharing.

​
The pattern

This shape — explore → organize into views → save a notebook → render a dashboard → ship an app — is the core Nightshift workflow, and it applies well beyond analytics data. The raw data stays put; each layer above it is cheap, governed, and rebuildable by the next prompt.