> ## Documentation Index > Fetch the complete documentation index at: https://docs.erdo.ai/llms.txt > Use this file to discover all available pages before exploring further. # Pages > Turn a result into a shareable, data-wired app — dashboards, reports, and tools Erdo builds for you. A **page** is a small app Erdo builds for you: a dashboard, a report, an interactive tool. It's wired to your data with live values, runs in a managed sandbox under your permissions, and can be shared with your team or published. ## Getting a page You don't drag and drop — you ask. In a [conversation](/concepts#conversations), describe what you want and Erdo builds it: > "Turn this into a dashboard showing signups by plan over time, with a filter by > region, that I can share with the team." Erdo generates the page, wires it to the right [data](/data), and shows it back to you. Ask for changes in the same conversation and it rebuilds. ## Pinning pages to a project When a conversation belongs to a project, every page it creates is added to that project's recent outputs automatically. This keeps the result discoverable without changing how you work in the conversation. Pin the pages that should define the project from the pin button in the page toolbar, or from **Recent pages** on the project home. Pinned pages appear at the top of the project home and in the project's sidebar. Unpinned outputs stay available in **Pages** and **Recent pages**, so generating a one-off output does not force it into a project. ## Live, not a snapshot Pages read your data at view time, so they stay current — open one tomorrow and it reflects tomorrow's numbers. They can also hold their own state and react in realtime when more than one person is looking. ## Self-healing A page is real code wired to data that changes over time, so either side can drift: the code can hit a case that only shows up later, or a dataset the page reads can be reshaped by a refresh weeks after the page was built. Erdo keeps pages working without you having to watch them. When Erdo builds or edits a page, it validates the code and its data queries before the page is saved. It re-verifies every page after each dataset refresh, so a change to your data can't quietly break a chart. And it monitors your published and shared pages for errors as real visitors view them. When something breaks at any of those points, Erdo automatically diagnoses the problem and prepares the fix — usually before you'd have noticed. A fix to a private draft is applied on its own; a fix to a published page is proposed for your approval first (or applied automatically if you've set an approval policy for page edits), so a live page never changes without your say-so. Every fix is a new revision, so nothing is lost. ## Sharing * **Private** — open to people in your workspace, under your existing permissions. * **Public link** — publish a read-only version anyone with the link can view. Identity and access always come from the viewer's own permissions, so a page can't expose data the viewer isn't allowed to see. ## Managing pages Pages have a full lifecycle you can drive from a conversation, the CLI, the REST API, or MCP: * **List** the pages in your workspace, newest first, and filter by title or a created-at window to find a specific set. * **Delete** a page. This is a soft delete: its public share link stops working immediately and it drops out of listings, but it is not gone. * **Restore** a deleted page to bring it back. It returns **private** — deleting revoked its public grant, so re-publish it if you want the share link live again. In a conversation you just ask ("list my pages", "delete the old pricing page"). From the terminal: ```bash theme={null} erdo pages list --query "pricing" erdo pages delete erdo pages restore ``` The same operations are on the REST API (`GET /v1/pages`, `DELETE /v1/pages/:id`, `POST /v1/pages/restore/:id`) and as the MCP tools `erdo_list_pages`, `erdo_delete_page`, and `erdo_restore_page`. Building pages programmatically (deploying via the API, MCP, or SDK, and the `window.erdo` client) is covered in the developer guide, [Build Apps](/apps/build-apps). ## Session replay & heatmaps Your published pages come with **session replay and heatmaps** automatically — see how real visitors actually behave: where they click, how far they scroll, where they drop off. There's nothing to turn on. The first time a public page is visited, Erdo provisions an isolated analytics project for your organization (so your data is never mixed with another customer's) and records real visitors from then on — this applies to pages you've already published, not just new ones. A few things are handled for you: * **Form inputs are masked by default** — names, emails and other typed values are hidden in replays, so you see behaviour without capturing personal data. * **Your own previews don't count** — pages opened in preview/screenshot mode (and staff previews) are never recorded, so your numbers reflect real visitors only. * **It's per-organization** — every published page in your workspace shares one project, and that project is yours alone. Just ask to review them: > "How are visitors using my landing page — where are they dropping off?" ### Querying your page analytics Beyond individual session replays, Erdo can **query your page-analytics events directly** — every event a published page fires carries the page, the experiment variant (when one is running), the URL, and campaign parameters, so questions about real visitor behaviour are answerable with a query rather than a fixed report. Conversion rates per variant, form starts by campaign, drop-off between pageview and lead submission: Erdo writes the measurement to fit the question. When you're running page variants against each other, ask: > "Which variant of my landing page converts better — show me form starts and lead > submits per variant for the last two weeks." Queries are read-only and always scoped to your organization's own analytics project. This is telemetry Erdo collects from your published pages, not data from a separate analytics-provider account you may have connected to Erdo. Ask explicitly about that connected provider when you want Erdo to inspect the provider account instead. ### First-party page events Your published pages also record their key conversion events **directly into your own Erdo workspace** — first-party, with no retention window and no vendor in the read path. Each published page posts a small, fixed set of named events to its own [event pipeline](/event-pipelines), which writes them to a shared **Page events** [dataset](/data) in your organization: | Event | Meaning | | -------------------------- | --------------------------------------------------------------------------------------------------------------- | | `pageview` | A visit — the denominator for every rate | | `scroll_50` / `scroll_100` | The visitor scrolled halfway / to the end | | `section_visible` | A named page section entered the viewport (section id in `params`) | | `cta_click` | A click on a call-to-action | | `form_start` | First focus on the lead form | | `generate_lead` | A completed lead submission — joins to the lead row itself | | `watch_video` | A visitor watched a video with sound — the first sound-on playback (ambient muted autoplay loops never fire it) | Every row carries the page (`artifact_id`), the **experiment variant the visitor was actually served**, a per-visit session key, the page URL, and campaign attribution (`utm_*`, `gclid`, `fbclid`) — so per-variant funnels are a plain SQL query over your own dataset, and they line up with your leads because both streams stamp identical attribution. Ask Erdo: > "From the Page events dataset, show pageview → form start → lead conversion per variant > for the last two weeks." This is a curated stream of discrete events, not a session recorder — session replay, heatmaps, and click autocapture stay with the session-analytics project above. It's on automatically for published pages (the first public view provisions the pipeline and dataset), preview and screenshot renders never emit, and events with names outside the fixed set are rejected at the pipeline. To turn it off for a page, disable that page's page-events pipeline. ### Google Analytics Your published pages are also wired up to **Google Analytics** automatically — Erdo provisions an isolated GA4 property for your organization and tracks pageviews and events there, alongside session replay. Same as session replay: nothing to set up, no measurement ID to paste, no Google account of your own required — it's handled for you and your data stays in your own property.