# Creating Live Intelligems Dashboards in Claude ## 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](https://docs.intelligems.io/developer-resources/external-api/automations-and-guides) in our developer docs, which require engineering resources to set up. Same results, but this approach takes minutes instead of hours. {% hint style="warning" %} **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. {% endhint %} ### Prerequisite: * Requires [Intelligems MCP Server](https://docs.intelligems.io/developer-resources/mcp-server/claude) 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. {% hint style="info" %} **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). {% endhint %} #### 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](https://docs.intelligems.io/developer-resources/external-api/automations-and-guides/build-a-multi-client-test-overview-dashboard), 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"`). > > ![](/files/LBeDRR2JOvR6N4NF8AOZ) > > **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: ""}]}`. 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](https://docs.intelligems.io/developer-resources/external-api/automations-and-guides/automating-a-cfo-friendly-incremental-revenue-attribution-for-cro). > 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: ""}]}`. 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. {% hint style="info" %} **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. {% endhint %} ## 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. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.intelligems.io/developer-resources/mcp-server/creating-live-intelligems-dashboards-in-claude.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.