Publish verified aggregate metrics safely

Approve a bounded aggregate query, publish only its reviewed blueprint, and embed the returned public URL without exposing owner credentials or identities.

Updated July 10, 2026 · published May 16, 2026

difficulty intermediate · time to value 10 minutes · execution human review required

Prepare one public aggregate metric from a verified signal. Confirm the exact definition, privacy threshold, and safe query blueprint, show the rows before publication, and wait for human approval before creating or embedding the public query.

Why this matters

A public metric is a disclosure boundary, not merely a chart. The wrong query can expose identities, small cohorts, internal operations, or a number whose definition changes silently.

Agentry public queries are safe when they publish a reviewed aggregate query blueprint with fixed, validated parameters. Custom owner-side HogQL is not directly publishable. If no suitable blueprint exists, the workflow ends with a code-review task for a new safe aggregate blueprint.

What you get

A precise metric definition and answerability check
A preview from the same reviewed blueprint that would be published
Human approval of audience, privacy threshold, wording, and lifetime
The returned revocable public_url, with no deployed owner credential

Walk through it

You

Publish our verified three-step signup funnel on the marketing site.

Agent

I will verify the exact events and preview the approved aggregate blueprint. Publication remains a separate human-approved action.

GET /v1/projects/:project_id/signal-map
GET /v1/projects/:project_id/onboarding
# Require status: "verified"; use live event/property reads for the selected signals.
GET /v1/query-blueprints/funnel_3_step
POST /v1/projects/:project_id/query-blueprints/funnel_3_step/run

After the reviewer confirms the rows, time window, sample, audience, and wording:

Endpoint: POST /v1/projects/:project_id/public-queries
Exact shape: /v1/openapi.json?path=%2Fv1%2Fprojects%2F%7Bproject_id%7D%2Fpublic-queries&method=post
Concept fields:
  blueprint_id: funnel_3_step
  params: <the exact reviewed params>
  description: <public definition and period>

Use the actual public_url returned by Agentry. Do not invent publication IDs or reconstruct the URL from an assumed pattern.

The output

Public metric review

Definition
- source events, ordered logic, exact period, denominator, timezone

Preview
- aggregate rows and sample size from the reviewed blueprint

Privacy
- no identities or rare segments
- minimum sample and disclosure notes

Publication
- approval owner: <human>
- destination: <site/page>
- returned public_url: <only after approval and creation>
- revoke/review date: <date>

Setting it up

Embed or fetch the returned URL exactly as documented by its response. Do not append undocumented query parameters or place AGENTRY_PRIVATE_API_KEY in browser code, static-site builds, edge workers, or unattended schedulers.

Review existing publications with the project public-query list and revoke any URL whose purpose has ended. A publication should fail closed when its blueprint or parameters are no longer safe or valid.

Variations

“Preview a verified retention aggregate, but do not publish it.”
“Explain why this requested metric needs a new safe blueprint.”
“Review all current public-query URLs and their stated purpose.”
“Revoke a selected publication after the owner confirms the exact ID.”

Adapt this workflow in your own agent.

Ask your agent to map the starter prompt to your saved signal map, live events, and the current HTTP API before answering.

Agentry gives coding agents production context from errors, product analytics, and deploys through one HTTP API. Fetch and read https://agentry.sh/install.md completely, then install Agentry's full first-time telemetry baseline in this repository. I authorize device-code login, saving the owner key only to ~/.agentry/credentials.json, creating one Agentry project for this repository, and read-only inspection of shipped source plus hidden CI/provider configuration. Deeply analyze the product's business logic and complete value flow before choosing telemetry. Save the complete source-backed plan and show me its exact contents and hash. Until I explicitly approve that plan or request a replacement, do not edit app/CI source, place runtime/CI credentials, commit, exercise product traffic, start proof, push, or deploy. After approval, I authorize only the reviewed targets: place the required scoped browser/server/CI credentials through the established environment or secret mechanism, preserve existing telemetry, implement and test the baseline, commit it, push that reviewed commit when the shipped CI/provider path requires it, exercise safe proof paths with test/non-customer data, and perform one deployment through the reviewed shipped CI/provider path. Ask first if proof would charge money, contact a third party, change real customer data, or require new external access. After the plan is saved, immediately before every onboarding state-changing POST, GET current onboarding state, perform only its single returned next_action, then read state again; do not batch or infer later stages. Continue until status is verified, installation_complete is true, and next_action is null. Keep all secrets, source snapshots, proof markers, and scratch files outside the repository.

+ Full access

5.5 Extra High

1. Open your repo in Codex, Claude Code, Cursor etc.
2. Paste the install prompt.
3. Your agent reads the install doc and shows you an implementation plan for approval.