Skip to main content

​
Page tracking

Page analytics tells you what visitors did on your published pages. Page tracking tells you whether anything was tagging them while they did it. Those are different questions, and confusing them produces a specific, expensive mistake. Here is the mistake. You read your page events, count the visitors who scrolled deep and lingered, and find 376 well-engaged sessions over the last month — comfortably enough to build a retargeting audience from. So you plan the campaign. But a retargeting audience is not built from your page events; it is built by the Meta pixel dropping a cookie on each of those visitors as they arrive. If no pixel was firing on those pages, the audience does not exist at Meta and never did. The 376 is a true number, and every conclusion it invited was wrong. Nothing in the traffic data can contradict that, because the traffic data is the same either way. The only thing that can is a read of what is actually installed. That is this endpoint.

​
What comes back

One record for your whole organization: the destinations your published pages send to, plus the two governance settings that apply to all of them.
Read kind first — it is the Erdo capability, and the field to branch on: The example above is the shape that causes the mistake: session analytics and GA4 are both on, so traffic is being measured in detail — and there is no meta_pixel entry at all, so none of those visitors is retargetable. A kind missing from the list is not configured; a kind present with enabled: false is configured and switched off. Keep those apart, because they are different problems with different fixes.
These are the vendor destinations configured on your organization. Erdo also runs a first-party page-events beacon, which writes to your own page-event dataset; it is provisioned per page when the page first renders rather than stored on the organization, so it never appears in this list. An empty destinations means no vendor is tracking your pages; it does not mean nothing is recording. (session_analytics is the destination behind page analytics HogQL queries — that is a vendor destination, and it does appear here.)
public_id is the client-side identifier already embedded in your published page’s JavaScript — a PostHog phc_… project key, a GA4 G-… measurement id, a numeric Meta pixel id. It is there so you can check the identity of what fires, not just its presence: a pixel can be enabled and still belong to an ad account your campaigns don’t run in, in which case the audience it builds is one nothing can target. Match the public_id against the pixel your ad account holds and that ambiguity disappears. host is the ingest host events are sent to; empty means the provider’s default. It travels with public_id because the same key means different projects on different provider regions. Two settings govern every destination at once. mask_inputs is whether form-input values are masked in session replay. Lead forms carry PII, so if you are about to surface replays — or reason about what a recording contains — this is the field that tells you whether the values a visitor typed were captured. consent is implied or required. Under required, recording waits on a consent banner, so thin event volume can be the consent gate rather than thin traffic. Read this before concluding a page is getting no visitors.

​
Reading it

The CLI prints every kind, including the ones you don’t have, precisely because the useful answer is usually an absence — and it says so explicitly when no Meta pixel is firing:
In chat or over MCP, the erdo_get_page_tracking tool returns the same record, so an agent asked “can we retarget the people who visited this page?” can check before answering.

​
Read-only, and why

There is no write endpoint, by design. Destinations are provisioned by Erdo into the account that has to be able to use them — your own connected ad account for a Meta pixel, Erdo’s measurement infrastructure for session analytics and GA4. A pixel created anywhere else is invisible to the campaigns meant to target it, so letting a caller name an arbitrary account would mostly produce configurations that silently do nothing. Masking and consent are yours to change, in your organization’s settings. Only public, client-side identifiers are returned — the same values a visitor can read in your page’s source. Nothing that authenticates against a provider, and not the internal numeric project id Erdo uses to read your analytics data back, ever crosses this API.

​
Permissions

Reading page tracking needs member access to the organization, and always reports that organization’s own configuration — the organization is resolved from your API key, never passed in.