Identify your most engaged users and accounts

Rank pseudonymous users or accounts with a reviewed product-value definition, keep identities private, and use the result as research evidence rather than an outreach command.

Updated July 10, 2026 · published May 16, 2026

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

Identify the most engaged users or accounts for a defined period using verified product-value events and a reviewed weighting rule. Return pseudonymous IDs by default, explain the formula and bias, and stop before outreach.

Why this matters

Highly engaged users can reveal durable product value, emerging workflows, and research candidates. Raw event count is a poor proxy: background jobs, pageviews, API polling, large accounts, and billing events can dominate a leaderboard without representing deeper value.

Define the unit and value events before querying. Keep identities pseudonymous until a separately authorized human workflow genuinely needs contact details.

What you get

A reviewed definition of meaningful engagement
Pseudonymous user or account rankings for an exact period
Component counts, not just an opaque score
Bias and coverage notes plus a human decision about any follow-up

Walk through it

You

Which accounts used our core workflow most deeply this month?

Agent

I need the approved value events, ranking unit, and period. I will not use emails or treat billing events as engagement by default.

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/projects/:project_id/event-names
GET /v1/projects/:project_id/event-property-keys?events=product_value_completed

Run a bounded owner-side aggregate query after the definition is fixed:

Endpoint: POST /v1/projects/:project_id/analytics/query
Query plan:
  - bind the exact period and selected product-value events
  - group by stable pseudonymous account_id or distinct_id
  - return component event counts and active days
  - apply the reviewed weighting rule, if any
  - exclude internal, test, synthetic, and automation traffic
  - return no email, name, message body, or unrelated profile property

{
  "rows": [
    {
      "account_id": "acct_opaque_1",
      "active_days": 19,
      "value_events": 84,
      "value_types": 3,
      "reviewed_score": 112
    }
  ]
}

The output

Engagement review — <exact period>

Definition
- unit: account
- value events: <list>
- weighting: <formula or none>
- exclusions: <internal/test/automation>

Top evidence rows
1. <pseudonymous account> — <components and score>
2. <pseudonymous account> — <components and score>

Coverage and bias
- <missing clients, account-size effect, automation, identity gaps>

Human follow-up decision
- research candidate | customer-success review | no action

An account being active does not prove satisfaction, willingness to pay, or permission to contact. Resolve identity only after a reviewer selects a valid purpose and confirms the appropriate customer relationship and channel.

Setting it up

Use stable pseudonymous identifiers and send only the properties needed for the analysis. Define value events from real product logic—for example, a report delivered, workflow completed, integration used successfully, or API outcome returned—not generic pageviews or every request.

Record internal, test, synthetic, and automation traffic so it can be excluded. Do not copy email addresses into every analytics event merely to make rankings convenient.

Variations

“Rank accounts by distinct value workflows, not total event count.”
“Compare this month’s top cohort with last month’s using the same frozen definition.”
“Show only pseudonymous accounts with activity across at least five separate days.”
“Prepare a research-candidate list for human review; do not resolve identities yet.”

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.