Skip to main content

​
Page analytics

When Erdo publishes a page for you, real visits to it are recorded into your organization’s own analytics project. Page analytics is the read side of that: a single query surface that answers quantitative questions about how your published pages perform — how many people viewed a page, which variant converts, where the traffic came from. It is the same data the growth engine measures a variant against, exposed so your own products and dashboards can read it too. You ask the question as a query, not by picking from a fixed menu of reports. That is deliberate: the events carry enough structure that a new question — views this week, conversions by campaign, a daily series — is a new query, never a new endpoint to wait for. The query language is HogQL, PostHog’s SQL dialect (ClickHouse under the hood), and it runs read-only against your organization’s own project — the project is resolved server-side from your org, so a query can only ever see your own traffic regardless of what it selects.

​
What every event carries

The tracking snippet Erdo injects into a published page stamps each event with the properties you need to attribute it. The main table is events — one row per event, with event (the event name), timestamp, distinct_id (the visitor), and JSON properties you read as properties.<name>: PostHog auto-captures a $pageview event on every view, so $pageview is your denominator when you compute a rate. Pages can also emit named conversion events (a form start, a lead, a video play); if you’re not sure what event names exist, list them first with a SELECT event, count() FROM events GROUP BY event.

​
enabled: false means analytics is off, not empty

Every result comes back as { enabled, columns, types, rows, truncated }. The one field to read first is enabled. When it is false, page analytics is switched off for your organization — it does not mean zero traffic. Treat it as a prompt to turn analytics on (publishing a page, or the first view of one, also turns it on), not as an empty dashboard. When enabled is true, columns names the columns, rows holds the result positionally per column, and truncated is true when the result hit the row cap — aggregate further or add a tighter filter if you see it.

​
Example queries

Views per page over the last week — the everyday “how much traffic did each page get” read, grouped by the page’s artifact_id:
Views by campaign — attribute traffic to the campaign that brought it, so you can see which utm_campaign is actually landing visitors:
Daily $pageview series — traffic over time, one row per day, to spot a launch spike or a slow week:
Always bound a query by timestamp and add a LIMIT — the events table grows with your traffic, and an unbounded scan is slower and more likely to be truncated. If a query is rejected, the error carries PostHog’s own diagnosis (an unknown column, a syntax slip), so you can fix the query and retry in place.

​
In chat

The simplest way in is to ask — the agent writes the HogQL for you:
“How many views did each of my published pages get this week, and which campaign drove the most traffic?”
The agent runs the query, reads the result, and summarizes it. If analytics isn’t on yet, it will tell you and offer to enable it.

​
CLI

By default the CLI prints an aligned table of the result. When analytics is off for the org, it says so rather than printing an empty table.

​
MCP

The erdo_page_analytics_query tool takes a single query argument (the HogQL) and returns the { enabled, columns, types, rows, truncated } result. Its description carries the events schema above, so an agent can write a correct query without first reverse-engineering the properties.

​
REST

The response mirrors the tool exactly:
Querying needs member access to the organization; the query only ever reads that organization’s own analytics project.