Docs Dashboard Sign in

Analytics

Every share has an analytics page. It shows two things: aggregate view stats, and a per-visitor breakdown.

What is tracked#

  • View count — total views, deduplicated within a short window. Reloading the same page from the same browser does not double-count.
  • Unique-visitor count — distinct visitors over the share's lifetime.
  • Per-visitor breakdown — one row per unique visitor: a peppered IP fingerprint, the user-agent string, the first-seen timestamp, and the last-seen timestamp.
  • Download count — total downloads of the underlying file (the Download button in the share toolbar). Deduplicated on the same one-hour ua+ip grain as views, so a double-click doesn't inflate. Surfaced on the analytics page alongside Views. The count is kept even if you later turn downloads off for the share (see Access and passwords) — the toggle changes what happens next, not the record of what already happened.

How visitors are identified#

We do not store raw IP addresses. For every view, we compute:

sha256(ip + VIEW_IP_PEPPER), truncated to the first 32 hex characters

VIEW_IP_PEPPER is a server-side secret. The 32-character hash is the per-visitor identifier on the analytics page. It is irreversible: it lets you tell whether two visits are from the same network, but it cannot be used to identify the person.

The same hash is used to deduplicate views within a window.

Accessing analytics#

Web#

Three ways in:

  • From the share itself: the ⋮ menu in its header → View analytics.
  • From the dashboard or a project page: the row's actions menu (⋯) → View analytics.
  • Directly: /<org>/<project>/<slug>/analytics.

The page shows:

  • Total views and unique visitors.
  • A small chart of views over time (if there are enough data points).
  • An Engagement block with the median read time (active seconds per session, capped per heartbeat to discount idle tabs) and the median scroll depth (furthest scroll position reached, as a percentage of the document). Rendered only when at least one heartbeat session has been recorded for the share.
  • A table of visitors, sorted by last-seen, with the visitor hash, user-agent, first-seen, and last-seen columns.

CLI#

anchorify analytics <slug-or-id>          # aggregates, tab-separated
anchorify analytics <slug-or-id> --json   # the raw payload

The default output is one key<TAB>value pair per line — url, views, unique_visitors, last_viewed_at, downloads, last_downloaded_at, downloads_enabled — so it pipes into grep and cut like every other verb. The per-visitor rows are not in it: they're peppered IP hashes, which are noise in a terminal and the most sensitive thing the payload carries. --json returns them along with the 30-day daily series.

Agents (MCP)#

anchorify_share_analytics takes a share reference and returns the same JSON. It also omits visitors[] unless you pass include_visitors: true, so per-visitor hashes don't land in a transcript that didn't ask for them. Use the web dashboard.

API#

GET /api/v1/shares/:id/analytics returns the same numbers as JSON, on the same gate as the page.

CLI#

Not exposed yet.

Who sees analytics#

The page authorizes on share.flip_visibility — the same rule as the share settings page. That means:

  • Admins of the org that owns the share — full access, including an admin who did not personally publish it.
  • Project editors — full access to shares in the projects they hold an editor grant on.
  • Everyone else — no access. Project viewers, org viewers, share-level editors, signed-in outsiders: 404. An anonymous request redirects to sign-in.

Until 2026-09-07 this was narrower still — the individual who created the share, so a second admin of the owning org was handed version history, suggestions and settings on a document and a 404 on its analytics. That was drift, not a decision, and it is fixed. The widening is real and worth naming: the per-visitor rows (IP hash + timestamp) are now visible to the org's admins rather than to one person. The org owns the document and already reads its version history.

Visitors of a share see nothing. They cannot see the view count, who else has viewed, or any of the analytics data.

Retention#

Per-visitor records are kept while the share is alive. Soft-deleting a share keeps the analytics rows attached; hard-deletion (which runs on a 30-day cycle for soft-deleted shares) removes them along with the share.

Next steps#