Creating Live Intelligems Dashboards in Claude

Learn how to build dynamic, real-time experiment and revenue attribution dashboards inside Claude using the Intelligems MCP Server—no coding required.

Overview:

Live artifacts are dynamic dashboards inside Claude that pull fresh data from your connected tools every time you open them. Unlike static reports, they stay current without any manual refreshing — open the artifact tomorrow and you'll see tomorrow's data.

This guide walks you through building live artifacts with Intelligems data — from multi-client test dashboards to revenue attribution reports. These are no-code alternatives to the API-based guides in our developer docs, which require engineering resources to set up. Same results, but this approach takes minutes instead of hours.

A note on loading speeds

Live artifacts fetch data in real time every time you open them. Each API call goes through the Cowork runtime one at a time, and each round-trip takes roughly 2-4 seconds. A dashboard tracking 2 clients with 3 tests total might take 10-15 seconds to fully load. More clients or more active tests means a longer wait.

This is a platform constraint, not something you can optimize in your prompt. We hope Anthropic will make improvements here in the future.

Prerequisite:

• Requires Intelligems MCP Server to be connected

• Requires a Claude Pro, Team, or Enterprise plan

How to Build Your Live Artifacts

Step 1: Navigate to Cowork

In the Claude Desktop app, click the checklist icon in the top left to switch to Cowork mode.

Step 2: Create New Live Artifact

Navigate to the Live artifacts section in the Cowork sidebar.

Click New artifact.

Step 3: Ask Claude to create your Live Artifact

Below are ready-to-use prompts for common dashboards. Copy the one you need, replace the placeholder brand names with your own, and paste it into the new artifact conversation.

Where do I find my brand names? Use the exact names as they appear in the Intelligems org switcher (top-left of the Intelligems app).

Multi-Client Dashboard Prompt

A single table showing active split tests and uplift metrics across multiple brands — the same view as the API + Netlify multi-client dashboard guide, but built entirely inside Claude.

Build me a live artifact: an Intelligems multi-client split test dashboard for [Brand A] and [Brand B].

What to show: A dark-themed table (slate background, light text) with one row per active experiment (like the screenshot below). Columns: Client, Test Name, Conv Rate Uplift, RPV Uplift, GPV Uplift, AOV Uplift, and a View link to https://app.intelligems.io/experiment/{id}. Include filter buttons to toggle by client, and make all columns sortable. Exclude personalizations — only show A/B tests (filter out any experiment where type starts with "personalization").

How to fetch data: Use the Intelligems MCP connector. For each client, call search_experiments with {organization: "Client Name", status: "started"} to get active tests, then call get_variation_overview with {id: experimentId, organization: "Client Name", metrics: ["conversion_rate", "net_revenue_per_visitor", "gross_profit_per_visitor", "net_revenue_per_order"]} to get metrics.

Critical implementation details you must follow:

1. Unwrap MCP responses. callMcpTool returns {content: [{type: "text", text: "<JSON string>"}]}. You must parse the response with JSON.parse(response.content[0].text) to get the actual data.

2. Make all API calls sequentially. Use for loops with await — never Promise.all. Concurrent callMcpTool calls cause responses to get mixed up between clients. Sequential is critical for correctness.

3. Parse the markdown table response. get_variation_overview returns a markdown table string in results. Split on newlines (handle both real \n and escaped \\n), extract headers from row 1, skip the separator in row 2, and parse data rows 3+.

4. Extract uplift from metric cells. Each cell looks like 9.29% (95% CI: 8.65% to 9.97%) (p2bb: 71%) (p2bc: 71%) (+3% uplift). Look for the (+X% uplift) pattern via regex. The variant with p2bc and uplift is the test variant; the one without is control. For multi-variant tests where no variant has explicit uplift text, compute it manually by comparing the highest-p2bb variant's raw value to the lowest-p2bb variant's raw value.

5. Poll for the cowork API. window.cowork may not be available immediately when the script runs. Poll every 50ms for up to 10 seconds before making any API calls.

6. Render progressively. After each get_variation_overview completes, re-render the table so users see results streaming in rather than waiting for everything to finish.

Incremental Revenue Attribution Dashboard Prompt

A CFO-friendly view of the incremental revenue your testing program has generated, using a conservative decay model. This is the live artifact version of the n8n + Airtable CFO-friendly attribution automation.

Build me a live artifact: an Intelligems Revenue Attribution dashboard for [Brand Name].

What it does: Calculates the incremental revenue generated by winning A/B tests using a conservative 6-month decay model — designed to be credible enough for a CFO.

Layout (dark theme):

• Header: "[Brand Name] Revenue Attribution" with subtitle "Conservative decay model · 6-month attribution window". Include time period toggle buttons: YTD (default), 90d, 30d. The selected period controls the date range for sitewide revenue and which months of attribution are summed.

• Summary cards row: (1) Attributed Revenue — the total decayed incremental revenue, highlighted in green/purple, with "N winning tests" subtitle; (2) Store Revenue — total sitewide revenue for the period; (3) Attribution % — attributed / store revenue, shown in green, with a warning icon if the 30% portfolio cap was applied; (4) Avg Monthly Visitors — from sitewide data.

• Cap warning banner: If the portfolio cap was applied, show an amber banner: "Portfolio cap applied: Total attribution was scaled down to $X (30% of store revenue)."

• Winning Tests Breakdown: A list of each winning test showing: test name, RPV uplift (as +$X.XX), go-live date, "Month N of 6", current decay percentage as a badge (color-coded: green for 100%, yellow for 75-50%, gray for 25-10%, "Expired" for 0%), and the individual attributed revenue amount.

How to calculate attribution:

1. Find winning tests. Call search_experiments with {organization: "[Brand Name]", status: "ended"} to get completed tests. For each, call get_variation_overview to get metrics. A test is a "winner" if any non-control variant has positive RPV uplift (look for positive net_revenue_per_visitor uplift in the response). Use the experiment's endedAtTs as the go-live date (when the winner was shipped).

2. Also check active tests. Call search_experiments with status: "started". Some winning variants may have been shipped while the test is still running. Include started tests that have positive RPV uplift with p2bb >= 80%. Use startedAtTs as the go-live date for these.

3. Get sitewide data. Call get_sitewide_snapshot with {organization: "[Brand Name]"} for total store revenue and visitor counts. If a time-range parameter is available, use it to match the selected period (YTD, 90d, 30d).

4. Apply the decay schedule per winning test. For each month since go-live, attribute revenue as: RPV_uplift × avg_monthly_visitors × decay_factor. The decay schedule is:

   • Month 1: 100%, Month 2: 100%, Month 3: 75%, Month 4: 50%, Month 5: 25%, Month 6: 10%, Month 7+: 0% (expired)

   • RPV uplift = the dollar difference in net_revenue_per_visitor between the winning variant and control (not percentage — the raw dollar amount)

   • Avg monthly visitors = total sitewide visitors for the period divided by months elapsed

5. Apply the portfolio cap. Sum all individual test attributions. If the total exceeds 30% of store revenue for the period, scale every test's attribution proportionally so the total equals exactly 30%. Flag this in the UI.

Critical implementation details:

1. Unwrap MCP responses. callMcpTool returns {content: [{type: "text", text: "<JSON string>"}]}. Parse with JSON.parse(response.content[0].text).

2. Make all API calls sequentially. Use for loops with await — never Promise.all.

3. Parse the markdown table response. get_variation_overview returns a markdown table string in results. Handle both real \n and escaped \\n.

4. Extract RPV values. The raw RPV value is at the start of the net_revenue_per_visitor cell (e.g., 9.1374 (95% CI: ...)). Parse with a regex like /^([\d.]+)/. To get RPV uplift in dollars, subtract the control variant's raw RPV from the winning variant's raw RPV.

5. Poll for the cowork API. Check for window.cowork every 50ms for up to 10 seconds before starting.

Note on go-live dates: This prompt uses endedAtTs (for ended tests) and startedAtTs (for active tests) as proxies for when the winning variant was shipped. For more precise attribution, you can tell Claude specific go-live dates: "For the 'Homepage Hero' test, the go-live date was March 18, 2026." Claude will hardcode these into the artifact.

Troubleshooting

"No active split tests" or empty table

• Verify your brand names match exactly how they appear in the Intelligems org switcher. Ask Claude: "Can you call list_organizations and search for [brand name]?"

• Check test status. Only experiments with status "started" appear. Paused, ended, or pending tests are excluded.

• Check that mcp_tools was set on creation. If the artifact was updated after its initial creation, the API connection may have been lost. Ask Claude to create a fresh artifact.

Metrics showing "n/a"

• The test may have only one variation with data, or the markdown table format may differ from expected. Ask Claude: "Can you call get_variation_overview for experiment [ID] on [Brand] and show me the raw response?"

• Tests with very few visitors may not yet have uplift annotations in the response.

Dashboard loads slowly

• Each test requires a separate API call. Brands with many active tests (10+) will take longer.

• You can speed things up by filtering out test types you don't need (e.g., add "personalization" or "pricing" to the exclusion filter).

• We anticipate that Claude will make enhancements here that allows more complex dashboards to load faster in the future.

"Cowork API not available after 10000ms"

• The artifact was created or updated without the mcp_tools runtime configuration. Ask Claude to create a new artifact from scratch rather than updating the existing one.

Dashboard not updating

• When Claude updates an existing artifact's code, the live API connection (mcp_tools) may stop working. If this happens, ask Claude to create a fresh artifact with the updated code rather than updating the existing one. Once created correctly, the artifact works reliably on every subsequent view. The issue only occurs during code updates.