Skip to main content
Insights, in the app’s sidebar for people with write on the workspace, and at GET /api/v1/insights, answers whether the brand is followed.
  • Brand answers per week: every file served, BrandHub listing read, use checked and search that found something, by people, agents and anonymous visitors.
  • Release adoption: fetches of the current version of an asset against fetches of a version that was already replaced when it went out.
  • Still on the old release: the replaced versions fetched lately, and the sites (referrer hosts) that load them.
  • Most used assets, with their fetches by surface: the app, a key on the API, MCP, a portal, a signed link, a public embed.
  • Search gaps: searches with no result, from the app, portals and MCP.
  • Delivery and portal page views, per day and per page.
Its Use checks tab, at /insights/checks, is the use-check log: every check_use and POST /api/v1/check answer counted, refusals by reason (replaced, expired, territory, wrong variant), and the latest ones with who asked, what was offered instead and whether it was taken: the same client fetched the replacement, or checked it and was allowed, afterwards. Export CSV saves those rows. Each asset’s panel has a Used in fold, from GET /api/v1/assets/{id}/insights: the brand rules that point at it, the brand pages that show it, the open public portals it is on, and its fetches over the last 30 days by surface and by the sites that load it. Each brand has an Insights tab too, at /brands/{slug}/insights, from GET /api/v1/brands/{slug}/insights. A fetch or a check names a file, not a brand, so the brand’s files are the ones its rules held in its last 20 releases, each belonging to the newest release that holds it. From them: this week’s brand answers (its files served, uses of them checked, its BrandHub files read), the share asked by agents, the uses refused, and release adoption: the fetches since the latest release a day each, on it or on an older one (a file replaced in its stack counts as older), with the places that still load an older one this week, by site, agent or surface. The brand’s Overview shows the share on the latest release beside its pulls. Connections, the page where agents are connected, adds what each one asked for over the last 30 days, from GET /api/v1/insights/connections, in a table: each agent with where it runs and its access (its key’s owner and scope), its calls, the MCP tool it asks for most (hover for every tool, how many failed, and the brand contexts it asked for), and what it was refused, by reason.

​
What is recorded

One row per event in the events table: a file fetched from /a/{id} (the app drawing its own thumbnails is left out), a check_use verdict with its reasons and the replacement offered, a search with words, a BrandHub file read, an MCP tool called (its name and whether it worked, never its arguments), and the brand context an agent asked for. Each keeps its kind, surface, whether the actor was a person, an agent or nobody in particular, an agent’s key name, the asset or subject, the version, the verdict, the referrer’s host, and the day. Never an IP address, a person’s name or a full URL. There are no cookies or trackers for portal and hub visitors. Everything stays in your own Postgres: a self-hosted install sends nothing anywhere. Raw events are kept 90 days. Once a day is over, it is rolled up into event_days, which is kept; charts read both through the event_counts view, so they are current whenever the rollup last ran.