Events
The Events page (/workspace/<slug>/journey/tracking-signals, its own row in the sidebar, right under Overview) is the inventory behind your journey: every event analysis found, one row each, in a single filterable table. The journey canvas shows the shape of your journey; this page shows the evidence. When you want your gaps as a list instead of a graph, start here.
Where the rows come from
This page is a different view over the same data the Analyze run produces. It has no analysis of its own to run first: if there's no journey yet, the page tells you so ("Run Analyze on Lifecycle to map events to steps") and links you to the Lifecycle page. Run your first analysis and come back.
What a row is
Three kinds of event share the table:
| Kind | Source badge | What it means |
|---|---|---|
| Code event | Code, or the analytics provider | An analytics event found in (or recommended for) your codebase, with the files it lives in |
| Observable in database | Supabase | A step tracked through a table or column in your schema |
| Step without tracking | Step | A step with nothing behind it. A gap |
Each row shows the event, its source, where it was found (a file in your repo, a table in your schema), its status, and what it maps to: the lifecycle stage and the step. Click a row to open the same detail panel you get from the canvas.
A step can appear on more than one row. When an event for it was found in your code and the step is also backed by a table, you get both a code row and a database row, one per source, rather than only the database one.
Status
| Status | Meaning |
|---|---|
| Detected | Tracking found in your product code |
| Recommended | Suggested by analysis, not in your code yet |
| Can be tracked (DB) | Backed by a table in your schema; no code event needed. When an event for the step was also found in your code, that row reads Detected instead |
| No tracking yet | A step with no event behind it |
| Not placed yet | An event found in your code that isn't mapped to any step yet |
The chips above the table keep the running totals: code events, events observable in the database, steps without tracking, and events not placed yet. Those last two are your to-do list.
Filters and grouping
Search by event name or location, filter by source or status, and group the table by Status (the default), Source, Found at, or Lifecycle stage. Grouping by lifecycle stage is the fastest way to answer "which part of the journey am I blind in?"
Ignoring events and tables
Not every event belongs in the inventory. Debug events, one-off test events, and internal tables add noise to the gap list. Every code event row and database row carries a dismiss button at the end of the row (Ignore event, Ignore event in <file>, or Ignore table, depending on the row): click it to drop that row from the table and keep it out of later Analyze runs. The chips above the table stop counting it, and it also disappears from the Overview tracking summary.
Ignoring writes a rule into your workspace snapshot:
- A code event goes to
skene-context/eventignore.md, scoped to the file it was found in when there is one. - A database row goes to
skene-context/dbignore.md, which also excludes that table from schema discovery on the next analysis.
To bring something back, or to ignore things in bulk, edit those two files from the Data sources popover on the Lifecycle page.
eventignore.md rules
One rule per line, # for comments, matching is case-insensitive. eventignore.md has a 64 KB limit.
| Rule | What it ignores |
|---|---|
debug_* | Every event whose name matches the pattern |
=feature_activated | That exact event name, everywhere |
=checkout_completed@src/analytics.ts | That exact event, but only in that file |
@src/analytics.ts | Every event found in that file |
@public.orders | Every database signal from that table |
dbignore.md is a plainer list: one schema.table or table per line.
Re-running analysis
The page header carries the same Analyze control as the Lifecycle page. Once a journey exists, the primary action is Status check: re-scan the code, re-read the schema, re-match events, without rebuilding the journey. Run full analysis, in the split menu, rebuilds it from scratch. Details in Running analysis.
Next steps
- Lifecycle & Analysis: the canvas these events map onto
- GitHub Integration: PR reviews: keep detected events from silently disappearing
- Flows: what users actually do in your product, captured live
