Noibu Product & Collection Performance Analysis

Surfaces which products and collections are winning or losing, and why — built from Noibu session and page data.

How it works

• Quick answer (one focused question) → run 1–2 queries, answer directly, offer to go deeper.
• Full analysis (broad request, bare invocation, or "yes" to the offer) → the workflow below.

Setup — before any query

Work quietly. Resolving the domain, loading reference files, reading field names, and running queries all happen silently — no "let me…" commentary. The triage board widget is the first substantive output.

• Resolve the domain first. Use what the user gave (name or UUID). If nothing, ask via AskUserQuestion populated from their domains — don't ask about anything else. If exactly one domain, skip the question.
• Use the querying-noibu-data reference already loaded in context — do not read it again. It maps role-based names to real tools/columns and documents query constraints.
• Call list_scheduled_tasks now — check whether any task's prompt references this domain and store the result. This sets the action bar button label later ("Schedule report" vs "Edit scheduled report") without blocking rendering.
• Confirm every field name by role before using it. Steps name fields by role, never hard-coded column names.
• Default window: from the context reference; if none, last 30 days.
• If the entire dataset is near-zero (total sessions 0 or a handful), say plainly the domain has no traffic in this window and offer to widen the range or pick another domain.

Quick answer

For focused questions ("which products get the most views?", "how is the Sale collection performing?"):

1. Run only the 1–2 queries needed.
2. Answer directly — a few sentences and a small table if useful.
3. Offer full analysis; if yes, proceed below.

Don't load the triage-board or scheduling references for a quick answer.

Full analysis

A broad request, a bare invocation, or "yes" to the quick-answer offer.

Loading reference files: Use the Read tool. All files live in a references/ subdirectory next to this SKILL.md — derive the base path from wherever this file was loaded from.

1. Read references/queries.md AND references/triage-board.md now, before running any queries.
2. Run the four-step workflow from queries.md.
3. Render the overview card, priority cards, and action bar as one show_widget using triage-board.md. Use the list_scheduled_tasks result from setup to set the schedule button label.

After the widget, add a single short closing line so the turn ends with visible text — a show_widget with no following text can be read as "no visible output" and trigger a duplicate re-render. Keep it to one sentence naming what it is; don't recap the findings or restate what's in the widget.

Create live dashboard

Triggered by the overview card 'Save as dashboard' button (arrives as "Save product overview as dashboard for [domain]").

Read references/live-dashboard.md and follow the instructions there to build and save the artifact. references/triage-board.md is already in context from the full analysis.

Export PDF

Triggered by the action bar button (arrives as "Export product analysis as PDF for [domain]").

Read references/export-pdf.md and follow the instructions there.

Schedule report

Triggered by the action bar button (arrives as "Schedule product analysis for [domain]" or "Edit schedule for [domain]").

Read references/schedule-widget.md and render it as a show_widget. After the widget, add a single short closing line so the turn ends with visible text — don't recap the options, just name what it is.

Investigate click

A triage-board Investigate button arrives as a chat prompt ("Investigate this product signal: …") — handle as a focused follow-up, not a re-render of the board.

• Don't re-run the breakdown that built the card — reuse the evidence already gathered; only query again if genuinely new depth is needed.
• Go one level deeper for root cause. A single Investigate may surface more than one cause.
• Route the what-next by cause type — decide this after diagnosing, never on the button click:
  • UX / merchandising / funnel / ops / localization → write the action inline: one concrete, owner-routed step + the check that confirms resolution.
  • Priority error or performance/CWV → invoke the tech-diagnosis skill directly (read it via the Read tool using its path from the available skills list) and continue inline. Do not output a slash command or handoff text — the user should not see any /tech-diagnosis ... syntax.
• Respond in plain chat text — do not use show_widget. Format: root cause in 1–2 sentences, then a small markdown table of supporting evidence (≤8 rows), then the recommended action or tech-diagnosis output. Keep it tight; don't re-render the board.

Data quality notes

• CVR is only comparable within the same price tier. High-ticket products and collections will always convert at lower rates than low-ticket items — this is expected, not a signal. Never flag low CVR as underperformance without a same-tier benchmark. Use product and collection names to infer price tier; when no same-tier benchmark exists, rely on ATC_LIFT_OPPORTUNITY and funnel depth instead. This limitation applies at every level — product, collection, and product type. Price data is not available in Noibu session data.
• Revenue per product unavailable. Order value = total cart for the session — all products in that session get credited the full value. Never label it "product revenue." Use purchase session count as the primary volume metric; median cart value as secondary.
• Product title variants. Same base product may appear as multiple rows (e.g. "WOMENS CLASSIC TEE - WT0200005" vs "WOMEN'S CLASSIC TEE - WT0200005"). Flag near-duplicates; don't silently merge.
• URL fragmentation. Always use URL CONTAINS with a SKU code or slug fragment in page visit queries.
• Null funnel depth = viewed only. Always label as "Viewed only", not blank or missing.