Agent Analytics Skill

Use the regular Agent Analytics skill when you want your AI agent to operate Agent Analytics end-to-end from the product codebase it is already editing.

The skill starts from the Projects, Surfaces, and Portfolios model. Before setup, analytics reads, or instrumentation recommendations, the agent should classify whether the target is project-local work, a surface inside a project, or related-project portfolio work.

It is the right first skill for setup, tracking, reporting, funnels, session paths, and normal experiment work. Use Closed-loop growth analysis as the normal full-loop analysis recipe when you want the agent to diagnose activation drop-off, choose one narrow experiment or readiness fix, and read the result later. If you want the agent to generate and judge growth variants before an A/B test, use the Autoresearch Growth Skill after the basic analytics loop works.

Install

Install from the public skill repo:

npx skills add agent-analytics/skills

If the installer asks which skill to install, choose agent-analytics.

You can also install it explicitly:

npx skills add agent-analytics/skills --skill agent-analytics

The source is public:

What To Ask Your Agent

Start in the codebase or site you want to measure, then ask:

Set up Agent Analytics for this project. If browser approval is needed, open it and wait for me. I will sign in with Google or GitHub and approve it. Ask for a finish code only if the browser callback cannot resume you. Then create or identify the matching Agent Analytics project, ask me to confirm the initial product goal before storing durable context, install the project-owned tracker, add only meaningful custom events tied to this repo's product workflows and that goal, explain what each event enables, and verify the first useful event.

After setup, ask normal analytics questions in plain English:

How did this site perform in the last 7 days?

Show the funnel from page_view to signup_cta_click to signup.

Create an experiment for the signup CTA with control and a clearer variant, then show me how to QA both versions before it gets traffic.

Classify scope before setup or reads

The canonical model is covered in Projects, Surfaces, and Portfolios. The short version for agent workflows:

A project is the unit of local product learning: events, activation, retention, lifecycle, releases, experiments, and local goals belong here.
A project can include many surfaces, including app pages, docs, blog, pricing, signup/onboarding, mobile clients, subdomains, local previews, and deploy previews.
A portfolio is the cross-project growth system for related projects. Use it for related-project grouping and shared interpretation without collapsing project-local truth.
Cross-project identity is available only when configured within intentionally grouped portfolio projects. Do not imply automatic identity merging across every project in an account.

Decision rules the skill teaches:

Subdomains are usually surfaces inside one project when they share the same product learning loop.
Mobile apps and free tools stay surfaces when they support the same product readout, but become separate projects when they have their own activation, retention, lifecycle, release cadence, experiments, acquisition loop, or local goals.
Localhost, staging, branch previews, and deploy previews are setup or QA surfaces for the intended project, not canonical project identities.
Separate products under one company should be separate projects under one portfolio when each needs its own local readout.
A domain mismatch is recoverable. The agent should clarify the intended project and surface instead of failing immediately.

Command scope follows the model: use project commands for project-local work, portfolios commands for related-project grouping, and portfolio context only for shared goals, roles, and milestones across related projects.

What The Skill Does

The skill teaches the agent to use the official Agent Analytics CLI and API patterns without making you hand-write requests.

Typical jobs:

classify the setup or read target as project-local work, a surface inside a project, or related-project portfolio work before taking action
infer goal and event candidates from the product code and workflow context
create or find the right project
install tracker.js
add only the first useful declarative events such as CTA clicks
verify the first useful recommended event
inspect pages, events, funnels, retention, and bot traffic
store compact project goals, activation events, and event-name glossary context so later analytics reads include the product meaning
store date annotations for major landing page, pricing, onboarding, feature, release, or experiment changes
store account-level portfolio context for shared goals, surface roles, and milestones across multiple related sites or projects
create, QA, measure, and complete experiments
explain gaps in the data before recommending action

Browser approval is the normal login path. Setup, paid upgrade, and resumed agent work do not require an API key.

When a product has its own activation definition, human vocabulary, or major shipped changes, ask the agent to keep project context updated. The skill tells the agent to check properties or properties-received first, then use context set with short entries tied to real event names through event_name. It can also add date annotations with occurred_at, title, and optional note when the user changes pricing, ships a feature, updates onboarding, changes a landing page, starts an experiment, or makes another meaningful product change. That context is returned as project_context on project-scoped analytics results, so future reads can explain metrics in the product’s own language without carrying a long prompt.

Annotations are intentionally not a git changelog. Keep them sparse, do not store PII or secrets, and use them only for changes that could explain graph movement later.

When many related projects or surfaces work together, also ask the agent to maintain portfolio context. Portfolio context is account-level memory for shared goals, surface roles, and cross-project milestones such as qualified_click_to_product, signup, or first_recommended_event_verified. Use project context for project-local truth and portfolio context for the shared growth system across a landing page, docs site, directory, product app, or ecosystem surfaces.

For OpenClaw and similar managed runtimes, tell the agent to keep Agent Analytics CLI auth in a persistent workspace path instead of the default home config path:

export AGENT_ANALYTICS_CONFIG_DIR="$PWD/.openclaw/agent-analytics"
npx --yes @agent-analytics/[email protected] auth status

If the runtime may not preserve exported variables between commands, prefix each Agent Analytics CLI command with that same AGENT_ANALYTICS_CONFIG_DIR=... value or pass --config-dir "$PWD/.openclaw/agent-analytics". Do not commit .openclaw/agent-analytics/config.json.

When To Use The Autoresearch Skill Instead

Use Autoresearch Growth Skill when the task is not just “read analytics” or “create an experiment,” but:

generate landing-page, onboarding, pricing, or CTA variants
critique generic copy and product-truth drift
blind-rank multiple candidates
output two review-ready experiment variants
rerun the loop after experiment data comes back

In practice, the regular skill gets the analytics foundation working. The autoresearch skill uses that foundation to run a structured growth loop.