> ## 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.

# Page tracking

> Read which analytics destinations your published pages send visitor data to — session analytics, GA4, the Meta pixel — so you know whether visitors are actually being tagged before you draw a conclusion from your traffic numbers.

# Page tracking

[Page analytics](/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.

```json theme={null}
{
  "destinations": [
    {
      "kind": "session_analytics",
      "provider": "posthog",
      "enabled": true,
      "public_id": "phc_abc123...",
      "host": "https://us.i.posthog.com"
    },
    {
      "kind": "google_analytics",
      "provider": "google",
      "enabled": true,
      "public_id": "G-XXXXXXXXXX",
      "host": ""
    }
  ],
  "mask_inputs": true,
  "consent": "implied"
}
```

Read `kind` first — it is the Erdo capability, and the field to branch on:

| Kind                | What it does                                                                                 |
| ------------------- | -------------------------------------------------------------------------------------------- |
| `session_analytics` | Heatmaps and session replay, and the events behind [page analytics](/page-analytics) queries |
| `google_analytics`  | GA4 measurement                                                                              |
| `meta_pixel`        | Cookies visitors so Meta retargeting audiences accumulate                                    |

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.

<Note>
  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](/data); 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](/page-analytics) HogQL
  queries — that is a vendor destination, and it does appear here.)
</Note>

`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.

## Masking and consent

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

<CodeGroup>
  ```bash CLI theme={null}
  erdo analytics tracking
  ```

  ```bash REST theme={null}
  curl https://api.erdo.ai/v1/page-tracking \
    -H "Authorization: Bearer YOUR_API_KEY"
  ```
</CodeGroup>

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:

```
kind               status          public id     provider  what it does
-----------------  --------------  ------------  --------  ----------------------------------------------------------------------
session_analytics  on              phc_abc123    posthog   heatmaps, session replay, and the events behind `erdo analytics query`
google_analytics   on              G-XXXXXXXXXX  google    GA4 measurement
meta_pixel         not configured                          cookies visitors so Meta retargeting audiences can be built

session replay input masking: on
consent: implied

No Meta pixel is firing on these pages, so no retargeting audience is accumulating — page traffic
alone does not mean those visitors can be served ads.

Erdo's own page-events beacon is provisioned per page at render time and is not listed above — it
records independently of every vendor here.
```

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.