Getting a page
You don’t drag and drop — you ask. In a thread, describe what you want and an agent 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.”The agent generates the page, wires it to the right data, and shows it back to you. Ask for changes in the same thread and it rebuilds.
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 an agent builds or edits a page, Erdo validates its 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, an agent is dispatched automatically to diagnose the problem and prepare 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.
Managing pages
Pages have a full lifecycle you can drive from a thread, 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.
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.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.
“How are visitors using my landing page — where are they dropping off?”
Querying your page analytics
Beyond individual session replays, agents 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: the agent 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 an agent 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, which writes them to a shared Page events dataset in your organization:
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 an agent:
“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.