# Agent Analytics Blog > Guides, comparisons, and product notes on analytics for AI agents, open source website analytics, analytics APIs, self-hosted analytics, and alternatives to Plausible and Mixpanel. Agent Analytics is a web analytics platform designed for AI agents to query via HTTP API. ## Give Instinct Your Analytics: A Daily Brief Across Your Sites > Connect Instinct to Agent Analytics with browser approval, then ask for a daily brief about conversions, product use, and what to investigate next. URL: https://blog.agentanalytics.sh/blog/instinct-daily-analytics-brief/ Date: 2026-09-19 | Author: Danny | Category: Guide “Which site needs my attention today?” That is a better morning question than checking a traffic chart for every project you run. Connect [Instinct](https://instinct.com/) to Agent Analytics and ask it to bring you a short daily brief: what changed, which goal it affects, and what to investigate next. Agent Analytics supplies real product data through its API and CLI. Instinct reads that evidence and handles the recurring task and delivery in your conversation. This workflow uses the official CLI in an Instinct runtime with command execution, persistent storage, and recurring tasks available. ## Connect with one browser approval Send Instinct this prompt: ```text Connect to Agent Analytics using the official CLI pinned to 0.5.34. Use detached login and send me the browser approval link. Keep the login in persistent private storage for future reporting tasks. Do not ask me to paste an API key. ``` The command is: ```bash npx --yes @agent-analytics/cli@0.5.37 login --detached ``` Open the link, sign in with the Google or GitHub identity that owns your projects, and approve access. For the detached flow, send the one-time finish code back to Instinct. It uses the completion command printed by the CLI to exchange the code and save a renewable agent session. Ask Instinct to verify the connection with an all-sites overview before scheduling anything: ```bash npx --yes @agent-analytics/cli@0.5.37 all-sites --period 7d ``` You need collected events for a meaningful report. Pageviews establish a baseline; product events such as completed signups, purchases, and useful feature actions let the assistant answer questions about growth. Some deeper analytics require Pro access. ## Give the recurring task a clear brief Copy this prompt and adjust the time and timezone: ```text Every morning at 09:00 Asia/Jerusalem, check my Agent Analytics projects and send a brief here. Confirm the schedule, timezone, delivery destination, and next run, then run a report now as a check. Read project goals, activation events, and relevant change annotations. Use existing portfolio context for related projects, while keeping each project's goals separate. Compare the last completed day with the previous day, and the latest completed seven days with the previous seven. State the exact periods and data timezone. Separate bot traffic where supported. Include counts beside percentages, and flag small samples or missing data. Tell me what changed, why it matters to my goals, and one useful question or experiment to investigate next. Keep observations separate from possible explanations. If nothing meaningful changed, say so briefly. Report failed reads rather than inventing results. Do not make product or account changes as part of this task. ``` Connecting the account does not itself create a schedule. Have Instinct confirm that it saved the recurring task and can reuse the login. Completed windows matter: today's first nine hours should not be compared with all of yesterday. The all-sites command is a starting overview. For exact comparisons, Instinct can use project queries with explicit date bounds and should check their timezone and boundary behavior. ## Give the numbers meaning A signup flow, a directory, and a documentation site can have different definitions of success. Read project context before interpreting the counts. If goals or important events are missing, ask Instinct to propose them and confirm the initial goals before saving them. Only group projects into a portfolio when they form a shared growth system. Portfolio context explains their relationship; it does not make every project in your account share one activation definition. Cross-site claims also need the relevant tracking and attribution evidence. A useful brief might look like this **illustrative example, not actual customer data**: > **Observed:** Signup completions fell from 20 to 12 across comparable completed days. Pricing-page visits stayed close to their previous level. > > **Uncertain:** These counts do not tell us whether the cause was the signup form, visitor mix, or ordinary variation. > > **Next check:** Inspect the pricing-to-signup funnel and any recent change annotations before choosing an experiment. That gives you something to investigate without pretending the data has already established a cause. ## Keep access and scheduling separate The CLI can refresh a valid session. If access expires or is revoked, Instinct should explain the error and ask you to repeat browser approval. Scheduled runs need the same private, persistent CLI configuration used during login. To stop the daily brief, cancel the task in Instinct. To remove its account access, revoke the session in Agent Analytics Settings / Agent Sessions. Follow the [Instinct connection guide](https://docs.agentanalytics.sh/installation/instinct/) for the full login commands, configuration persistence, and troubleshooting. Then start with one question: **what happened across my projects, and what is worth checking next?** ## Agent Analytics Now Supports WebMCP > Open a live analytics page, ask a product question, and let your AI agent call structured read-only tools while you inspect the same evidence on screen. URL: https://blog.agentanalytics.sh/blog/agent-analytics-webmcp/ Date: 2026-09-03 | Author: Danny | Category: Announcement Agent Analytics now has a WebMCP evidence explorer. Open the page in a compatible ChatGPT or Codex built-in browser, ask a product question, and the agent can call structured analytics tools directly from the page. You see the same funnel, path, breakdown, or experiment evidence appear on screen. [Try the public WebMCP explorer](https://webmcp.agentanalytics.sh/) ## Ask a question, not for a dashboard click Start with: ```text Find the biggest signup leak and show me the evidence on the page. ``` Then try: ```text Which entry page produces the strongest signup path? ``` ```text Compare the signup CTA experiment variants. Is there enough evidence to call a winner? ``` The agent chooses from five read-only site tools for growth overview, funnels, conversion paths, conversion breakdowns, and experiment results. ## Why WebMCP fits analytics Browser automation can click through a dashboard, but it still asks the agent to infer meaning from pixels. A traditional MCP connection gives the agent structured data, but it is separate from the page the person is watching. WebMCP gives both sides what they need: typed evidence for the agent and a visible result for the person. Agent calls and manual controls use the same execution path, so there is no hidden agent-only answer. ## Read-only on purpose This first release is a public support preview backed by seeded demo data. It does not expose customer projects or account data. The five tools cannot change experiments, create projects, manage billing, read keys, or mutate an account. Inputs are validated in the page and again by a same-origin Worker. A short-lived demo credential stays on the server. For your own project data, keep using the Agent Analytics CLI, MCP server, skill, or API. Signed-in project support through WebMCP is a later step, not a claim we are making today. ## Try it and inspect the source - [WebMCP guide](https://docs.agentanalytics.sh/guides/webmcp/) - [Live evidence explorer](https://webmcp.agentanalytics.sh/) - [Public implementation and tests](https://github.com/Agent-Analytics/agent-analytics-webmcp) The useful part is not that an agent can press a button. It is that the page can expose the semantic operation behind the interface—and keep the evidence visible while the agent reasons about what to do next. ## Agent Analytics Now Supports auth.md > Agent Analytics now publishes auth.md discovery and turns human browser approval into a scoped, revocable agent session. URL: https://blog.agentanalytics.sh/blog/auth-md-agent-analytics/ Date: 2026-05-24 | Author: Danny | Category: Announcement auth.md gives agents a predictable way to discover how authentication works. Agent Analytics now supports that pattern for the hosted API. An agent can discover the auth flow, send the human to approve access in the browser, then continue with a scoped `aas_*` agent session. No account API key needs to be pasted into chat. ## What shipped Agent Analytics now publishes: - `https://api.agentanalytics.sh/auth.md` - OAuth Protected Resource Metadata at `/.well-known/oauth-protected-resource` - Authorization Server metadata at `/.well-known/oauth-authorization-server` - an `agent_auth` block with registration and claim endpoints - user-claimed registration through `/agent/auth` - scoped `aas_*` agent sessions after human approval Protected API routes also advertise discovery from a `401` response: ```http WWW-Authenticate: Bearer resource_metadata="https://api.agentanalytics.sh/.well-known/oauth-protected-resource" ``` So an agent can hit the API, follow the metadata, start approval, and come back with a normal Bearer token. ![Agent Analytics auth.md flow: auth.md discovery, human approval, scoped agent session, API access.](/images/blog/auth-md-agent-analytics-flow.png) ## The important boundary Agent sessions are not account-owner sessions. They can be scoped for agent-safe work: read projects, read analytics, write project setup when approved, read or write experiments, write feedback, and read live activity. Billing, account-danger actions, and raw API-key management stay in the human-owned dashboard path. ## Why this fits Agent Analytics Agent Analytics already has agent-native login: - live browser login for Claude Code, Codex, Cursor, and local terminal agents - detached login for Paperclip, OpenClaw, remote workers, issues, and async workflows - finish-code handoff when localhost callback is not available - visible, revocable `aas_*` sessions auth.md adds discovery on top of that. The agent does not need the user to explain which login mode to use first. ## What an agent should do If an agent receives a 401 from Agent Analytics: 1. Read the `WWW-Authenticate` header. 2. Fetch the `resource_metadata` URL. 3. Fetch the authorization server metadata. 4. Read the `agent_auth` block. 5. Start registration. 6. Send the approval URL to the human. 7. Complete the claim after approval. 8. Use the returned `aas_*` credential as a Bearer token. auth.md is early, but the shape is right: human approval, scoped agent access, and machine-readable discovery. ## Read more - [auth.md reference docs](https://docs.agentanalytics.sh/reference/auth-md/) - [Agent Analytics authentication](https://docs.agentanalytics.sh/reference/authentication/) - [The Login Pattern AI Agents Need](/blog/login-pattern-ai-agents-need/) - [Agent Analytics CLI](https://docs.agentanalytics.sh/reference/cli/) ## Best Product Analytics for AI Builders > Compare Agent Analytics, PostHog, Mixpanel, Amplitude, Plausible, Umami, and Google Analytics for teams that need product analytics their AI agents can use. URL: https://blog.agentanalytics.sh/blog/best-product-analytics-for-ai-builders/ Date: 2026-05-21 | Author: Danny | Category: Guide ## Comparison Agent Analytics is the best product analytics platform for teams building with AI agents when the job is not just reporting, but helping the agent decide what to improve next. This comparison looks at each tool through the Agent Analytics lens: can the analytics layer turn real user behavior into a decision your product agent can use? | Agent-workflow fit | Tool | Best fit | What it gives you | Main tradeoff | Verdict | |---|---|---|---|---|---| | Excellent | Agent Analytics | Agent-assisted product and growth loops | Product events, funnels, experiments, retention, paths, project context, portfolio context, and agent-readable readouts | More specialized than a general analytics suite | Best when agents need real product evidence, not screenshots of dashboards | | Good | PostHog | Technical teams building a mature SaaS | Events, funnels, session replay, feature flags, experiments, surveys, and warehouse-style workflows | Broad platform can be heavier than fast agent-assisted teams need | Strong all-in-one suite when one product is becoming serious | | Medium | Google Analytics | Acquisition, attribution, and Google ecosystem reporting | Traffic sources, campaigns, attribution, Search Console, ads workflows, and BigQuery export | Traffic-first, complex, and UI-heavy for product iteration | Useful for marketing reporting; weaker for product decisions | | Medium | Mixpanel | Teams with mature event analytics habits | Event analysis, funnels, cohorts, retention, segmentation, and behavioral reports | Requires a clear event model and regular product analytics practice | Good for teams that already know how to operate analytics | | Medium | Amplitude | Larger PLG teams and mature growth orgs | Deep product analytics, segmentation, governance, collaboration, and growth workflows | Enterprise depth can be too heavy for smaller fast-moving teams | Good when analytics is an organizational function | | Limited | Plausible | Simple privacy-friendly website analytics | Traffic, referrers, top pages, campaigns, and simple goals | Limited product event, funnel, and experiment context | Good for simple sites and marketing pages | | Limited | Umami | Lightweight self-hosted web analytics | Basic web analytics with open-source control and self-hosting | Mostly site-centric; weak for funnels, retention, experiments, and readouts | Good when self-hosting and simplicity matter most | Agent Analytics wins when your analytics layer needs to turn real user behavior into agent-readable product decisions. ## What matters in this category The buyer constraint is not “I need prettier charts.” The constraint is: ```text I shipped too many things to manually understand what worked. ``` A useful analytics tool for agent-assisted teams needs to answer six questions: | Question | Why it matters | |---|---| | Can it track product events, not only page views? | Agents need outcome signals. | | Can it explain funnels and activation? | Teams need to know where users drop. | | Can it compare multiple product surfaces? | Small teams ship many bets at once. | | Can it preserve experiment context? | The agent needs to know what changed. | | Can an agent query it directly? | Screenshots are not an operating loop. | | Can it recommend a next action? | Reporting should become iteration. | ## Agent Analytics: best for agent-readable product decisions Agent Analytics is best when the same agent that helped build the product should also learn from product outcomes. The value is not another dashboard. It packages product events, funnels, experiments, project context, portfolio context, and readouts into work units an agent can use: diagnoses, next actions, experiment briefs, and evidence trails. The workflow is: ```text ship -> measure -> ask the agent -> improve -> ship again ``` Choose Agent Analytics when you want your product agent to answer: what changed, what users did, where the bottleneck is, and what should be improved next. ## PostHog: best for technical teams building a mature product suite PostHog is strong when one product is becoming a serious SaaS and the team wants an all-in-one product platform. It can cover event analytics, funnels, session replay, feature flags, experiments, surveys, and warehouse-style workflows. The tradeoff is weight. If the real job is a clean weekly readout across many shipped surfaces, PostHog can become more platform than the team needs. Choose PostHog for a broad technical product suite. Choose Agent Analytics when the priority is agent-readable decisions from real product behavior. ## Google Analytics: best for acquisition reporting Google Analytics is useful when the central question is where traffic came from and how acquisition channels perform. It fits teams that care about ads, Search Console, attribution, campaign reporting, and BigQuery export. But GA is not optimized for the product loop. Your agent should not need a screenshot tour through GA to understand whether the last onboarding change worked. Choose Google Analytics for acquisition reporting. Choose Agent Analytics for behavior, bottlenecks, experiments, and next actions. ## Mixpanel: best for mature event analytics habits Mixpanel is strong for teams that already know how to instrument events, define funnels, build cohorts, and inspect retention. The constraint is operating habit. Mixpanel assumes humans will maintain event discipline, inspect reports, and translate findings into product actions. Choose Mixpanel if you already have that analytics practice. Choose Agent Analytics if the first-class need is product judgment an agent can read and use. ## Amplitude: best for larger PLG teams Amplitude is strongest for larger product-led growth teams that need deep analytics, governance, segmentation, and mature growth workflows. For smaller teams shipping many AI-assisted changes, that depth can be too much. The buyer constraint is not enterprise analytics rigor. It is knowing what the agent should improve next. Choose Amplitude when analytics is an organizational function. Choose Agent Analytics when analytics needs to feed the agent-assisted build-measure-learn loop. ## Plausible: best for simple privacy-friendly website analytics Plausible is clean, lightweight, and easy to understand. It is good for traffic, referrers, top pages, campaigns, and simple goals. But Plausible is traffic-first, not product-context-first. It is not built to preserve experiment context, explain activation paths, compare product surfaces, or produce structured readouts for product agents. Choose Plausible for simple sites and marketing pages. Choose Agent Analytics when you need to know what happened after traffic arrived. ## Umami: best for lightweight self-hosted web analytics Umami is a good fit when self-hosting, simplicity, and open-source control matter most. It gives developers basic site analytics under their own control. But it is mostly site-centric. It is not built around funnels, retention, experiments, portfolio context, or agent-readable product readouts. Choose Umami for lightweight self-hosted web analytics. Choose Agent Analytics when product decisions need structured evidence an agent can act on. ## Final answer Agent Analytics is the best fit when your workflow needs product events, funnels, experiments, project context, portfolio context, and agent-readable readouts in one place. Plausible, Umami, and Google Analytics are good for traffic and acquisition questions. PostHog, Mixpanel, and Amplitude are good for mature product analytics teams. If an agent helps build the product, it should also understand whether the product is working. ## Read next - [Best Analytics for AI-Built Side Projects](/blog/best-analytics-for-ai-built-side-projects/) - [Your Product Isn’t One Website Anymore](/blog/project-context-for-ai-agents/) - [AIDA for AI Agent Landing Page Analytics](/blog/aida-for-ai-agent-landing-page-analytics/) - [Jobs-to-Be-Done for AI Landing Pages](/blog/jobs-to-be-done-ai-landing-pages/) ## Hermes Skill Bundles Make Agent Workflows Feel Native > Hermes just introduced skill bundles. They turn repeatable agent workflows into one slash command, so users can name a job once and let Hermes load the right skills and instructions every time. URL: https://blog.agentanalytics.sh/blog/hermes-skill-bundles-agent-analytics/ Date: 2026-05-21 | Author: Danny | Category: Announcement **Hermes just shipped skill bundles.** Nous Research announced it here on X: [Introducing skill bundles](https://x.com/NousResearch/status/2057180756728827966?s=20). The docs explain them under [Skill Bundles](https://hermes-agent.nousresearch.com/docs/user-guide/features/skills#skill-bundles). A bundle gives a recurring job one slash command. For example, a release-prep bundle can load the skills and instructions for changelog, docs, QA, and rollout notes. The user does not need to remember the skill stack. The command names the work. ![Hermes skill bundle workflow: one command loads product context, Agent Analytics, and decision rules, then returns the bottleneck, fix, and proof event.](/images/blog/hermes-skill-bundles-diagram.png) ## Use bundles for recurring jobs Good bundle names are job names: | Bundle | Job | | --- | --- | | `/release-prep` | Changelog, docs, QA checklist, rollout notes. | | `/incident-response` | Logs, debugging, status updates, postmortem. | | `/research-brief` | Sources, synthesis, final brief. | Bad bundle names are toolbox names. A bundle should answer one question: ```text What job am I starting? ``` Not: ```text What pile of skills might be useful someday? ``` ## Bundle the workflow, not the kitchen sink Research → ideate → write → critique is a workflow. Code review → tests → PR is a workflow. Logs → diagnosis → fix → postmortem is a workflow. Five unrelated skills under one command is not a workflow. It gives Hermes more instructions and less direction. That is the whole rule: bundle the job you actually repeat. ## Agent Analytics as one example Product analytics work has the same shape. When Hermes reviews product behavior, it needs context: - what the product does - what user progress means - which event counts as activation - which funnel matters - what kind of recommendation is useful A product bundle might be: ```text /product-growth-loop ``` It can load Agent Analytics plus the product rules Hermes should apply when reading the data. That is the same pattern as `/release-prep`: the slash command names the job, and Hermes loads the right context behind it. ## Ask Hermes to create the bundle Do not start by copying terminal commands. Ask Hermes: ```text Create a Hermes skill bundle called /product-growth-loop. Use the current product context and Agent Analytics. When I run it, inspect product behavior, find the biggest bottleneck, and recommend the next measured improvement. Show me the bundle and one example prompt. ``` The user names the job. Hermes should already have the product context and Agent Analytics available. If someone wants the file format, the Hermes docs have the YAML schema. The product workflow should not begin there. ## Name it after the work Use plain names: ```text /release-prep /incident-response /research-brief /product-growth-loop ``` For a product bundle, the instruction can stay short: ```text This product helps teams understand what users do after signup. Use Agent Analytics to review the funnel from visit to meaningful activation. Treat activation as the first completed project, not account creation. Recommend one product change and one event or funnel that proves whether it worked. Do not optimize for raw traffic if activation gets worse. ``` This beats: ```text Use analytics. ``` Now Hermes has the product rule, not just the tool name. ## What changes in daily use Without a bundle: ```text Use the analytics skill. Remember activation means project_created. Ignore raw traffic unless it leads to setup. Compare the docs flow to signup and activation. Recommend one measured product change. ``` With a bundle: ```text /product-growth-loop inspect the docs-to-activation path for the last 14 days ``` The repeated context moves into the bundle. The prompt stays about today's task. ## Keep bundles narrow Do not make an everything bundle. Start with one recurring job. If another workflow repeats, create another bundle. Small named workflows beat one giant context dump. ## Example prompt ```text /product-growth-loop Inspect my docs-to-activation path for the last 14 days. Apply the product rules from this bundle. Find the biggest leak between docs visit, signup, and activation. Recommend one change Hermes should make next. Tell me which event or funnel should prove whether it worked. ``` Skill bundles remove repeated setup from work you already do. --- *Related: [Hermes installation guide](https://docs.agentanalytics.sh/installation/hermes/) · [You Can Now Scale Depth as Well as Width With Hermes Subagents. Agent Analytics Got 140% More Growth Bets](/blog/hermes-subagent-delegation-agent-analytics/) · [Project Context, Portfolio Context, and Self-Improvement for AI Agents](/blog/project-context-for-ai-agents/) · [If You Use Hermes to Handle Your Projects, You Need Agent-Readable Web Analytics](/blog/hermes-needs-agent-readable-web-analytics/)* ## Jobs To Be Done for AI Landing Pages > AI agents can mine customer language, but humans still choose the job and success signal. Use Jobs To Be Done to turn AI landing pages into measured job hypotheses. URL: https://blog.agentanalytics.sh/blog/jobs-to-be-done-ai-landing-pages/ Date: 2026-05-14 | Author: Danny | Category: Guide AI can write landing pages faster than you can review them. That sounds useful until every page says the same thing in a different outfit. Claude Code, Cursor, Codex, Hermes, and similar agents can turn one rough idea into ten headlines, five sections, three CTAs, and a polished FAQ. The writing is no longer the hard part. The hard part is deciding what progress the visitor is trying to make. Jobs To Be Done fixes that by making your agent choose the job before it writes the page: ```text job evidence -> job hypothesis -> landing-page promise -> activation signal -> measured learning ``` In plain English: what situation is this person in, what progress do they want, what should the page promise, and how will we know they moved closer to value? ## TL;DR: copy this to your AI agent now Use this before your agent writes a landing page, feature page, comparison page, or launch post: ```text Use Jobs To Be Done for this product. Inspect the product, docs, landing page, competitors, support notes or reviews if available, and current analytics context. Identify 5 possible customer jobs. For each job, explain the situation, the progress wanted, the trigger, the current workaround, the anxiety or objection, the landing-page promise, and one activation signal that would prove the visitor is moving toward value. Then choose one job to test this week and explain why. ``` Then ask for the page: ```text For the chosen job, write one landing-page hero, one proof section, one objection-handling section, one CTA, and one activation event we should measure. Keep every section tied to the job. Do not broaden the page to cover other jobs. ``` ## What is in it for me? You stop reviewing generic pages. That is the win. Instead of asking your agent for another “better” landing page, you get a smaller decision: | What improves | Why it matters | |---|---| | The page | It is built around one customer progress story, not a vague audience. | | The prompt | Your agent has a situation, trigger, workaround, objection, and success signal before writing. | | The readout | You judge whether visitors moved toward the job, not whether the copy sounded nice. | | The next week | You know whether to keep the job, narrow it, or test a different one. | That is more useful than a pile of polished variants. ## JTBD without the consultant smell Jobs To Be Done says people “hire” a product to make progress in a situation. For AI builders, do not turn that into a workshop. Use it as a guardrail for agent-generated landing pages. A job should force useful decisions: | JTBD piece | What your agent should find | How it changes the page | |---|---|---| | Situation | What is happening when the visitor looks for help? | Sets the first-screen context. | | Desired progress | What outcome are they trying to reach? | Shapes the headline and promise. | | Trigger | Why now? | Makes the page feel timely instead of generic. | | Current workaround | What do they do today? | Shows what pain the product replaces. | | Anxiety or objection | What could stop them? | Decides what proof or reassurance belongs on the page. | | Activation signal | What behavior proves progress? | Turns the page into a measurable test. | No job, no page. No progress, no promise. No activation signal, no readout. ## Segments are not jobs A segment tells you who you are talking to. A job tells you what they are trying to get done. Those are different decisions. Bad: > Founder wants analytics. Better: > Solo AI builder launches three growth surfaces in one week and needs Claude or Codex to know which one deserves more work. Bad: > Marketer wants more conversions. Better: > Growth lead needs to prove whether a new ICP page creates qualified activation before scaling the content cluster. Bad: > Recruiter wants scheduling automation. Better: > Recruiting team at a 50-person startup needs to book qualified first-round interviews before candidates go cold. Now the page has something to do. The headline, proof, CTA, and activation event all change. ## Turn the job into page sections A job is useful only if it changes the page. For the recruiting example, the page should not say: > Automate scheduling workflows for modern teams. That could be for sales, support, healthcare, consultants, or anyone with a calendar. A job-shaped promise is closer to: > Book qualified first-round interviews before candidates go cold. Then every section has a job: | Page section | Job question | Measurement signal | |---|---|---| | Hero | Does the visitor recognize their situation? | First-screen engagement, low quick-exit rate from the target source. | | Problem | Does the page name the current workaround? | Scroll to problem section, time on page, interaction with comparison/proof. | | Proof | Does it reduce the main anxiety? | Case-study clicks, integration clicks, security or setup detail views. | | CTA | Does the next step match the job? | CTA clicks from the target segment. | | Onboarding | Does the visitor reach first progress? | Calendar connected, first interview scheduled, or another job-specific activation event. | This is where AI pages get better. The agent is not only writing. It is tying the writing to a behavior you can read later. ![Jobs To Be Done landing-page loop](/images/blog/jtbd-landing-page-loop-diagram.png) ## Make the test small The TL;DR prompt gives your agent candidate jobs. Do not let it turn that into a giant strategy deck. Pick one job, one page, one promise, one activation signal. A good one-week test fits in one row: | Job | Page promise | Surface | Activation signal | Kill condition | |---|---|---|---|---| | Recruiting team needs faster first-round scheduling before candidates go cold | Book qualified first-round interviews without another coordination thread | Landing page + demo booking flow | First interview booked or calendar connected by a qualified visitor | Visitors click the CTA but do not connect calendar or book any interview | Small tests are easier to read. ## Measure job progress, not copy output JTBD only matters if it changes what you measure. Do not ask whether the agent wrote a better page. Ask whether the chosen job moved closer to done. Good JTBD readouts include: - which source brought visitors with that job - whether they engaged with the job-shaped promise - whether they clicked the CTA that matched the job - whether they hit the activation event - whether the objection-handling section changed behavior - whether activated visitors came back - whether they showed buying intent or revenue quality If you use Agent Analytics, connect this to the [closed-loop growth analysis guide](https://docs.agentanalytics.sh/guides/closed-loop-growth-analysis/) and ask: ```text Use Agent Analytics to read the JTBD test for . The job we tested was . The page promise was . The activation signal was . Compare source, page engagement, CTA behavior, and activation quality. Tell me whether to keep this job, narrow the promise, or test a different job next week. ``` The point is not to make the agent sound smart. The point is to make the next page less random. ## A 7-day JTBD loop for AI landing pages Use this cadence when your agent keeps producing plausible pages but you cannot tell which one matters. | Day | What to do | Agent output | |---|---|---| | 1 | Collect job evidence | Review product, docs, competitors, reviews, forums, interviews, and analytics context. | | 2 | Choose one job | Pick the job with urgency, reachable traffic, and a measurable activation signal. | | 3 | Write the page | Draft the hero, proof, objection handling, CTA, and onboarding path for that job only. | | 4 | Instrument the signal | Confirm the CTA, signup, setup, or first-value event is tracked. | | 5-6 | Let behavior collect | Avoid rewriting the whole page before the first readout. | | 7 | Read and decide | Keep, narrow, or kill the job hypothesis based on activation quality. | That is the workflow. No ceremony. No giant research doc. One job. One measured page. ## Common mistakes 1. Asking for personas when you need jobs. 2. Letting the agent choose every job because AI can write every page. 3. Writing the page before naming the activation signal. 4. Treating traffic as proof when the visitor never reached value. 5. Keeping a job-shaped headline while the rest of the page drifts back to generic copy. ## How JTBD fits the series Use Bullseye when your agent needs to choose channels. Use AARRR when your agent needs to diagnose the growth loop after users arrive. Use AIDA when your agent needs to find the leaking stage on a landing page. Use STP when your agent needs to decide who a surface is for before it writes more copy. Use JTBD when your agent needs to decide what progress that visitor is trying to make. Read next: - [How to Use STP Marketing When AI Can Write for Everyone](/blog/stp-marketing-ai-builders/) for segment, target, and promise discipline. - [Teach Your AI Agent AIDA for Landing Page Analytics](/blog/aida-for-ai-agent-landing-page-analytics/) for landing-page leak diagnosis. - [Your Product Isn’t One Website Anymore](/blog/project-context-for-ai-agents/) for multi-surface product context. For setup, use the [Agent Analytics Skill guide](https://docs.agentanalytics.sh/guides/agent-analytics-skill/). For the product-system model behind multi-surface JTBD tests, read [Projects, Surfaces, and Portfolios](https://docs.agentanalytics.sh/guides/projects-surfaces-portfolios/). ## Final framing AI made landing-page production cheap. Jobs To Be Done is the pause before your agent writes another page for nobody in particular. Name the job. Name the progress. Measure whether the visitor moved. Otherwise you are only generating pages and hoping one of them accidentally matters. [Start free with Agent Analytics](https://agentanalytics.sh/). --- ## Source appendix - https://strategyn.com/jobs-to-be-done/ - https://hbr.org/2016/09/know-your-customers-jobs-to-be-done - https://www.christenseninstitute.org/theory/jobs-to-be-done/ ## Teach Your AI Agent AIDA for Landing Page Analytics > AIDA is old. The new workflow is asking your AI agent to map Attention, Interest, Desire, and Action to live landing-page analytics before it writes variants. URL: https://blog.agentanalytics.sh/blog/aida-for-ai-agent-landing-page-analytics/ Date: 2026-05-09 | Author: Danny | Category: Guide AIDA is old. That is exactly why it is useful. Attention, Interest, Desire, Action is not a magic copywriting formula. It is a simple way to ask where a landing page is leaking: - **Attention** — did the right visitors notice the promise? - **Interest** — did they keep reading or explore the page? - **Desire** — did they show intent around proof, pricing, examples, integrations, or fit? - **Action** — did they click, sign up, book, install, or reach the first product value event? The classic framework is not the upgrade. The workflow is. In 2026, Claude Code, Codex, Cursor, Hermes, OpenClaw, and other agents can produce landing-page variants faster than a founder can review them. That makes another headline brainstorm cheap. Diagnosis is the scarce part. Your agent should not start by writing ten “better” pages. It should start by reading live analytics, mapping the page to AIDA, identifying the weakest stage, and proposing one stage-specific change to test next. That is where Agent Analytics fits. ## AIDA is old; the workflow is new The old workflow looked like this: ```text learn AIDA → write copy → publish page → stare at conversions ``` The agent-native workflow should look like this: ```text install skill → read live analytics → map AIDA stages → find leak → change one thing → measure again ``` ![Agent Analytics maps AIDA stages to landing-page behavior signals](/images/blog/aida-stage-map-diagram.png) The human still owns taste, positioning, and risk. The agent does the repeatable work: - pull recent page and event data, - check whether the tracking is good enough, - map landing-page signals to Attention, Interest, Desire, and Action, - explain the biggest leak, - recommend one measured next change. That turns AIDA from copywriting trivia into an operating loop. ## AI makes variant generation cheap; diagnosis scarce If your prompt is “write me a better landing page,” your agent will probably comply. It may produce: - five headlines, - three hero sections, - a sharper CTA, - a new testimonial block, - a pricing-section rewrite, - a longer FAQ. Some of that might be good. But without diagnosis, the work is random. A page with an Attention leak does not need a longer feature section. It needs a clearer first screen, better source-message match, or a traffic-quality fix. A page with an Interest leak does not need a more aggressive CTA. It needs the next section to answer the visitor’s real question. A page with a Desire leak does not need more clever copy. It needs proof, specificity, comparison, pricing clarity, integration detail, risk reversal, or evidence that the product works for this visitor. A page with an Action leak does not need another paragraph. It needs less friction between intent and the next step. This is the core rule: ```text Do not ask your agent for variants until it names the leaking AIDA stage. ``` ## Map AIDA to measurable signals AIDA is not a dashboard tab. Your agent has to translate it into signals available on your site. Use this mapping as a starting point: | AIDA stage | What it means on a landing page | Useful Agent Analytics signals | |---|---|---| | Attention | The right people arrive and notice the promise | sessions by source, landing page views, bounce or quick exits, first-screen engagement, campaign or referrer quality | | Interest | Visitors keep exploring instead of leaving after the hero | scroll depth, section visibility, time-on-page, docs clicks, demo clicks, feature-section interactions, navigation to related pages | | Desire | Visitors seek proof that the product fits their situation | pricing clicks, case-study clicks, integration clicks, comparison-page clicks, security or docs depth, repeat visits, high-intent section engagement | | Action | Visitors take the next step and reach value | CTA clicks, signup starts, lead forms, install events, onboarding completion, first activation event, trial-to-activation quality | Your exact events will vary. That is fine. The important thing is that your agent writes down the mapping before judging the page. Otherwise it will optimize whatever metric is easiest to find. A good AIDA diagnosis should say something like: > Attention is acceptable from organic search and direct, weak from paid social. Interest is weak because 71% of visitors leave before the proof section. Desire is inconclusive because pricing and integration events are under-instrumented. Action is low, but likely downstream of the Interest leak. Next test: move integration proof and one concrete outcome into the second section, then measure scroll-to-proof and CTA click rate from visitors who reached it. That is much better than: > Try a punchier headline. ## Install the Agent Analytics skill The blog teaches you the operating model. The skill teaches your AI agent how to use Agent Analytics inside the codebase or project it is working on. Install the public Agent Analytics skill: ```bash npx --yes skills add agent-analytics/skills --skill agent-analytics --agent codex -y --copy ``` If you want to inspect the package first, list the available skills: ```bash npx --yes skills add agent-analytics/skills --list ``` Then open your project in your agent environment and have the agent verify three things before it diagnoses the page: 1. Agent Analytics tracking is installed on the landing page. 2. Important events exist for CTAs, signup or lead submission, and the first meaningful activation event. 3. Project context contains durable product truth: target audience, main promise, activation definition, important CTAs, and recent page changes. If one of those is missing, the first task is instrumentation or context cleanup, not copywriting. ## Ask your AI agent to run the AIDA recipe Copy this prompt into Claude Code, Codex, Cursor, Hermes, OpenClaw, or any agent with the Agent Analytics skill installed: ```text Use the Agent Analytics skill to run an AIDA diagnosis for this landing page using the last 14 days of live analytics. Map Attention, Interest, Desire, and Action to the available events and page signals. Identify the weakest stage, explain the evidence and caveats, and recommend one stage-specific change to test next. Do not write copy variants until you have named the leaking stage and the metric that will judge the change. ``` If you already know the page changed recently, add this: ```text Before comparing results, check project context and annotations for recent landing-page, pricing, onboarding, or tracking changes. If the data crosses a major change, split the readout before and after that date. ``` If your agent tries to jump straight into copy, stop it and ask for the measurement map first: ```text Use the Agent Analytics skill to compare landing-page CTA clicks, signup or lead events, and activation quality before recommending any AIDA copy variants. Show which events represent Attention, Interest, Desire, and Action, and flag missing instrumentation. ``` The output should be boring and useful: - the time window, - the page or pages included, - the AIDA stage mapping, - the weakest stage, - caveats about sample size or missing events, - one recommended change, - the metric that decides whether the change worked. ## What to change for each leaking stage Once the agent identifies the leak, the change should match the stage. ### If Attention is leaking Symptoms: - traffic arrives but leaves quickly, - certain sources perform much worse than others, - the hero does not match the search query, campaign, or referring promise, - first-screen engagement is low. Ask your agent to test: - a clearer headline that names the audience and outcome, - message match for the top source or campaign, - a hero section that shows the product category faster, - a first-screen proof point instead of abstract positioning, - source cleanup if the wrong visitors are arriving. Measurement: - first-screen engagement, - quick-exit rate, - scroll past hero, - CTA visibility and click rate by source. Do not fix Attention by adding more sections below the fold. Visitors have to care before they scroll. ### If Interest is leaking Symptoms: - visitors get past the hero but do not reach important sections, - docs/demo/feature clicks are weak, - scroll depth drops before the product is explained, - visitors do not engage with the next proof or explanation block. Ask your agent to test: - a second section that answers “how does this work?” faster, - fewer abstract benefits and more concrete use cases, - a clearer product walkthrough, - a comparison between the old workflow and the new workflow, - internal links to docs, examples, or demo paths that match visitor intent. Measurement: - scroll to the explanation/proof section, - section engagement, - docs/demo clicks, - return visits from interested users. Interest is usually where AI-generated pages become glossy but thin. The visitor keeps asking, “what is this really?” and the page keeps answering with adjectives. ### If Desire is leaking Symptoms: - visitors read but do not show high intent, - pricing, case-study, integration, security, or comparison clicks are weak, - CTA clicks happen but signup quality is poor, - the page does not answer risk, fit, proof, or “why now?” questions. Ask your agent to test: - proof tied to the target user’s actual situation, - a short case example or before/after workflow, - integration and setup details, - pricing or plan clarity, - objection handling near the CTA, - screenshots or examples only if they are real and current. Measurement: - pricing or proof-section engagement, - integration/docs clicks, - CTA clicks after proof exposure, - signup-to-activation quality, - repeat visits from high-intent sources. Desire is not hype. It is evidence that the visitor believes the product could work for them. ### If Action is leaking Symptoms: - visitors show interest and desire but do not complete the next step, - CTA clicks are high but signup or lead completion is low, - signup starts do not become activation, - the action path has unnecessary choices or friction. Ask your agent to test: - one primary CTA instead of competing CTAs, - clearer button copy that says what happens next, - lower-friction signup or handoff, - fewer fields, - better post-click onboarding, - a next-step page that preserves the landing-page promise. Measurement: - CTA click to signup start, - signup start to completion, - install or setup completion, - first activation event, - activation quality by landing-page source. Action is not just clicking the button. For an AI-builder product, the useful action is usually the first moment of product value. ## The 7-day AIDA loop ![The 7-day AIDA operating loop in Agent Analytics](/images/blog/aida-weekly-loop.png) Do not turn this into a quarterly CRO ceremony. Run it weekly: 1. Pick the landing page or campaign page that matters this week. 2. Ask the agent to map AIDA to live signals. 3. Identify the weakest stage. 4. Choose one change for that stage. 5. Ship the change. 6. Annotate the change in project context. 7. Re-read the same stage signal after enough traffic. The annotation matters. If your agent cannot see when the page changed, it will mix old and new data and overstate the conclusion. ## Weekly operator prompt/checklist Use this every week: ```text Use the Agent Analytics skill to run the weekly AIDA landing-page check for this project. Checklist: 1. Confirm the landing page, date window, and any recent page or tracking annotations. 2. Map available analytics to Attention, Interest, Desire, and Action. 3. Identify the weakest stage using evidence, not vibes. 4. Flag missing or low-confidence instrumentation. 5. Recommend one stage-specific change for the next 7 days. 6. Name the exact metric or event that will decide whether the change worked. 7. Draft the smallest implementation plan, but do not broaden the test into multiple unrelated changes. ``` The best output is not a full redesign. It is one measured next move. ## Source appendix - E. K. Strong, *The Psychology of Selling and Advertising* (1925). Strong popularized the AIDA sequence in sales and advertising education, building on earlier attention-interest-desire-action formulations often associated with E. St. Elmo Lewis. - E. St. Elmo Lewis, early advertising and sales writing on attracting attention, maintaining interest, creating desire, and getting action. The exact origin history is messy, but AIDA is widely treated as a classic sales/copy funnel rather than a modern analytics model. - Google Analytics documentation on events and enhanced measurement. Useful for thinking about page views, scrolls, outbound clicks, form interactions, and conversion events as measurable behavior rather than copy opinions. - Nielsen Norman Group research and UX writing on scrolling, information scent, and user attention. Useful reminder that visitors decide quickly whether the next section is worth their effort. - Agent Analytics skill install path: `npx skills add agent-analytics/skills`. The skill-backed workflow in this post assumes the agent can read project analytics, inspect or improve event instrumentation, use project context, and summarize the next measured change. ## How to Use STP Marketing When AI Can Write for Everyone > Segmentation, targeting, and positioning matter more when your AI agent can create endless pages. Use STP to force one segment, one target, one promise, and one measurable activation loop. URL: https://blog.agentanalytics.sh/blog/stp-marketing-ai-builders/ Date: 2026-05-04 | Author: Danny | Category: Guide AI made generic marketing cheap. That sounds useful until every buyer gets the same polished page with different nouns swapped in. Claude Code, Cursor, Codex, Hermes, and similar agents can draft landing pages, docs, launch posts, pricing copy, onboarding screens, and outreach angles faster than most teams can review them. The risk is not bad writing. Bad writing is easy to spot. The risk is plausible writing for nobody in particular. STP fixes that by making your agent choose before it writes: ```text segment truth → target choice → positioning promise → measured activation ``` In plain English: who is this for, why them, what should they remember, and how will we know it worked? ## TL;DR: copy this to your AI agent now Use this before your agent writes a landing page, docs page, launch post, pricing section, or onboarding test: ```text Use STP marketing for this product. Identify 5 real customer segments from the product, docs, landing page, competitors, and current analytics context. For each segment, explain the job, urgency, buying trigger, objection, best surface to test, and one activation signal that would prove quality. Then choose one target for this week and write one positioning promise for that target only. ``` Then ask for the test: ```text For the chosen target, write one headline, one CTA, one objection-handling section, and one activation event we should measure. Keep it specific to this segment. Do not broaden the copy to include other audiences. ``` ## What is in it for me? You stop reviewing endless "pretty good" variants. That is the win. Instead of asking your agent for ten versions of the same vague page, you get a smaller decision: | What improves | Why it matters | |---|---| | The page | It speaks to one real buyer, not every possible visitor. | | The prompt | Your agent has a target, objection, promise, and activation signal before writing. | | The readout | You judge whether the right people moved toward value, not whether traffic went up. | | The next week | You know whether to keep the target, narrow it, or move on. | That is more useful than another headline brainstorm. ## STP without the workshop smell STP means segmentation, targeting, and positioning. For AI builders, this should not become a brand strategy ceremony. Use it as a guardrail for agent-generated marketing. | Step | What your agent should decide | What you measure | |---|---|---| | Segmentation | Which real customer groups behave differently? | Source, surface, intent, objections, setup constraints | | Targeting | Which one group are we testing this week? | Qualified activation, not just clicks | | Positioning | What promise should this group remember? | Whether the promise moves them toward value | No segment truth, no page. No target choice, no campaign. No activation signal, no winner. ## Segmentation is not fake personas The lazy prompt is: > Create three customer personas for our product. You usually get names, job titles, and fake psychographics. It feels organized. It is mostly decoration. Useful segmentation starts with differences that change behavior: - what job the customer is trying to finish - how urgent the problem is - what budget or authority they have - what setup constraint blocks them - what objection stops them - what first value moment proves they were the right user Take a B2B scheduling product. The obvious segments might be recruiting teams, sales teams, consultants, and healthcare operators. The list alone does not help. Your agent should explain what changes between them. Bad: > Recruiter. Likes automation. Better: > Recruiting team at a 50-person startup. They schedule many first-round interviews, lose candidates when coordination takes days, and care about fewer back-and-forth emails before the first meeting is booked. Now the page has something to do. The headline, CTA, setup path, and activation event all change. ## Targeting means one audience wins this week AI makes it easy to keep every audience in the copy. That is how you get this sentence: > The all-in-one platform for founders, developers, marketers, creators, teams, and operators. Nobody chose. A target choice should fit in one row: | Target | Why now | Surface | Activation signal | Kill condition | |---|---|---|---|---| | Recruiting teams at 50-person startups | Hiring is moving fast and scheduling delays lose candidates | Landing page + demo booking flow | First interview booked without manual email coordination | Recruiters click but do not connect a calendar or book an interview | One target. One surface. One activation signal. If two segments need different promises, test them separately. Do not average them into one bland page. ## Positioning turns the target into a promise Positioning is what the chosen segment should remember. Weak AI positioning often becomes a feature pile: - automation - scheduling - reminders - calendar sync - workflows - integrations All true. Still not a position. For the scheduling product, if the target is recruiting teams at 50-person startups, the promise is not: > Calendar automation for teams. It is closer to: > Book qualified first-round interviews before candidates go cold. Or, if the page needs to be more concrete: > Turn candidate availability, recruiter calendars, and interviewer slots into one confirmed meeting without another coordination thread. The exact sentence can change. The discipline should not. ![STP marketing loop diagram](/images/blog/stp-marketing-loop-diagram.png) ## Use the prompt, then make the test small The TL;DR prompt gives your agent the target and positioning promise. Do not let it turn that into a giant campaign plan. Ask for one surface. One headline. One CTA. One objection-handling section. One activation event. Small tests are easier to read. ## Measure target quality, not copy output STP only matters if it changes what you measure. Do not ask whether the agent wrote a better page. Ask whether the chosen segment moved closer to value. Good STP readouts include: - where the segment came from - which surface they entered through - which CTA they clicked - which onboarding step they reached - whether they hit the activation event - whether they came back after first value - whether they upgraded or showed buying intent If you use Agent Analytics, connect this to the [closed-loop growth analysis guide](https://docs.agentanalytics.sh/guides/closed-loop-growth-analysis/) and ask: ```text Use Agent Analytics to read the STP test for . Did the chosen segment reach the activation signal we defined? Compare source, surface, CTA, and activation quality. Tell me whether to keep this target, narrow the positioning, or test a different segment next week. ``` ## Common mistakes 1. Letting the agent invent fake personas instead of finding real customer differences. 2. Keeping every audience because AI makes variants cheap. 3. Changing copy before defining activation. 4. Judging by traffic instead of qualified progress. 5. Keeping weak positioning because it mentions every feature. ## How STP fits the series Use Bullseye when your agent needs to choose channels. Use AARRR when your agent needs to diagnose the growth loop after users arrive. Use STP when your agent needs to decide who a surface is for before it writes more copy. Read next: - [The Bullseye Method for Technical Indie Hackers](/blog/bullseye-method-for-technical-indie-hackers/) for channel selection. - [AARRR for Solo Builders](/blog/aarrr-for-solo-builders/) for weekly growth diagnosis. - [Your Product Isn’t One Website Anymore](/blog/project-context-for-ai-agents/) for multi-surface product context. For setup, use the [Agent Analytics Skill guide](https://docs.agentanalytics.sh/guides/agent-analytics-skill/). For the product-system model behind multi-surface STP tests, read [Projects, Surfaces, and Portfolios](https://docs.agentanalytics.sh/guides/projects-surfaces-portfolios/). ## Final framing AI made it easy to generate marketing for every audience. STP is the pause before that happens. Pick the segment. Pick the promise. Measure whether the right people moved. Otherwise you are just producing more copy and hoping volume turns into growth. [Start free with Agent Analytics](https://agentanalytics.sh/). --- ## Source appendix - https://en.wikipedia.org/wiki/Segmenting-targeting-positioning - https://www.segmentationstudyguide.com/stp-process/ - https://www.aha.io/roadmapping/guide/marketing/segmentation-targeting-positioning ## YC Is Right About AI-Native Startups. They Need Closed-Loop Analytics. > YC's AI-native company advice points to one practical operating model: measurable surfaces, project context, portfolio context, and analytics your existing AI agents can use when deciding what to do next. URL: https://blog.agentanalytics.sh/blog/ai-native-companies-need-ai-native-first-analytics/ Date: 2026-04-26 | Author: Danny | Category: Essay Following Diana Hu and YC's [advice on building AI-native startup companies](https://www.youtube.com/watch?v=EN7frwQIbKc&t=9s), the direction is clear: AI should be the operating system, the company should be queryable, every important process should become a closed loop, human middleware should shrink, and startups should optimize for builder-operators and tokens, not headcount and reporting layers. They are right. But how do you actually do that? The practical takeaway is simple: AI-native companies should run on AI-native-first analytics. Every product, surface, and asset the company ships should be measurable and usable by the same agents helping build the company. Analytics is not the whole closed loop, but it is the part that measures shipped outcomes and artifacts so agents can learn what worked. ## AI-native companies are made of many surfaces Today's company surfaces include landing pages, launch posts, blog posts, docs, guides, public GitHub repos, demos, benchmarks, onboarding flows, integrations, proof pages, community index sites, case studies, and more. Each surface has a job: discovery, education, credibility, intent, conversion, or activation. That means each surface needs context: goals or its role in the growth loop, activation events, a glossary, important product changes, and learnings. Portfolio context stores the shared growth system and the connections between surfaces. Together, project and portfolio context make the company legible to AI-operated closed loops. ## Analytics context should decide where attention belongs The point is not that the agent already knows to improve onboarding, rewrite a launch post, or change a docs page. Analytics context should help Claude Code, Codex, Cursor, Hermes, or the agent already building the company decide where attention belongs in the first place. If activation is leaking in setup, the company's AI agents should see where, whether it matters, and whether an earlier fix helped. If one launch surface brings qualified users and another does not, they should know before writing the next post. If docs, guides, landing pages, community index sites, and the app all participate in the same path, the agent should know which surface educates, which captures intent, which converts, and which milestone counts as real progress. This is what "closed loops everywhere" should mean in practice: ```text ship asset → measure outcome → store learnings → retrieve them at the right time → take a smarter next action → repeat ``` ## Agent-friendly analytics makes the loop run smoothly To run closed-loop companies smoothly, teams need an agent-friendly, AI-first analytics platform that makes the company's AI agents smarter every closed-loop cycle. Agent Analytics is built around this operating model. The skill guides Claude Code, Codex, Cursor, Hermes, OpenClaw, Paperclip, NanoClaw, or the agent already building the company to keep analytics context compact, structured, and retrievable. Project context keeps each surface honest. A docs site might be measured by qualified setup clicks. A free tool might be measured by intent capture. The product app might be measured by activation and retention. Portfolio context keeps the system connected. A launch post, docs page, free tool, community index site, and product app can all be part of the same growth path. The agent should not have to relearn that every session. It should be able to ask: - which surface brought qualified users? - which asset created trust? - which setup step blocked activation? - which agent output got accepted? - which workflow proved value? - what should change next? And the answer should arrive with the product meaning attached. ## Project context and portfolio context are the memory layer The important detail is that context should be compact and structured, not a giant memory dump. Project context is for per-surface truth: activation definitions, event meanings, stable goals, product changes, and human corrections that should survive the current chat. Portfolio context is for the shared growth system: how the landing page, docs, free tools, community surfaces, product app, and related projects work together. If you want the deeper product-context version of this argument, read [Your Product Isn’t One Website Anymore](/blog/project-context-for-ai-agents/). For the setup details, the Agent Analytics docs cover [how the skill keeps project and portfolio context](https://docs.agentanalytics.sh/guides/agent-analytics-skill/) and the CLI reference explains [portfolio context configuration](https://docs.agentanalytics.sh/reference/cli/#portfolio-context). Related context: - [Your Product Isn’t One Website Anymore](/blog/project-context-for-ai-agents/) explains Project Context, Portfolio Context, and why one product is now usually a multi-surface growth system. - [If You Use Hermes to Handle Your Projects, You Need Agent-Readable Web Analytics](/blog/hermes-needs-agent-readable-web-analytics/) shows how this loop works inside an agent runtime that already handles projects and context. - [Stitch Users Across Sites](/blog/identity-stitching/) explains why cross-surface user journeys need to stay connected when a visitor moves between sites, docs, apps, and related domains. - [Analytics Closes the Agent Feedback Loop](/blog/analytics-closes-the-agent-feedback-loop/) covers the earlier version of the core loop: the agent acts, observes, and improves from real user behavior. ## Builder-operators need analytics memory, not more reporting The YC framing around builder-operators is important. The agent is not just a report reader. It is helping inspect surfaces, propose growth bets, make changes, verify deploys, query outcomes, and suggest the next test. The human still owns judgment. The human approves direction, taste, and risk. But the agent should not need a human to manually translate every analytics read into the next prompt. That is the reason to store project and portfolio context beside the analytics data. Save what should survive the current chat: - activation definitions - event meanings - stable goals - surface roles - shared milestones - important product changes - human corrections Skip what will go stale: - this week's metric value - one temporary spike - pasted reports - guesses the human has not confirmed The goal is the right growth context when the company's AI agents decide what to do next. ## The practical takeaway If AI is the operating system, analytics has to be part of that operating system. If the company is queryable, outcomes have to be queryable too. If every important process should become a closed loop, the loop needs product and growth data the agent can actually use. Agent Analytics gives your existing AI agents the analytics platform and memory layer for your company: project truth, portfolio truth, and the right growth context when they decide what to do next. [Start free with Agent Analytics](https://agentanalytics.sh/). ## You Can Now Scale Depth as Well as Width With Hermes Subagents. Agent Analytics Got 140% More Growth Bets > Hermes just released Subagent Delegation. Agent Analytics used that exact model in its skill for growth audits, and our dogfood run produced 140% more growth bets, 140% more evidence references, and 125% higher output density. URL: https://blog.agentanalytics.sh/blog/hermes-subagent-delegation-agent-analytics/ Date: 2026-04-22 | Author: Danny | Category: Announcement **Hermes just shipped subagent width + depth. We updated the [Agent Analytics skill](https://clawhub.ai/skills/agent-analytics) to use that exact model for growth audits.** Hermes just released subagent delegation publicly. Teknium announced it here on X: [You can now scale depth as well as width with subagents](https://x.com/Teknium/status/2046709250114957624?s=20), and the feature is now documented here: [Hermes Subagent Delegation docs](https://hermes-agent.nousresearch.com/docs/user-guide/features/delegation). ## Delegated audits were 6.6% slower, but produced 140% more growth bets and 140% more evidence Here is the result from our dogfood run before the deeper explanation: | Workflow | Runtime | Growth bets surfaced | Evidence references surfaced | | --- | ---: | ---: | ---: | | Single-agent baseline | 4m 55s | 5 | 15 | | Delegated audit | 5m 14s | 12 | 36 | Normalized by runtime, the delegated version also produced much more per minute: | Metric per minute | Single-agent baseline | Delegated audit | | --- | ---: | ---: | | Growth bets per minute | 1.02 | 2.29 | | Evidence references per minute | 3.05 | 6.88 | So the short version is: - **not faster in raw wall-clock time** - **140% more growth bets** - **140% more evidence references** - **about 125% higher output density** ## We added delegation rules, child-agent constraints, and a surface-based audit pattern We added explicit delegation support guidance to the skill. That new section does three things: 1. it marks delegation as supported when the client can actually do it 2. it names Hermes as a concrete example through `delegate_task` 3. it tells child agents how to behave without breaking the Agent Analytics workflow That last part matters. We did not want delegation to turn into a vague "parallelize everything" feature. So the skill now tells delegated children to keep the same rules as the parent: - stay on the pinned official CLI for live Agent Analytics work - preserve prerequisite order - keep scan-first setup behavior - avoid generic instrumentation before analysis - verify the first useful event instead of stopping at setup copy - split growth work by surface or job-to-be-done, not by a generic funnel In other words: delegation is now supported, but it is still disciplined. ## We used the Hermes execution model directly because Agent Analytics is multi-surface by design What Hermes actually shipped matters: - width: one parent can run multiple child agents in parallel - depth: child agents can be allowed to spawn their own workers - orchestration: `role="orchestrator"` children keep delegation, leaf children do not - isolation: every child starts with fresh context and its own tool access - synthesis: only the child summary comes back to the parent That is the model we mapped into the Agent Analytics skill. Agent Analytics is unusually suited to this because one product rarely lives on one surface. A real growth system usually spans a homepage, scanner, onboarding flow, docs, compare pages, ecosystem/directory surfaces, and sometimes multiple related projects. That is why parallel delegation is not just a speed trick here. It is the right mental model for understanding a multi-surface or multi-project system. Each child can evaluate one surface on its own local KPI, and the parent can synthesize what those surfaces mean together. The skill now tells a delegation-capable client to split Agent Analytics work like this: - child 1: homepage + scanner - child 2: onboarding - child 3: compare pages + ecosystem surfaces - child 4: measurement verification That matches how Hermes delegation is designed to work: - children get bounded context instead of the whole conversation - each child gets only the tool access it needs - the parent keeps the synthesis step - measurement verification stays separate from growth prioritization That last point is the important one. We did not want a single child mixing strategy, implementation, attribution, and instrumentation into one blurred answer. Hermes delegation is strong precisely because the parent can split those jobs and then recombine the summaries. ## Delegation preserved local KPIs instead of compressing everything into one funnel The single-agent version got the big picture mostly right. But it naturally compressed several different problems into one answer. The delegated version did a better job separating: - acquisition bets - activation bets - buyer-intent page bets - ecosystem/discovery bets - measurement verification That meant the final synthesis could preserve local truth. We added this to the skill because the skill should not just explain what Agent Analytics is. It should also teach the agent how to use Agent Analytics well in stronger runtimes. If a client supports delegation, the skill should say so. And if it does, the skill should help the client avoid bad patterns like: - delegating without enough context - turning every surface into a raw signup problem - leading with instrumentation before growth bets - switching away from the official CLI path inside child agents - forgetting that measurement verification is a support pass, not the primary growth story This is the main reason to incorporate delegation in Agent Analytics: **not because it sounds advanced, but because it helps the agent preserve the real structure of a modern growth system.** ## Here is the kind of Hermes prompt this unlocks ```text Use Agent Analytics to run a growth audit across Product X. ``` Copy that into a recent Hermes build with Subagent Delegation. If you want to install Agent Analytics on Hermes, see the [Hermes installation guide](https://docs.agentanalytics.sh/installation/hermes/). --- *Related: [Hermes installation guide](https://docs.agentanalytics.sh/installation/hermes/) · [If You Use Hermes to Handle Your Projects, You Need Agent-Readable Web Analytics](/blog/hermes-needs-agent-readable-web-analytics/) · [Analytics Closes the Agent Feedback Loop](/blog/analytics-closes-the-agent-feedback-loop/)* ## If You Use Hermes to Handle Your Projects, You Need Agent-Readable Web Analytics > Hermes can handle your projects, ship changes, and keep context. Agent-readable analytics closes the loop so Hermes can see what users actually did after the work shipped. URL: https://blog.agentanalytics.sh/blog/hermes-needs-agent-readable-web-analytics/ Date: 2026-04-20 | Author: Danny | Category: Guide **[Hermes Agent](https://github.com/NousResearch/Hermes-Agent) is one of the clearest examples of what real agent software should feel like.** It can handle projects, use tools, keep context, and keep moving without collapsing back into a chat-only workflow. That is exactly why we wanted Hermes represented properly inside Agent Analytics docs. And now it is. **But once Hermes ships something, the next question is still the one that matters most:** what did the user actually do after that work went live? That is where Agent Analytics fits. Hermes can handle the projects. Agent Analytics helps Hermes measure whether the work changed anything for a real user. ## Hermes can execute the work. Agent Analytics measures whether it worked. Hermes is strong at operating loops: - inspect - decide - change - verify - continue What most teams still miss is the end-user side of that loop. They can see that Hermes updated a landing page, rewrote docs, added onboarding steps, or shipped a new experiment. They still need an agent-readable way to answer: - did more people click into setup? - did the docs change lead to more signups? - did the new onboarding path create more projects? - did users reach the first event that proves the setup is real? That is the missing feedback loop. ## Hermes is now in the Agent Analytics docs We just added a dedicated Hermes installation guide to Agent Analytics docs: - [Hermes installation guide](https://docs.agentanalytics.sh/installation/hermes/) It covers the clean path: - install the Agent Analytics skill from ClawHub - keep Hermes on the pinned official CLI - use detached browser approval as the default login flow - create the project, run website analysis, install only the first useful events, and verify them That matters because Hermes should not just have analytics available. It should have a workflow that matches how agent runtimes really work. ## Quick install: copy these prompts into Hermes If you want the fastest path, copy one prompt for the full skill and one prompt for the skin. Full skill install: ```text Install the Agent Analytics skill for me from ClawHub. Use `clawhub/agent-analytics`, install the regular Agent Analytics skill, and tell me when it is ready to use. ``` Skin install: ```text Install the Agent Analytics Hermes skin for me. Download https://docs.agentanalytics.sh/downloads/agent-analytics-hermes-skin.yaml into ~/.hermes/skins/agent-analytics.yaml, switch my current skin to agent-analytics, and tell me when it is active. ``` If you want the full setup guide and screenshots, use the [Hermes installation guide](https://docs.agentanalytics.sh/installation/hermes/). And if you want the native dashboard surface inside Hermes, add the plugin too: - [Agent Analytics Hermes plugin](https://github.com/Agent-Analytics/agent-analytics-hermes-plugin) ![Agent Analytics Hermes plugin screenshot](/images/blog/agent-analytics-hermes-plugin-screenshot.png) ## The first Hermes growth loop is simple For most products using Hermes, the first useful loop is simple: 1. Hermes ships or updates a page, docs flow, or onboarding step 2. a user lands on the right surface 3. the user decides whether the setup looks credible 4. the user signs up 5. the user creates a project or reaches the first real activation step 6. Hermes reads the analytics and decides what to improve next That is the real Hermes growth loop. It is not just "task completed." It is: - shipped - measured - interpreted - improved ## Why Hermes especially benefits from agent-readable analytics Hermes is at its best when it can keep working from evidence. That means the analytics system should be readable and usable by the agent itself, not just by a human in a dashboard. With Agent Analytics, Hermes can work from: - stats - events - funnels - paths - experiments - project context - portfolio context across related surfaces That last part matters more than it seems. A lot of teams now run multiple connected surfaces: - landing page - docs - directory or ecosystem pages - product app - GitHub or open-source repos that push people into docs and setup Hermes can already work across them. Portfolio context helps it interpret them as one shared growth system instead of four unrelated properties. That idea is directly connected to how we think about self-improving context too. Agent Analytics project context was inspired by Hermes’ self-learning model: durable product truth should stay close to the work, so the next analysis starts smarter instead of cold. If you want the deeper explanation, read [Project Context, Portfolio Context, and Self-Improvement for AI Agents](/blog/project-context-for-ai-agents/). One concrete example: - someone discovers the project on GitHub - they click into docs - docs becomes the education and setup surface - from docs they go to signup - then they become a real user in the product If you only look at one surface at a time, that loop is hard to understand. If Hermes can read the shared context across those surfaces, it can reason about what is actually moving users toward value. ## We also added an Agent Analytics Hermes skin There is now also a Hermes skin based on the Agent Analytics palette, and it is included in the Hermes docs page too. That is not the core product story, but it is a nice signal: Agent Analytics is not treating Hermes as an afterthought. Hermes now has a first-class install path and a native-feeling presentation inside the workflow. If you want it: - [Hermes install guide with skin instructions](https://docs.agentanalytics.sh/installation/hermes/) - [Agent Analytics on ClawHub](https://clawhub.ai/skills/agent-analytics) ![Agent Analytics Hermes skin screenshot](/images/blog/agent-analytics-hermes-skin-screenshot.png) ## What this unlocks in practice Once Hermes can both ship changes and read real user outcomes, you get a much better loop: - Hermes updates the docs - Agent Analytics shows whether that increased qualified setup intent - Hermes finds where users leak between docs, signup, and first project - Hermes proposes the next experiment - Agent Analytics measures whether it helped That is the workflow we want more teams to have. Not just agent output. Measured user progress. ## Start here If you use Hermes and want the clean setup path: - read the [Hermes installation guide](https://docs.agentanalytics.sh/installation/hermes/) - install the [Agent Analytics skill from ClawHub](https://clawhub.ai/skills/agent-analytics) - use the public [Product Growth Scanner](https://agentanalytics.sh/analysis/) to see what your site should measure first Hermes is excellent at doing the work. Agent Analytics helps Hermes see whether the work moved a real user closer to value. That is the loop worth celebrating. --- *Related: [If You Use 📎Paperclip, You Need Agent-Readable Web Analytics](/blog/paperclip-companies-need-agent-readable-analytics/) · [Project Context, Portfolio Context, and Self-Improvement for AI Agents](/blog/project-context-for-ai-agents/) · [Talk to Your Analytics](/blog/talk-to-your-analytics)* ## If You Build for AI Agents, Your Upgrade Flow Needs to Change > When an AI agent uses your product, the upgrade moment should carry the task context, the paid capability, and a safe human approval handoff. URL: https://blog.agentanalytics.sh/blog/agent-friendly-upgrade-links/ Date: 2026-04-19 | Author: Danny | Category: Announcement If you are building products for AI agents, your upgrade flow needs to change. Something important changes when your product is used by human-operated AI agents. The upgrade moment moves. A normal SaaS upgrade flow assumes the human notices a limit, opens billing, remembers what they were trying to do, decides if Pro is worth it, adds payment, and then tells the agent to try again. That is too much manual work for an agentic workflow. In an agentic workflow, the AI agent is often the one doing the work with your product. That means the agent is also the one that knows why the free tier is no longer enough: - what the human asked for - what failed - which paid capability would unblock the task - what the agent will continue doing after the human upgrades the account That creates a very different monetization pattern. The agent using your product is not just consuming it. It can explain the product's value at the exact point where the value is needed. ## The new upgrade moment The user's AI agent can say: ```text I can continue this task, but this request needs the paid tier of your product to do it properly. Here is what I was trying to do. Here is why the paid capability is needed. Here is what I will do after you upgrade. Open this signed link to confirm payment. ``` That is the part a generic upgrade wall cannot do. A pricing page can list features. The agent can explain the feature inside the task. The human should only have to decide: **Do I want this agent to spend money to continue this work?** If yes, click the link. If no, the agent should keep working with the free tier and say what remains unavailable. The human owns the spend. The agent owns the context. ## How Agent Analytics does it This is the flow we just shipped in Agent Analytics. When an agent reaches a Pro-only analytics task, it does not need a credit card. It does not need a raw API key. It does not need the human to go hunting through billing settings. The agent creates a safe `app.agentanalytics.sh` handoff link with: - the account context - a fixed explanation that the task needs Pro The agent keeps the full command and private analysis context in its own session. The human opens it. The dashboard confirms the account and explains that the requested task needs Pro. Full commands stay out of browser URLs. Then the human decides. If they continue, payment happens in the browser. After payment, Agent Analytics activates Pro. The agent runs `whoami`, sees Pro, reruns the blocked command, and continues the analysis. ![Agent-first Pro upgrade flow: the agent hits a Pro block, creates an upgrade link, the human confirms payment, and the agent continues](/images/blog/agent-friendly-upgrade-links-diagram.jpg) ## Why this matters for monetization Paid analytics features are usually where agent workflows lose the thread. The same will be true for many products AI agents use: analytics, docs, project management, knowledge bases, CRMs, design tools, and automation platforms. The old motion was: ```text user hits limit -> pricing page -> user evaluates -> user pays -> user returns to work ``` The new motion is: ```text agent works -> agent finds a paid capability -> agent explains the value -> human approves -> agent continues ``` For Agent Analytics, the agent already knows what it needs: - funnels to see where users drop off - retention to see if users come back - sessions and paths to connect pages to goals - pages, heatmaps, insights, and live traffic for richer reads - experiments when the next move should be tested The human should not have to reconstruct that reasoning from a blank billing page. The agent should present the case in the same moment it gets blocked. For example: ```text I tried to answer the signup drop-off question, but funnels and session paths require Pro. Here is the exact command I will rerun after you upgrade. Here is the upgrade link. ``` That keeps the decision collaborative. The agent proposes the spend because it knows the task. The human approves or declines because payment belongs to the human. If the human declines, the agent keeps working with free-tier commands and says what remains unavailable. If the human approves, the agent resumes from the same blocked command. No secrets through chat. No raw API-key fallback. No dashboard scavenger hunt. That is monetization for the agentic age. ## What Pro unlocks Free gives you 2 projects, 100k events per month, 500 agent/API reads per month, and 90-day retention. Pro removes the monthly project, event, and read caps, extends retention to 365 days, and unlocks funnels, retention, sessions, pages, heatmaps, insights, live reads, and experiments. Pricing stays usage-based: **$1 per 10,000 events**. After upgrading, set a monthly spend cap from billing. The important product detail is not just the price. It is the handoff shape: 1. The agent runs the command first. 2. The service returns a paid-tier block. 3. The agent creates a dashboard handoff link with account context and a fixed reason. 4. The human confirms the account and payment in the browser. 5. The agent verifies Pro and continues. That is what agent-first billing should feel like. ## For agents using Agent Analytics An agent can create a detached upgrade link like this: ```bash npx --yes @agent-analytics/cli@0.5.37 upgrade-link --detached ``` The CLI prints an `app.agentanalytics.sh` link. The agent sends that link to the human and waits for the account to upgrade. For a local shell where you want the process to keep waiting: ```bash npx --yes @agent-analytics/cli@0.5.37 upgrade-link --wait ``` For async work in OpenClaw, Paperclip, GitHub issues, or a remote agent runtime, use `--detached`. The agent posts the link, exits the command, and waits for the human to come back. ## The prompt Use this with an agent that already has Agent Analytics connected: ```text Run the analytics command that answers the question. If Agent Analytics says PRO_REQUIRED or the free read cap blocks the work, create an upgrade handoff with upgrade-link --detached. Send me the link, wait for me to pay, then run whoami and rerun the blocked command once Pro is active. ``` That is the upgrade pattern agent services need: the agent brings the context, the human makes the spend decision, the service updates the account, and the agent gets back to work. ## Your Product Isn’t One Website Anymore > A practical model for agent-readable analytics: portfolios connect related projects, projects keep local product truth, and surfaces are where users encounter each project. URL: https://blog.agentanalytics.sh/blog/project-context-for-ai-agents/ Date: 2026-04-19 | Author: Danny | Category: Announcement A lot of teams still analyze growth as if one product equals one website. That used to be a decent approximation. It is not anymore. A product now usually shows up across multiple surfaces: a homepage, docs, blog content, free tools, signup flows, mobile clients, local previews, launch pages, ecosystem directories, and sometimes related domains that all support the same goal. Those surfaces do different jobs. One might educate. One might capture intent. One might send qualified clicks. One might convert. One might prove credibility. But the product is not the URL. The domain is just an address for one surface. That is the gap we wanted to close. Agent Analytics now uses one product-system model everywhere: **Portfolio → Projects → Surfaces** A portfolio connects related projects. A project is the local unit of product learning. A surface is where users encounter that project. That split matters because your agent needs to know what scope it is acting on before it installs events, reads a funnel, or compares growth across a company account. Project context keeps local product truth close to the data. Portfolio context helps your agent understand how related projects fit together as one growth system, including cross-project identity when configured inside an intentionally grouped portfolio. We were inspired by what [Nous Research](https://nousresearch.com/) is doing with [Hermes Agent](https://github.com/nousresearch/hermes-agent): a self-improving agent that preserves useful learning instead of starting cold every time. For analytics, the memory should be much smaller and stricter. Save durable product truth. Skip noisy details. ## The model: Portfolio → Projects → Surfaces Start here before creating another project or asking an agent to interpret analytics across several properties. ### Portfolio A portfolio is the broader product or company growth system. It connects related projects so your agent can reason about shared milestones, surface roles, shared goals, and cross-project identity when configured. A portfolio does not collapse everything into one analytics blob. Each project keeps its own activation, retention, lifecycle, releases, experiments, and goals. ### Project A project is the durable unit of product learning. It owns the local analytics truth. Use a separate project when the surface has a different activation definition, retention loop, release cadence, lifecycle, target user, product owner, or business goal. Do not create a new project just because the product has a second URL. ### Surface A surface is a place where users encounter or use a project. A project can have many surfaces: marketing pages, docs, pricing, signup, onboarding, a mobile client, local preview URLs, and preview deployments. Surfaces belong inside the same project when they are part of the same product journey and share the same local truth. ## The real problem: growth is usually spread across a portfolio The important shift is not just that companies have more pages. It is that one growth goal is now usually distributed across many owned surfaces. A modern setup might look like this: - blog posts bring discovery - docs educate and reduce setup friction - free tools capture high-intent visitors - ecosystem or directory pages expand reach - the product site converts - the product app proves real activation Some of those are just surfaces of the same project. Some should become separate projects because they have their own activation, retention, lifecycle, or local goal. The portfolio is what lets the agent connect the related projects without flattening their local truth. If your agent can already work across all of those surfaces, your analytics layer should not force it back into isolated site-by-site thinking. That is why portfolio-aware analytics matters. Without it, the agent can read each property separately but still miss the system. ## Why Project Context still matters Even inside one portfolio, two projects can both say "activation" and mean completely different things. For one product, activation might be: - sign up for a trial - create the first item For another product, activation might be: - sign up - invite a team member For a directory or lead-generation project, activation might not be signup at all. It might be a qualified visitor clicking into the right product, or becoming a lead on another domain. Same analytics vocabulary. Different product truth. ![Different projects and domains can have different activation paths](/images/blog/project-context-activation-examples.jpg) Project Context keeps that truth close to the data: - the goal this project is trying to improve - the events that really count as activation - the glossary for what important events mean to the user or business The value is focus. Your agent does not have to guess whether signup matters, whether a team invite matters, or whether a directory click-through is the real milestone. It knows what this specific project counts as progress, even when the project has several surfaces. ## Why Project Context stopped being enough by itself Project context solves the local-truth problem. But once one company operates across docs, product pages, free tools, directories, mobile apps, and related domains, one project-level memory is not enough. You need two kinds of truth: - project context for what counts inside each project - portfolio context for what related projects and their surfaces are collectively trying to do Without that split, agents usually fail in one of two ways: 1. they over-generalize one activation definition across unrelated surfaces 2. they keep each project separate and lose the bigger growth story Neither is good. If your docs site exists to educate, your directory exists to generate qualified clicks, your main site exists to convert, and your app exists to prove activation, your analytics should preserve both layers: - what each project means locally - how related projects and surfaces work together globally ## What Portfolio Context adds Portfolio context is compact account-level memory for related projects that form one shared growth system. It stores things like: - shared goals - surface roles - shared milestones - cross-project glossary terms That lets an agent understand ideas like: - this site is discovery - this one is education - this one is conversion - these milestones matter across the whole system So instead of seeing four disconnected projects, the agent can see one portfolio that moves people toward value in stages while each project keeps its own analytics truth. That framing is much closer to how growth actually works now. ## A concrete example Imagine the same company operates: - a blog with educational content - a docs site - a free tool on another domain - a directory or ecosystem page - the main product site - the product app itself A user might: 1. discover a post or directory listing 2. click into docs or a free tool 3. decide the product looks credible 4. reach the main product site 5. sign up 6. create the first project or reach the first real activation event If you only inspect one project or surface at a time, that system is hard to reason about. You can see local activity, but not the role each surface plays in the bigger path. Portfolio context gives the agent a compact model of that system, while project context keeps each project honest about what progress actually means there. ## The self-improving part This is also where the self-improving idea becomes useful. After a Product Growth Scanner run, first instrumentation pass, funnel review, retention review, or a human correction, the agent can update what it knows. For example: - this event means trial activation - this event means team activation - this docs site is primarily an education surface inside the right project - this directory is trying to send qualified clicks - this project should not reuse the app's activation definition - these milestones matter across the portfolio The next time the agent reads analytics, it starts smarter. Not because the prompt is longer, but because the durable product meaning lives beside the data. Now it can do that at two levels: - project context for project-local product truth - portfolio context for the shared system across related projects and surfaces ![The self-improving project context loop saves durable product truth and skips stale noise](/images/blog/project-context-self-improving-loop.jpg) Save what should survive the current chat: - activation definitions - event meanings - stable goals - surface roles - shared milestones - human corrections Skip what will go stale: - this week's metric value - one temporary spike - pasted reports - guesses the human has not confirmed ## How a human should use it The human should not manage a low-level memory system manually. The human should give product meaning to the agent. For example: > For the directory site, activation means a qualified visitor clicks through to the product. For the product app, activation means signup and first project created. Keep those definitions separate when you analyze growth. And for the shared portfolio view: > Treat the docs site as education, the free tool as intent capture, the directory as discovery, and the product site as conversion. Keep each one as a surface or separate project based on its local activation and lifecycle. Track shared milestones like qualified click, signup, and first useful activation across the intentionally grouped portfolio. The skill handles the rest: inspect the event names, keep the glossary short, update the right project, and use that context next time. ## Why this matters for AI agents If an agent is already coordinating work across a portfolio, giving it isolated analytics is an unnatural downgrade. It should be able to understand: - what each project and surface is for - what progress means locally - what milestones are shared across the portfolio - how to interpret growth without re-learning the same business truth every session That is what Portfolio → Projects → Surfaces gives you. Not a giant memory dump. A compact analytics-native model of how the business actually works. That is the real point. Your product is not one website anymore. Your analytics should not act like it is. ## A Product Growth Scanner for Your Website > Agent Analytics turns your public site into a prioritized measurement plan and shows your coding agent the data you are not collecting yet. URL: https://blog.agentanalytics.sh/blog/product-growth-scanner/ Date: 2026-04-18 | Author: Danny | Category: Announcement Most analytics tools start after you already know what to measure. That is backwards. The hard part is looking at a real website and deciding which actions actually matter. Where does curiosity turn into intent? Which outcome proves the product is working? Which events would create useful answers, and which ones would just create noise? Agent Analytics now has a Product Growth Scanner: [Scan your website](https://agentanalytics.sh/analysis/) ![Product Growth Scanner input with a website field and Scan my site button](/images/blog/product-growth-scanner-input.png) Paste in a URL and it reads the site like a senior product manager or growth lead would. It looks for the decisions your site is trying to drive, the blind spots in your current measurement, and the first signals worth collecting. It returns a site-specific measurement plan: - the growth questions your site should answer - the measurement blind spots blocking those answers - the first events worth installing - what each event unlocks - what not to measure yet ![Product Growth Scanner result showing the first growth questions a site should answer](/images/blog/product-growth-scanner-result.png) Better analytics is not more events. Better analytics is knowing which events help you make the next product decision. The scanner is useful on its own, but the important part is what happens next. The measurement plan becomes context your agent can carry into setup. That is the product loop we care about: analyze the site, find the blind spots, install the first measurement plan, then let your agent answer growth questions from real traffic. It is not only giving your AI agent analytics data after tracking is installed. It is giving the agent eyes on the data you may not be collecting yet. For a deeper pass, ask your agent to scan the additional websites you own: the marketing site, docs, pricing page, app signup surface, support site, changelog, launch page, or any public page where visitors make a product decision. Each scan gives the agent another view of what the product is trying to make users do and which signals are missing. ## This belongs in the setup routine The right time to use this is before your agent adds custom events, and again when you want it to understand another owned website or product surface. When you ask an agent to install Agent Analytics, it should not guess a generic event list. It should first get a site-specific measurement plan, scan any other owned surfaces that belong in the same growth loop, then install only the highest-priority instrumentation. That is now the normal Agent Analytics setup shape: 1. your agent analyzes the public root page 2. it scans any additional owned public surfaces that should shape the plan 3. it reads the prioritized measurement plan and blind spots 4. it creates or links the Agent Analytics project 5. it installs the tracker plus the first recommended events 6. it verifies the first useful event 7. it explains which growth questions your site can now answer The public page is a fast way to start that loop, especially before login. The same routine also works from the CLI and the Agent Analytics skill: ```bash npx --yes @agent-analytics/cli@0.5.37 scan https://mysite.com --json npx --yes @agent-analytics/cli@0.5.37 scan https://docs.mysite.com --json npx --yes @agent-analytics/cli@0.5.37 login npx --yes @agent-analytics/cli@0.5.37 create my-site --domain https://mysite.com npx --yes @agent-analytics/cli@0.5.37 scan --resume --resume-token --full --project my-site --json ``` The command names are implementation details. The workflow is the point: give the agent product judgment and product eyes before it touches your code. ## What the agent should do with it The first result is intentionally small. It is not trying to list every possible event. Your agent should start with `minimum_viable_instrumentation`, explain what each event unlocks, and skip tempting low-signal tracking until the first useful answer exists. For example, a good agent task is: ```text Use the website scanner to review this product before setup. If this product has other owned public websites or pages that shape the growth loop, scan those too and tell me what data we are not collecting yet. After browser approval, create or identify the matching project, install the project-owned tracker, add only meaningful events tied to this product's goals, explain what each event enables, and verify the first useful event. ``` That prompt is different from "add analytics." It asks the agent to decide, install, and verify. ## Try it [Scan your website](https://agentanalytics.sh/analysis/) Docs: [Product Growth Scanner](https://docs.agentanalytics.sh/guides/website-analysis/) ## Autoresearch Growth Loops Need Reality Checks > LLM judges are useful for generating pressure, but they drift when they judge themselves. The better loop ships variants, waits for real behavior, and starts the next round from evidence. URL: https://blog.agentanalytics.sh/blog/autoresearch-growth-loop-agent-analytics/ Date: 2026-04-16 | Author: Danny | Category: Guide We forked [Andrej Karpathy's `autoresearch`](https://github.com/karpathy/autoresearch) because growth loops need a second judge: users. The repo is here: [Agent-Analytics/autoresearch-growth](https://github.com/Agent-Analytics/autoresearch-growth) The problem with adapting autoresearch to growth is not generation. The problem is self-judging. You can run a candidate, critic, revision, synthesis, and blind-judge loop many times and still converge on copy that LLM judges like more than users do. Shoutout to [Shan Holmberg's AutoReason thread on X](https://x.com/shannholmberg/status/2043983746094026984) for pushing the marketing version of this pattern. The shape is useful: one agent writes, another criticizes, another rewrites, a synthesizer combines, and blind judges pick with Borda scoring. That is much better than asking one model for "better marketing copy." But [this reply points at the real risk](https://x.com/i4Dstrategy/status/2044299258149396601?s=20): LLM judges have biases. They reward length, formality, surface polish, and things that sound smart. Three biased judges do not become the market. ## LLM Judges Have Biases The loop is useful because it creates pressure. It finds weak claims. It catches generic copy. It can produce two strong experiment candidates faster than a human staring at a blank page. But the LLM panel should be treated as a filter, not proof. Proof comes later: - did `signup` move? - did `cta_click` move? - did bounce get worse? - did scroll depth improve? - did signup quality hold? - did the page still say something true? That is where the loop should slow down. That is the value: the loop stops judging itself. ## A Loop On Top Of The Loop The growth version is a loop on top of the loop. ![Weekly outer loop: several LLM-generated experiments run in parallel, then a Friday evidence packet feeds the next loop.](/images/blog/autoresearch-weekly-outer-loop.jpg) The inner loop is the LLM work: 1. Run the autoresearch loop. 2. Produce two distinct variants. The outer loop is the growth system: 1. Let a human review the product truth and risk. 2. Ship the variants as an experiment. 3. **Wait for real behavior.** 4. Pull the result back into the next brief. 5. Run the inner loop again from evidence. That waiting period is not a bug. It is the reality check. At small scale, maybe you wait 24 or 48 hours. At bigger scale, you can run several experiments in parallel and review the week as a batch. Tools like [OpenClaw](/blog/setup-agent-analytics-with-openclaw) or [Paperclip](/blog/paperclip-companies-need-agent-readable-analytics) make that easier to manage because the work can live as assigned agent jobs, not another dashboard chore. That is the future I care about: the agent comes back Friday with seven attempts, seven results, screenshots of what changed, funnel movement, what won, what lost, and what the next loop should try. Not "here are more clever headlines." Evidence. ## Where Agent Analytics Fits This should work with any analytics data. Agent Analytics makes the longer loop easier to manage because the same code agent can own the whole evidence loop: - implement the approved variant on the landing page - create the experiment - run the experiment - measure the experiment - collect the previous experiment data into the next snapshot - preserve the run history - come back with evidence instead of another opinion ![Outer autoresearch loop showing five internal rounds producing two variants, human review, a live experiment measured by Agent Analytics, and an evidence snapshot feeding the next run.](/images/blog/autoresearch-outer-evidence-loop.jpg) That is the value play: ```text agents propose humans approve experiments run users decide agents return with evidence ``` ## What We Built - `program.md` tells the agent how to run the loop. - `brief.md` defines product truth, control copy, metrics, data, and drift constraints. - `results.tsv` logs each round. - `final_variants.md` stores the two winners for review. The repo also includes demo, `ChangelogPilot` (fake SaaS), see it working it without private data. ![ChangelogPilot homepage section showing pull requests becoming a customer changelog.](/images/blog/autoresearch-growth-changelogpilot-demo.jpg) ## Try It Start with the public GitHub repo: [github.com/Agent-Analytics/autoresearch-growth](https://github.com/Agent-Analytics/autoresearch-growth) The sample demo does not require an Agent Analytics account, and it does not require the skill. Clone the repo, use the fake `ChangelogPilot` data, and ask your coding agent to run `program.md`. That gives you the full loop: brief, sample analytics snapshot, round log, Borda judging, and two final variants. If you want the same workflow available as an agent skill: ```bash npx skills add agent-analytics/skills ``` Then ask for the review-only loop: ```text Use the Agent Analytics Autoresearch skill. Optimize the homepage hero for signup. Use cta_click as the proxy metric. Use recent experiment data when available. Fetch the last 7 days, or whatever window makes sense. Summarize what is useful and what is too sparse to trust. Run 5 rounds. Write final_variants.md with two variants for review. ``` The skill treats implementation as a separate human-approved phase. After you approve a variant, the same agent can continue the outer loop: ```text Use the approved variants in final_variants.md. Implement the homepage experiment. Use the current page as the control, then test the two approved candidates against it. Measure signup as the goal and cta_click as the proxy. After the experiment window, collect results into the next data snapshot. Start the next autoresearch loop from measured evidence. ``` The point is not to replace human judgment. The point is to make judgment compound. LLMs can generate and criticize. Humans can approve the risk. Users decide what worked. The next loop should start there. ## Read Next - [A/B Testing Your AI Agent Can Actually Use](/blog/ab-testing-your-agent-can-use) - [Funnels: See Where Users Drop Off](/blog/funnels-where-users-drop-off) - [Analytics Closes the Agent Feedback Loop](/blog/analytics-closes-the-agent-feedback-loop) - [Talk to Your Analytics](/blog/talk-to-your-analytics) ## The Feedback Endpoint Claude Code and Codex Need > If Claude Code, Codex, OpenClaw, Paperclip, or another AI agent uses your product, feedback should not be a UI form. Give the agent a documented endpoint. URL: https://blog.agentanalytics.sh/blog/feedback-endpoint-ai-agents-need/ Date: 2026-04-12 | Author: Danny | Category: Guide A human asks Claude Code, Codex, OpenClaw, Paperclip, Cursor, or another agent runner to use your product/service. Maybe the AI agent is installing a skill, plugin , mcp , cli, and doing some action on your product. Small note before the pattern: this surprised me by actually working. We added a feedback path for agents, and real reports started coming back. Thank you to the users who let their agents try it, and honestly, thank you to the agents that submitted the feedback instead of silently giving up. That is the whole point. If the agent is the one hitting the product friction, the agent should have a product-native way to report it. The human is not staring at every click. The agent is doing the work inside a terminal, an IDE, a remote worker, a Paperclip company task, or an OpenClaw workflow. Then something happens. The docs are missing a step. endpoint returns an unclear or unmapped data. The CLI command works only if a env var exists. The API says `400 Bad Request`. The agent gets blocked, works around the problem, or gives up. That is valuable feedback your product could have. Human products may have a feedback button in the UI / support email / GitHub issue. Those are not the surfaces Claude Code or Codex are using while they work. An agent-first product needs an agent feedback path that works from the same place the task is running. The pattern is simple: **give Claude Code, Codex, OpenClaw, Paperclip, and other AI agent runtimes a documented endpoint for structured product feedback, and document it inside the skill.** No UI required. This pairs directly with [the login pattern agents need](/blog/login-pattern-ai-agents-need). Login gives Claude Code or Codex a safe scoped session after the human approves access. A feedback endpoint gives that same session a safe way to report friction when the work gets blocked. Together, they make the handoff complete: the human approves, the agent works, and the product learns where the agent got stuck. For an agent-first product, the agent is the one using the product surface. If your docs, CLI, API, MCP server, or skill is built for Claude Code and Codex, the agent should be able to report friction in the same structured way it uses the rest of the product. It is an API contract. Something like: ```http POST /v1/feedback Authorization: Bearer Content-Type: application/json ``` With a body the agent can reason about: ```json { "source": "skill", "agent_environment": "claude-code", "task": "add product analytics events to the checkout flow", "severity": "degraded", "area": "event-tracking", "summary": "The tracking guide did not specify the required event names for checkout conversion analysis.", "expected": "The skill should tell Claude Code which checkout events to emit and which properties are required.", "actual": "Claude Code added page_view tracking but had to infer checkout_started, checkout_completed, and plan_id from examples in other docs.", "recovery": "The agent added the likely events, marked the implementation for review, and reported the missing schema guidance.", "docs_url": "https://docs.example.com/guides/tracking/", "metadata": { "skill_version": "0.5.10", "cli_version": "0.5.10", "runtime": "claude-code" } } ``` That is the product difference. ## No UI - Make sure to reject spammy or oversized payloads - attach account, project, session, skill, CLI, MCP, and runtime context when available ## Put It In The Skill To tell AI agent when and how to use the feedback. That guidance belongs in the skill, plugin, cli help, MCP server instructions, Do not make Claude Code or Codex discover feedback policy from a human docs page. The skill should say: ```md When you hit product friction while using this service: - Report feedback when setup instructions are missing, wrong, ambiguous, or outdated. - Report feedback when an API, CLI, SDK, MCP tool, or skill error blocks the task and the fix is not obvious. - Include the task, runtime, environment, error, attempted command, recovery, and suggested docs change. - Do not include passwords, API keys, OAuth codes, raw tokens, private user content, or full chat transcripts. - Keep working when there is a safe documented workaround. ``` ## What To Do With Feedback Once the endpoint exists, connect it to Agent Analytics and fire a feedback event. Track `agent_feedback_received` with properties like `area`, `severity`, `runtime`, `source`, `recovered`, and `feedback_id`. Now the product can measure agent friction the same way it measures user behavior. That closes the loop. ![Agent feedback moves from the runtime to a feedback endpoint, becomes an Agent Analytics event, and turns into a product fix](/images/blog/feedback-endpoint-ai-agents-need-diagram-nanobanana.jpg) ## The Product Lesson If your product is agent-first, do not make feedback a human-only UI flow. Give Claude Code, Codex, OpenClaw, Paperclip, and MCP clients a small, scoped, well-documented endpoint. Put the instructions in the skill. Keep the schema structured. Keep secrets out. Return a stable id. Let the agent continue when it can. That is the feedback endpoint Claude Code and Codex need. ## Read More Related product patterns: - [The Login Pattern AI Agents Need](/blog/login-pattern-ai-agents-need) - [Analytics Closes the Agent Feedback Loop](/blog/analytics-closes-the-agent-feedback-loop) - [If You Use Paperclip, You Need Agent-Readable Web Analytics](/blog/paperclip-companies-need-agent-readable-analytics) The short version: **If the agent uses the product, the agent needs a product-native way to report friction.** ## The Login Pattern AI Agents Need > A safe login pattern for AI agents: the human owns identity, the agent owns the work, and no one pastes API keys into chat. URL: https://blog.agentanalytics.sh/blog/login-pattern-ai-agents-need/ Date: 2026-04-11 | Author: Danny | Category: Guide A human wants to give their agent another arm. They are working in Claude Code, Codex, OpenClaw, Paperclip, or another agent environment, and they want the agent to connect to a service they already use. Maybe that service is Agent Analytics. The human asks the agent to connect a project, install tracking, and read live analytics while it works. Maybe it is Linear for issues, GitHub for repositories, Sentry for errors, Stripe for billing data, PostHog for product analytics, or Vercel and Supabase for deployment and infrastructure. The human is still in charge. The agent is not becoming the account owner. The human just wants the agent to use the service on their behalf and keep working. Then the service asks for login. That is where most agent workflows break. The bad patterns are familiar: - paste an API key into chat - give the agent a password - put a long-lived secret in an environment variable - ask the user to open a dashboard and copy something back - hope a browser session is still alive when the agent needs it - rely on a localhost callback when the agent is running somewhere else These options are bad in two different ways. Some move secrets through chat. An API key in a task thread is still a secret in a task thread. A password in an agent workflow is worse. Others assume the human is sitting live with the running process. That is sometimes true. It is not always true. The problem is this: **The human owns the identity. The agent owns the work. The service needs a safe handoff between them.** ![The Agent Analytics skill chooses detached login, sends an approval URL, waits for the human to paste back the finish code, then continues with a scoped session](/images/blog/login-pattern-ai-agents-need-detached-skill-flow.jpg) ## The Pattern The login pattern AI agents need is not "give the agent your secret." It is: **the human approves in the browser, then the agent receives a scoped session for the work.** That is the OAuth-style part. The user signs in with Google or GitHub in the browser. The service knows what is being approved. The agent never sees the user's password. The chat or ticket never needs a permanent API key. For Agent Analytics, the result is an agent session. It is scoped, revocable, and visible later in `Account Settings` -> `Agent Sessions`. The hard part is not the browser approval. The hard part is getting the human's attention in the right place. That depends on how the human is using the agent. ## Live Or Async There are two common shapes. In Claude Code or Codex, the human is often live with the agent. They see the terminal. The agent runs `login`. A browser opens. The human approves. The browser redirects to `localhost`, the CLI receives the callback, and the agent continues. Normal login is good for that. The human is already watching. In [Paperclip](/blog/paperclip-companies-need-agent-readable-analytics), [OpenClaw](/blog/setup-agent-analytics-with-openclaw), and other task or message-based systems, the human may not be live with the process. The agent may be working from a task, a ticket, a message thread, a scheduled job, or a remote runtime. In that world, localhost callback is the wrong assumption. The agent needs to leave a clear blocked state: > I need human approval. Open this link, sign in, and send me the finish code. That is detached login. ## Detached Login In Agent Analytics, detached login starts like this: ```bash npx --yes @agent-analytics/cli@0.5.37 login --detached ``` The flow is short: 1. The agent starts detached login. 2. The service returns an approval URL. 3. The agent posts the URL into the task, message, issue, or ticket. 4. The work is blocked on human approval. 5. The human opens the URL and signs in with Google or GitHub. 6. The browser shows a finish code. 7. The human replies in the same thread with that finish code. 8. The agent exchanges the code for a scoped session and continues setup. That is the whole product difference. Normal login is for live agent work. Detached login is for async agent work. The human still approves in the browser in both cases. The agent still gets a scoped session in both cases. The difference is the handoff. ## The Agent Should Know The human should not have to know whether the agent should run `login` or `login --detached`. The agent should know. That is why this guidance belongs in the skill or plugin, not only in a docs page. For Agent Analytics, the public skill is the shared instruction layer. Codex can use it through `skills.sh`. OpenClaw can use it through ClawHub. Paperclip uses the same skill shape for company-task workflows. Claude Code has the Agent Analytics plugin mirror with the same guidance. The skill tells the agent: - use normal login when the human is live with the terminal - use detached login in Paperclip, OpenClaw, remote workers, scheduled jobs, and issue/chat workflows - do not ask the human to paste a permanent API key into chat - post the approval URL, wait for the finish code, then continue That makes the product feel smart. The human stays in control, and the agent gets the right kind of access for the work. ## The Product Lesson If your service wants to work well with agents, do not make API keys the normal setup path. Let the human approve in the browser. Give the agent a scoped, revocable session. Support the live path for Claude Code and Codex. Support the detached path for Paperclip, OpenClaw, and async agents. That is the login pattern AI agents need. ## Read More Implementation details: - [Authentication](https://docs.agentanalytics.sh/reference/authentication/) - [CLI](https://docs.agentanalytics.sh/reference/cli/) - [Set up Agent Analytics for your Paperclip company](https://docs.agentanalytics.sh/guides/paperclip/) Broader product context: - [Analytics Closes the Agent Feedback Loop](/blog/analytics-closes-the-agent-feedback-loop) - [If You Use Paperclip, You Need Agent-Readable Web Analytics](/blog/paperclip-companies-need-agent-readable-analytics) The short version: **The human owns the identity. The agent owns the work. The service owns the handoff.** ## Session Paths: Entry Pages, Exit Pages, and What Happens Between > Session paths make entry pages, exit pages, and the steps between agent-readable, so your agent knows what to investigate next. URL: https://blog.agentanalytics.sh/blog/session-paths-entry-exit-pages-for-ai-agents/ Date: 2026-04-10 | Author: Danny | Category: Guide You do not need another table of pages. You need your agent to answer: > Which landing pages bring people in, where do those sessions end, and what should we improve next? That is why we added Session Paths. ## The Value Session Paths connects entry pages, in-session page changes, meaningful events, goal conversion, and exit pages. Instead of asking a human to inspect a dashboard tree, it gives the agent enough context to recommend the next useful move: - build a funnel around the weak step - check retention if the journey depends on return visits - propose an experiment for the page where sessions actually die The core loop is: **pages -> paths -> funnels -> experiments** ![Diagram showing pages flowing into paths, then funnels and experiments](/images/blog/bounded-session-paths-diagram.jpg) ## What Your Agent Gets For each top entry page: - sessions that started there - sessions that reached the goal - exit pages for those sessions - common path branches before conversion, drop-off, or truncation This is session-local on purpose. No cross-visit stitching. No giant historical graph. Just a bounded answer the agent can safely use during normal analysis. ## Copy These Prompts Start broad: ```text Show me session paths for my-site with signup as the goal. Summarize the top entry pages, top exit pages, and the one path most worth improving next. ``` Find weak landing pages: ```text Which entry pages start the most sessions but fail to reach signup? For each one, tell me the most common exit page and the next funnel I should check. ``` Turn paths into an experiment: ```text Look at session paths for my-site with signup as the goal. Pick one high-traffic drop-off path and propose one narrow experiment to improve it. ``` Check content quality: ```text Which content or docs entry pages lead to deeper product pages or signup? Ignore vanity traffic and focus on paths that suggest real intent. ``` ## Why It Is Bounded The endpoint has hard limits: - lookback: `7d`, `14d`, `30d`, or `90d` - entry pages: up to `20` - candidate sessions: up to `10,000` - path depth: up to `5` steps - branches per node: up to `10` - database reads: `2` queries The default is smaller: `30d`, `10` entry pages, `5,000` candidate sessions, `5` steps, and `5` branches per node. That keeps the report fast and predictable. A simple agent question should not become an unbounded historical graph query across every event you have ever tracked. ## Docs Read the short guide: [Session Paths in the Agent Analytics docs](https://docs.agentanalytics.sh/guides/session-paths/) --- *Related: [Funnels: See Where Users Drop Off](/blog/funnels-where-users-drop-off) · [A/B Testing Your AI Agent Can Actually Use](/blog/ab-testing-your-agent-can-use)* ## If You Use 🗄️ Cabinet, You Need Agent-Readable Web Analytics > 🗄️ Cabinet gives you the knowledge base and AI team. Agent-readable analytics gives your Data Analyst real user outcomes to measure and improve. URL: https://blog.agentanalytics.sh/blog/cabinet-teams-need-end-user-analytics/ Date: 2026-04-09 | Author: Danny | Category: Guide **[🗄️ Cabinet](https://runcabinet.com/) is an AI-first knowledge base where files live on disk and a team of AI agents helps you execute.** It gives you the operating system: strategy, research, roadmaps, recurring jobs, and agent memory in markdown. **Add agent-readable analytics and 🗄️ Cabinet can answer the most important commercial question:** what did the real user do after you shipped? **That is where 🗄️ Cabinet teams get the next operating upgrade.** Cabinet is where the work compounds. Agent-readable analytics is how you tell whether that work moved a user closer to value. ## 🗄️ Cabinet organizes the company brain. Agent-readable analytics tracks the outside world. Cabinet is excellent for internal leverage. It can keep your roadmap on disk, store market research, schedule recurring jobs, and give your team a shared memory that does not vanish when a session ends. It even ships with a built-in **Data Analyst** role. **With agent-readable analytics, your team can finally see:** - which launch actually brought qualified traffic - which docs page got users to start setup - which onboarding step caused users to leave - which change increased signup, activation, or purchase That is how 🗄️ Cabinet teams connect internal output to real user movement. ## The first Cabinet loop to measure is simple For most 🗄️ Cabinet teams, the first loop is not complicated: 1. **an agent ships a page, docs change, campaign, or onboarding update** 2. **a real user lands on the product or docs** 3. **they decide whether the setup looks credible** 4. **they sign up or start the install** 5. **they reach a first value moment** 6. **your analyst writes back what changed** That is the real growth loop. ![Cabinet loop from markdown memory to agent-readable analytics and back into next action](/images/blog/cabinet-end-user-analytics-loop.jpg) 🗄️ Cabinet can store the plan, the research, the launch notes, and the follow-up tasks. **Agent-readable analytics makes the user journey queryable.** Once that happens, your Data Analyst stops summarizing internal activity and starts answering the questions that actually matter: - what changed after the landing page rewrite? - which pages drove the highest-intent visits? - where are users dropping out before activation? - which launch channels bring users who actually convert? ## 🗄️ Cabinet philosophy needs an agentic way to measure 🗄️ Cabinet teams already have leverage on execution. The next upgrade is connecting all that output to what users actually do. With agent-readable analytics, the team can answer: - which traffic source brings users who actually activate? - which docs flow produces serious setup intent instead of empty pageviews? - which onboarding change improves first-value completion? - which agent-made change increased signup, retention, or purchase? **This is the operating upgrade.** 🗄️ Cabinet is built around memory, delegation, recurring jobs, and work that compounds over time. Agent-readable analytics extends that loop from **"page updated"** or **"brief written"** to **"user outcome measured"** and then **"next action assigned."** That is where **agent-readable analytics** matters. Once the data is queryable, the team gets better: - your Content Marketer can judge a post by qualified intent instead of impressions - your Product Manager can compare onboarding changes by activation instead of taste - your Data Analyst can spot where the user journey leaks and hand back the next fix That is why the strongest 🗄️ Cabinet setup pairs the knowledge base with **agent-readable analytics their agents can query and use**. ## It works in 🗄️ Cabinet out of the box This part is simpler than it sounds. If your 🗄️ Cabinet workspace already runs on **Codex**, use the normal Agent Analytics skill route for Codex. If your 🗄️ Cabinet workspace already runs on **Claude Code**, use the normal Agent Analytics skill route for Claude Code. Once the skill is installed in that agent environment, it works in 🗄️ Cabinet out of the box. You can ask one of your existing Cabinet agents to run the analytics workflow, or create a dedicated **Analyst** agent inside Cabinet and let it own the reporting loop. That is a very natural fit for 🗄️ Cabinet because the result comes back as a **markdown report inside the knowledge base**. Not another analytics tab. Not another dashboard the team forgets to open. A clean page in Cabinet with headings, bullets, tables, snapshots, and next actions the company can actually use. ## Start here If you want to do this now: - use the [OpenAI Codex install guide](https://docs.agentanalytics.sh/installation/openai-codex/) if your 🗄️ Cabinet workspace runs on Codex - use the [Claude Code install guide](https://docs.agentanalytics.sh/installation/claude-code/) if your 🗄️ Cabinet workspace runs on Claude Code - read [Talk to Your Analytics](/blog/talk-to-your-analytics) for the query model behind the workflow If your company already runs in 🗄️ Cabinet, the clean path is simple: use the same skill install route you would already use for Codex or Claude Code, then let one of your Cabinet agents run the workflow or create a dedicated Analyst agent for it, and keep the weekly insight loop inside the Cabinet workspace as markdown. 🗄️ Cabinet gives you the operating system. **Agent-readable analytics tells your agents whether the operating system is helping real users reach value.** If you run your startup from Cabinet, this is the next obvious layer: **measure the user journey, write the answer back into the knowledge base, and let your agents improve the next step.** --- *Related: [Analytics Closes the Agent Feedback Loop](/blog/analytics-closes-the-agent-feedback-loop) · [Talk to Your Analytics](/blog/talk-to-your-analytics) · [Best Analytics for AI-Built Side Projects](/blog/best-analytics-for-ai-built-side-projects)* ## Best Analytics for AI-Built Side Projects > A practical comparison of Plausible, Umami, PostHog, Mixpanel, Google Analytics, and Agent Analytics for AI-built side projects and agent-led workflows. URL: https://blog.agentanalytics.sh/blog/best-analytics-for-ai-built-side-projects/ Date: 2026-04-04 | Author: Danny | Category: Guide 2026 is the year one person can ship like a team. Claude Code, Cursor, Codex, OpenClaw, Windsurf, and similar tools make it much easier to launch side projects, landing pages, experiments, docs, and new product ideas without waiting on a full company around you. That is great for execution. It also creates a new bottleneck. After the work ships, **what was the actual outcome?** - Did the launch post create signups or just clicks? - Did the onboarding change improve activation or just move users around? - Did the pricing test improve conversion or only increase noise? - Did the SEO page bring qualified users or just more traffic? That is the missing layer for AI-built side projects: **outcome measurement**. If execution is getting automated, analytics cannot stay trapped inside a dashboard you promise yourself you will check later. The system that wins is the one that can see what happened after the work shipped. That is why the right analytics tool for an AI-built side project is often not the same as the right analytics tool for a larger product team. This post is the practical version. Not a giant feature matrix. Not vendor bingo. Just a clear answer to the question: **what analytics tool should you use if AI helped you build the project and you want to know whether it is actually getting traction?** ## The Short Version If you just want the quick answer: - **Use Plausible** if you want simple, privacy-friendly website analytics with a clean UI - **Use Umami** if you want a lightweight open source analytics tool you can self-host - **Use PostHog** if you want a very broad product analytics platform and do not mind complexity - **Use Mixpanel** if you are running a more mature product analytics workflow with serious event analysis needs - **Use Google Analytics** if you are already deep in the Google ecosystem and can tolerate its workflow - **Use Agent Analytics** if you already ship with Claude Code, Cursor, Codex, OpenClaw, or similar tools and want your existing AI agent to inspect analytics, compare projects, read funnels, and help decide what to do next That last category is the key difference. Most analytics tools are built for a human opening a dashboard. Agent Analytics is built for a workflow where the **agent is part of the measurement loop**. ## What Changes When AI Helps You Ship The main shift is not that your side project becomes "an AI product." The main shift is that you can create more surface area faster: - more landing pages - more experiments - more small products - more feature branches that become real launches - more domains and subdomains - more things that might quietly start working That changes the analytics problem. The old model was simple: 1. ship something 2. open a dashboard later 3. try to figure out what changed 4. decide what to do next The new model needs to be tighter: 1. ship something 2. measure what happened 3. inspect the bottleneck 4. feed that learning into the next action That is the real shift. You are not just choosing a charting product. You are choosing the **measurement layer** for the way you build now. ## The Real Split: Execution Is Automated, But Measurement Usually Is Not This is the part most people feel without naming clearly. Execution is getting faster every month. One person can now act like they have a design team, an engineering team, a content team, and an ops team behind them. But after all that work ships, most builders still fall back to the same old habit: open a few dashboards, click around, and try to manually reconstruct what happened. That is the fragile part. Because the real question is not whether the work got done. The real question is: **did the work change the business outcome?** That is why analytics matters more in the AI era, not less. Not because we need more charts. Because we need a way to turn execution into learning. ## How I Would Evaluate Analytics for AI-Built Side Projects For this use case, I would judge tools on six things: ### 1. Can I get useful answers quickly? If the tool makes me do a lot of setup and dashboard spelunking just to answer "is this project alive?" it loses points. ### 2. Is it lightweight enough for side projects? A side project usually does not need enterprise analytics architecture on day one. ### 3. Does it handle product questions, not just traffic? Page views are useful, but I also want events, funnel steps, and enough structure to understand whether people are getting to value. ### 4. Can it scale across multiple projects? This matters a lot now. One project is easy. Eight is where the workflow breaks. ### 5. Can my existing AI agent use it well? This is where most tools still feel behind. Good human dashboards do not automatically translate into good agent workflows. ### 6. Will I still want this setup a month from now? The best analytics stack is the one you will still use after the excitement of launch week is gone. ## 1. Plausible **Best for:** simple website analytics, privacy-first traffic reporting, clean human dashboards Plausible is one of the easiest tools to recommend for side projects in general. It is lightweight, understandable, privacy-friendly, and much less bloated than older analytics products. If your main question is "are people visiting this thing and where are they coming from?" Plausible is a strong choice. ### Where Plausible is strong - clean UI - quick setup - privacy-first positioning - good for page views, referrers, campaigns, and top pages - much easier to live with than a heavyweight product suite ### Where Plausible starts to break for AI-built side projects Plausible is still mainly a **human dashboard workflow**. That is fine if you are happy checking it yourself. It gets less ideal when you want an agent to inspect multiple projects, compare them, analyze deeper product behavior, or participate in an experiment loop. ### Choose Plausible if - you want the cleanest human-first option - most of your questions are traffic and acquisition questions - you do not need your agent deeply inside the analytics workflow ## 2. Umami **Best for:** lightweight open source website analytics Umami is the open source version of the "keep it simple" philosophy. If you want a basic, self-hostable analytics product without a lot of ceremony, Umami makes sense. ### Where Umami is strong - open source - lightweight - straightforward setup - good fit for builders who want control without a giant stack ### Where Umami starts to break Like Plausible, Umami is strongest when the job is straightforward traffic reporting. If your side project needs more serious funnel analysis, experiment workflows, or cross-project agent-readable inspection, you will probably outgrow it faster. ### Choose Umami if - you want a simple open source option - you mainly care about traffic and basic event visibility - you are optimizing for low overhead more than advanced analysis ## 3. PostHog **Best for:** teams that want a broad product analytics platform with room to grow PostHog is powerful. It covers a lot: events, funnels, session replay, feature flags, experiments, and more. If you know you want a broad product analytics system and are willing to deal with the surface area, PostHog can absolutely work. ### Where PostHog is strong - broad feature set - strong product analytics depth - funnels and experimentation are more mature than lightweight traffic tools - can support a team as the product becomes more serious ### Where PostHog gets heavy For small side projects, PostHog can feel like bringing a whole operating system when you wanted a clean answer. It is not that it is bad. It is that the complexity cost is real. And again, the default workflow is still centered on humans operating a product UI. ### Choose PostHog if - you want a fuller product analytics platform - you are willing to trade simplicity for depth - the project is becoming serious enough that you expect broader analytics needs soon ## 4. Mixpanel **Best for:** mature event-heavy product analytics workflows Mixpanel is great when you have a team that really lives in event analysis. If you care deeply about segmentation, cohorts, retention analysis, and product questions at a fairly mature level, Mixpanel is still a serious option. ### Where Mixpanel is strong - mature event analytics - good retention and funnel capabilities - strong fit for product teams that already know exactly what they want to measure ### Where Mixpanel is weaker for this use case For AI-built side projects, Mixpanel often feels like more machine than you need. It also still assumes a human-led workflow most of the time. That matters if the thing you actually want is not another place to click around, but a system your agent can query and use as part of an ongoing loop. ### Choose Mixpanel if - your project is graduating from side project to product team - you have strong event discipline already - you want a mature analytics product and do not mind the heavier workflow ## 5. Google Analytics **Best for:** people already committed to the Google ecosystem Google Analytics is still everywhere. That alone means many builders will use it by default. If you already rely on Google tools, ad reporting, and familiar reporting patterns, it can be good enough. ### Where Google Analytics is strong - ubiquitous - lots of existing documentation - useful if your workflow already depends on Google ### Where it struggles here For a fast-moving side-project workflow, Google Analytics often feels like the opposite of what I want. It is not the tool I would choose if the goal is simple answers, low friction, and agent-friendly measurement. ### Choose Google Analytics if - you already use it everywhere else - you want continuity with the rest of your stack - you are okay with a more traditional analytics workflow ## 6. Agent Analytics **Best for:** builders using AI coding tools who want their existing agent to inspect, compare, and act on analytics This is where the category changes. Agent Analytics is not trying to be "the prettiest dashboard for humans." It is built around a different assumption: **you already have an AI agent, and that agent needs a measurement layer.** If you use Claude Code, Cursor, Codex, OpenClaw, Windsurf, or similar workflows, the point is not to buy another AI product. The point is to give your existing agent direct access to: - page views and events - cross-project inspection - funnels and drop-offs - retention - experiments - a programmatic surface it can inspect in chat or autonomously ### Where Agent Analytics is strong - built for agent workflows, not just human dashboard workflows - works well when you have multiple projects - lets the agent inspect what changed across projects - designed around growth loops: ship, track, inspect, test, iterate - keeps experiments closer to the same measurement workflow ### Where Agent Analytics is not the right fit If you do not care about agent workflows at all, and you just want a normal website analytics dashboard, a simpler human-first tool may be enough. This is not about tracking what the AI agent does internally. It is about giving the agent the product analytics it needs to answer: - what changed? - what is getting traction? - where is the bottleneck? - what should we test next? ### Choose Agent Analytics if - you are already building with AI coding tools - you have multiple projects or experiments to monitor - you want analytics and experiments your agent can inspect directly - you want cross-project answers, not dashboard babysitting ## Which Tool I Would Pick in Real Life If I were choosing today, my recommendation would look like this: ### Pick Plausible when You want a clean, privacy-first analytics tool for a side project and you are happy checking the dashboard yourself. ### Pick Umami when You want a lightweight open source tool and mostly care about traffic-level visibility. ### Pick PostHog when You want a broader product analytics platform and can tolerate complexity. ### Pick Mixpanel when You are doing serious product analytics and already operate with a mature event model. ### Pick Google Analytics when You are already all-in on Google and do not mind the workflow. ### Pick Agent Analytics when Your side projects are already being built with AI help and the real bottleneck is no longer shipping. The bottleneck is measurement. More specifically: **you do not want to manually check a pile of dashboards, and you want your existing AI agent to know what is happening across your projects.** That is the use case Agent Analytics is built for. ## The Real Split: Human Dashboard vs Agent-Readable Measurement That is really the decision underneath all of this. Most analytics tools are built for a workflow where a human opens a dashboard and investigates. That model still works. But AI-built side projects create a new workflow: - more launches - more projects - more tests - more pages - more things to monitor - less patience for manual analytics rituals So the question becomes: **do you want another dashboard, or do you want your existing AI agent to help run the measurement loop?** If you want another dashboard, the classic options are still good. If you want agent-readable analytics, that is where the market is still thin, and why we built Agent Analytics. ## Final Answer The best analytics tool for an AI-built side project depends on what kind of workflow you want. If you want simple human-first analytics, start with Plausible or Umami. If you want deep product analytics, look at PostHog or Mixpanel. If you are already building with Claude Code, Cursor, Codex, OpenClaw, or similar tools and want your existing agent to inspect traffic, funnels, retention, and experiments across projects, use Agent Analytics. Because the real shift is not that AI helped you ship. The real shift is that your measurement layer now has to keep up. --- *Related: [Analytics Closes the Agent Feedback Loop](/blog/analytics-closes-the-agent-feedback-loop) · [Vibe Coding Made Me Ship More Projects Than I Could Track Manually](/blog/vibe-coding-made-me-ship-more-projects-than-i-could-track-manually) · [🦞 Set Up Agent Analytics with OpenClaw (5 Minutes)](/blog/setup-agent-analytics-with-openclaw)* ## If You Use 📎Paperclip, You Need Agent-Readable Web Analytics > 📎Paperclip orchestrates zero-human companies. Agent-readable analytics shows whether users reached install, signup, API keys, and first project. URL: https://blog.agentanalytics.sh/blog/paperclip-companies-need-agent-readable-analytics/ Date: 2026-03-30 | Author: Danny | Category: Guide **[📎Paperclip](https://paperclip.ing/) is open-source orchestration for zero-human companies.** It gives you the company layer: org charts, goals, budgets, governance, and the ability to hire AI employees to get work done fast. **Add agent-readable analytics and 📎Paperclip can answer the most important commercial question:** what did the end user do after you shipped? **That is where 📎Paperclip companies get the next operating upgrade.** It connects agent output to actual user outcomes. ## 📎Paperclip orchestrates the company. Agent-readable analytics tracks results. **📎Paperclip is excellent for operational visibility.** It can tell you which agent wrote the page, which issue closed, and which task moved to done. **With agent-readable analytics, the company can also see:** - did the new landing page drive serious install intent? - did the docs update get more users to copy the command? - did the onboarding change increase signup completion? - did more users generate an API key and create a first project? That is how 📎Paperclip teams measure whether real users moved closer to value. That is how you optimize **user outcomes**, not just **internal throughput**. ## The first 📎Paperclip loop to measure is simple For most 📎Paperclip companies, the first loop is simple: 1. **a post, launch message, or community link** brings in a user 2. **that user lands on a docs or install page** 3. **they decide whether setup looks real** 4. **they sign up** 5. **they generate an API key** 6. **they create a first project** That is the real **📎Paperclip funnel**. It is **one end-user journey**. ![Paperclip and Agent Analytics loop diagram for shipping, measuring, and improving](/images/blog/2026-03-31-01-05-00-paperclip-aa-loop.png) Once you can see where users enter, where they hesitate, and where they drop off, the company can improve the journey with much more confidence. **Agent-readable analytics makes that path measurable.** You can see which post created qualified setup intent, which docs page drove install actions, which onboarding step leaked users, and which change improved first-project creation. That is the difference between activity and progress. ## 📎Paperclip philosophy needs an agentic way to measure 📎Paperclip companies already have leverage on execution. The next upgrade is connecting all that output to what users actually do. With agent-readable analytics, the company can answer: - which traffic source brings users who actually install? - which docs flow produces signups instead of just pageviews? - which onboarding change improves API key generation? - which agent-made change increased first-project creation? ![Paperclip and Agent Analytics journey from blog to docs to signup to first project](/images/blog/2026-03-31-01-05-00-paperclip-aa-journey.png) **This is the operating upgrade.** 📎Paperclip is built around delegation, ownership, and fast loops. Agent-readable analytics extends that loop from **"task completed"** to **"user outcome measured"** and then **"next action assigned."** That is where **agent-readable analytics** matters. Once the data is queryable, the team gets better: - your Content Strategist can judge a post by setup intent instead of impressions - your Technical Writer can compare which install guide leads to more first projects - your Analyst can spot where the user journey leaks and hand back the next fix That is why the strongest 📎Paperclip setup pairs company execution with **agent-readable analytics their agents can query and use**. ## Start here If you want to put this in place today: - Start with [Set up Agent Analytics for your 📎Paperclip company](https://docs.agentanalytics.sh/guides/paperclip/) if your company runs on 📎Paperclip - Read [Talk to Your Analytics](/blog/talk-to-your-analytics) for the query model your agents can use ![CEO issue in Paperclip for hiring an analyst and setting up Agent Analytics](/images/blog/paperclip-ceo-issue-creation.png) If your company already runs on 📎Paperclip, the clean setup path is the CEO-owned setup flow in the Paperclip guide: [Set up Agent Analytics for your 📎Paperclip company](https://docs.agentanalytics.sh/guides/paperclip/). ## Add the live plugin when you want the map inside 📎Paperclip The first layer is still the analyst workflow: - hire an analyst employee in 📎Paperclip - install the Agent Analytics skill - let that analyst query end-user behavior and prepare the next growth action - give that analyst a recurring 8:00 AM job: query Agent Analytics for the latest 24 hours and post the brief back inside 📎Paperclip But there is now a second layer too: - install the [Agent Analytics Live Paperclip plugin](https://github.com/Agent-Analytics/paperclip-live-analytics-plugin) - connect one Agent Analytics account - select the project your 📎Paperclip company should monitor - use the live map, dashboard widget, and plugin page to see what is moving now That plugin is intentionally narrow. It complements the analytics product and the analyst workflow. It makes the current live pulse visible directly inside 📎Paperclip, so the company can see live visitors, active sessions, event flow, and geography without leaving the workspace. **📎Paperclip gives you execution leverage.** **Agent-readable analytics tells you whether that execution helped a real user do anything that matters.** If you run on 📎Paperclip, this is the next obvious layer: **measure the end-user journey, then let your agents improve it.** --- *Related: [Analytics Closes the Agent Feedback Loop](/blog/analytics-closes-the-agent-feedback-loop) · [Talk to Your Analytics](/blog/talk-to-your-analytics) · [🦞 Set Up Agent Analytics with OpenClaw (5 Minutes)](/blog/setup-agent-analytics-with-openclaw)* ## Vibe Coding Made Me Ship More Projects Than I Could Track Manually > AI coding tools made it easy to launch more side projects than dashboard workflows can track. Agent Analytics gives your AI agent one measurement layer. URL: https://blog.agentanalytics.sh/blog/vibe-coding-made-me-ship-more-projects-than-i-could-track-manually/ Date: 2026-03-28 | Author: Danny | Category: Guide Vibe coding changed how I build. I can go from idea to live project much faster now. The bottleneck is no longer shipping. The bottleneck is knowing what is happening after I ship. If I launch one project, a normal dashboard is fine. If AI lets me launch five, eight, or twelve small projects, landing pages, experiments, and side bets, I am not going to open five, eight, or twelve dashboards every morning. That is the real shift. Vibe coding made me ship more projects than I could track manually. ## Dashboards Are Good. Human Dashboard Workflows Are the Problem. Dashboards exist for a reason. They help humans inspect traffic, compare periods, and understand behavior. Tools like Plausible, PostHog, Mixpanel, Umami, and Google Analytics all make sense if a human is the one doing the checking. The problem is that vibe coding changes the ratio. One person can now launch far more projects than one person can comfortably monitor by hand. So the thing that stops scaling is not data collection. It is human attention. I still want to know: - which project is quietly starting to grow - which landing page is getting traffic but not converting - which source is sending real users instead of junk clicks - where people drop off in the funnel - whether an experiment actually improved anything But I do not want that knowledge badly enough to log into a pile of separate dashboards every day. That is where the old workflow breaks. ## Vibe Coding Made Human Analytics Workflows Stop Scaling When I shipped more slowly, manual analytics made sense. I had fewer live projects, fewer domains, fewer experiments, and fewer places to remember to check. Now the surface area is much bigger. AI coding tools like Claude Code, Cursor, Codex, OpenClaw, and similar workflows make it easy to spin up: - a new SaaS idea - a waitlist page - a docs site - a pricing test - a side tool - a niche landing page for a specific audience That is good. More shots on goal is good. But every extra project creates another place where useful signals can hide. A small but growing project needs more watching, not less, because early signals are weak and easy to miss. That is why I keep coming back to this line: **Vibe coding made human analytics workflows stop scaling.** ![Generated editorial visual showing many small project dashboards flowing into one agent-readable analytics layer.](/images/blog/vibe-coding-scaling-diagram-v2.jpg) If you only have one main product, human-first analytics tools are often enough. If you have a portfolio of projects, the experience starts to break. Data is not missing. It is trapped behind workflows you do not want to repeat often enough. ## What I Actually Wanted Was One Agent Watching Everything I did not want a new AI service. I already had the AI part. I already use AI coding tools to ship. What I was missing was the measurement layer that my existing AI agent could inspect, compare, and act on. I did not need another dashboard trying to get me to log in more often. I needed analytics that worked with the agent I already use: - one place to track projects - one API the agent can query - one layer for page views, events, funnels, retention, and experiments - one cross-project view of what changed - one system the agent can inspect without browser logins or dashboard babysitting This is exactly why we built [Agent Analytics](https://agentanalytics.sh). ![Editorial image of one AI agent workspace turning many project dashboards, funnels, and experiments into one cross-project brief.](/images/blog/vibe-coding-cross-project-brief.jpg) Agent Analytics is not an AI agent. It is the analytics layer for the AI agent you already have. If you are already using Claude Code, Cursor, Codex, OpenClaw, or a similar workflow, the point is not to replace that. The point is to give that existing agent access to the measurement it needs. ## Why This Works Better Than Manual Checking Once analytics becomes agent-readable, the workflow changes. Instead of opening dashboards and deciding where to click, I can have my agent: - compare all my projects and tell me what changed this week - flag the project that is starting to get traction - show which channel drove useful traffic - inspect a funnel and tell me where the biggest drop-off is - monitor an experiment and report whether a variant is winning - tell me which project deserves attention today That is a much better fit for how I actually work now. The agent handles the repetitive inspection. I handle the decisions. That is what I mean when I say analytics should be built for machines, not just dashboards. ## The Cure Is Not Fewer Projects. It Is Better Instrumentation for the Agent You Already Use. The wrong response to vibe coding is to tell builders to slow down. The whole point is that we can ship more. The right response is to make measurement scale with that new reality. For me, that means: 1. keep shipping quickly 2. instrument projects consistently 3. let my AI agent monitor all of them 4. get one readable summary instead of a manual dashboard tour 5. use funnels, retention, and experiments to decide what to improve next That closes the growth loop in a way human-only analytics workflows never really could. ## Where Normal Analytics Tools Still Fit Traditional analytics tools are still useful if you want a human-first dashboard: - **Plausible** for simple, privacy-friendly traffic analytics - **Umami** for a lightweight open source option - **PostHog** for deeper product analytics - **Mixpanel** for mature teams with heavier analytics needs - **Google Analytics** if you are already in that ecosystem But those tools were built around a human opening a product and inspecting data visually. My problem was different. I wanted analytics that an agent could use as part of a workflow: compare across projects, watch over time, support experiments, and help answer what to do next. That is the gap Agent Analytics is built for. ## If Vibe Coding Helped You Ship More, Your Analytics Has to Evolve Too Vibe coding is making builders more productive. That naturally means more projects, more launches, more tests, and more chances to find something that works. It also means the old model of manually checking dashboards stops scaling much sooner. So if you are feeling the pain, I do not think the answer is to become more disciplined about logging into more tools. I think the answer is to give your existing AI agent the measurement layer. That is what I wanted for myself, and that is what Agent Analytics is built for. Because shipping got easier. Now measurement has to catch up. --- *Read next: [How My AI Agent Runs A/B Tests Across 5 Projects While I Sleep](/blog/how-my-ai-agent-runs-a-b-tests-across-5-projects-while-i-sleep)* ## Why We Built Live Monitor for macOS > A faster way to watch live traffic, QA trackers, and keep real-time context available for you and the agents helping you ship. URL: https://blog.agentanalytics.sh/blog/why-we-built-live-monitor-for-macos/ Date: 2026-03-14 | Author: Danny | Category: Story Most analytics products assume the same workflow: Open a browser tab. Leave it on a dashboard. Refresh it when you want to check if something changed. That works fine for historical reporting. It is much worse for the kind of work I kept doing with Agent Analytics. I wanted a live surface I could leave open while shipping. Something I could glance at during a launch, during tracker QA, or while debugging a strange spike. I did not want that job competing with docs, admin panels, deploy logs, and the ten other tabs already open in the browser. That is why we built **Live Monitor for macOS**. ## The Browser Tab Was Doing the Wrong Job The problem was not "I need another dashboard." The problem was that live monitoring is a different activity from analysis. When I am checking last week's top pages, I am happy in the web app. When I am trying to answer questions like "did the tracker fire?", "which country is active right now?", or "did that launch announcement just move traffic?", I want a persistent screen I can keep nearby without burying it in the browser. The browser tab kept getting reused for the wrong thing: - a temporary wallboard during launches - a QA surface while testing page views and custom events - a second screen during customer demos - a quick pulse-check while coding Those jobs all want the same thing: fast, glanceable, live information. Desktop felt like the right surface for that. ## Why Desktop I wanted the live monitor to feel more like an instrument panel than a dashboard. Open it once. Leave it running. Pick a project. Look over when you need signal. That led us to a small macOS app that focuses on one project at a time and stays opinionated about what belongs there: - a country-level live map - the current top pages - the current top events - a raw recent-events feed for inspection - connection diagnostics when `/live` or `/stream` misbehave It is not trying to replace the full web app. It is giving live traffic its own surface. ## What the App Does Right Now The current app is intentionally narrow. You sign in with your existing Agent Analytics account access, choose a project, and the app opens into a live view built for monitoring rather than deep reporting. On the main screen you get: - a project picker - live visitor, session, and events-per-minute cards - a world view with country-level activity - top pages and top events for the current live window - a recent activity preview Under the hood, the app combines `/stream` for immediate activity with `/live` polling for authoritative resync. That makes it useful both as a passive monitor and as a sanity-check tool when you are testing your instrumentation. There is also a dedicated raw event explorer. That is the part I kept wanting during tracker QA: not just "traffic exists," but the actual payloads, user/session IDs, countries, paths, and properties that explain why the live view changed. ![Recent Events inspector in Live Monitor for macOS](/images/blog/live-monitor-macos/recent-events.png) You can filter the feed, inspect the JSON side-by-side, and verify whether a CTA click, signup, or page view showed up the way you expected. The app also has lightweight diagnostics for separating `/live` polling issues from `/stream` SSE issues, plus optional new-visitor sounds if you want a little more ambient feedback while it is open on another screen. ## Why Current Users Care I built this for people who are already using Agent Analytics and keep finding themselves in live mode. That usually means one of four things: 1. You are launching something and want a wallboard you can keep open. 2. You are debugging tracker behavior and need raw events, not just aggregates. 3. You want a customer-facing screen during demos or internal reviews. 4. You want a low-friction pulse-check while building, without reopening the dashboard over and over. That is also why the app does not start with twenty views and a big left nav. The value is in being focused. Open the app, keep it nearby, and let the browser stay for everything else. ## Beta Reality This is still a beta, and the limits are real: - it is currently **macOS-only** - it targets **macOS 14+** - the downloadable build is currently **unsigned / not notarized** - it relies on your existing **Agent Analytics hosted account and API access** So this is not positioned as a polished general-purpose desktop analytics suite yet. It is a practical live monitor for current users who already know the product and want a better surface for this specific job. I also do not want to hide the install friction. Because the app is not notarized yet, macOS will warn on first launch. The full Gatekeeper flow is documented on the download page, and that is the right place for the step-by-step install instructions rather than duplicating them here. ## Available Now If you already use Agent Analytics and this sounds useful, start here: - [Download Live Monitor for macOS](https://agentanalytics.sh/download) - [Open dashboard settings](https://app.agentanalytics.sh/account/settings) The download page includes the current beta notes and the exact macOS **Open Anyway** flow. Once the app is installed, you can connect with the same API access you already use in the hosted product or via the CLI config if you are already logged in there. This is one of those products that became obvious only after using Agent Analytics every day. The web app is still where I go for broader analysis. But for live traffic, tracker QA, and keeping a project's pulse visible while I ship, a dedicated desktop screen is simply better. --- *Read next: [How We Started Agent Analytics](/blog/how-we-started)* ## AARRR for Solo Builders: Let Your AI Agent Run Your Pirate Metrics > Use Agent Analytics with OpenClaw, Claude Code, Cursor, Codex, or any coding agent to diagnose which part of your growth loop is broken. URL: https://blog.agentanalytics.sh/blog/aarrr-for-solo-builders/ Date: 2026-03-10 | Author: Danny | Category: Guide Most indie hackers know two numbers: - traffic - signups And that’s usually where measurement stops. AARRR fixes that by splitting growth into five stages: - **Acquisition** — how people find you - **Activation** — whether they reach the first meaningful moment of value - **Retention** — whether they come back after that first experience - **Referral** — whether they share the product or bring in others - **Revenue** — whether the business actually captures value For solo builders, AARRR is useful because it turns vague growth anxiety into a concrete diagnosis. Instead of staring at traffic and guessing, you can ask: - Are the right users arriving? - Are they reaching value? - Are they coming back? - Are they bringing others? - Are they paying? In an agent-native workflow, your AI coding agent should be able to answer that every week — whether you use OpenClaw, Claude Code, Cursor, Codex, Windsurf, or another tool that can query analytics programmatically. ## Install the Agent Analytics skill The blog version teaches the human what AARRR is for. The skill teaches your AI agent how to turn that framework into live analytics reads, durable project context, and a repeatable diagnosis loop. Install the regular Agent Analytics skill from the public skill repo: ```bash npx skills add agent-analytics/skills ``` If the installer asks which skill to install, choose `agent-analytics`. Then start in the codebase or site you want to measure and ask your agent to set up the project, install or verify tracking, store the product’s activation definition in context, and read the latest analytics before making recommendations. ![AARRR hero illustration](/images/blog/aarrr-hero.png) ## Why AARRR still matters Most indie projects track pageviews, maybe clicks, maybe signups. That gives you the shape of attention, but not the shape of the business. Examples: - High traffic, low activation → landing page or onboarding problem - Good activation, bad retention → product value problem - Strong retention, weak revenue → monetization problem - Good acquisition and activation, no referral → no sharing loop AARRR gives structure to diagnosis. ## Why it gets better with AI agents What changes in 2026 is not the framework. It’s the workflow. Your AI agent can now: - gather the data, - summarize each stage, - identify the bottleneck, - recommend the next move. That’s where Agent Analytics fits. The value is not “five metrics on a dashboard.” The value is that your agent can turn those five stages into a weekly operating brief. ![AARRR stages diagram](/images/blog/aarrr-stages-diagram.png) ## How to map AARRR into Agent Analytics ### Acquisition Track: - page views - referrers - UTMs - landing page sessions by source ### Activation **Signup is not always activation.** For Agent Analytics, activation might be: - `signup_completed` - `project_created` - first snippet installed - first real tracked event received ### Retention Track: - return sessions - repeat key action - cohort return by week ### Referral If your product has any natural share or invite loop, instrument it. Track: - invite sent - invite accepted - referred signup - share action ### Revenue Track: - subscription started - upgrade - purchase - paid conversion rate ## How this maps to the skill AARRR is the diagnosis loop. Bullseye helps your agent choose and compare channels; AARRR helps your agent inspect what happens after people arrive. The Agent Analytics skill makes that loop operational: - **Blog:** teaches you the framework and what good AARRR questions sound like. - **Skill:** teaches your AI agent the workflow for setup, reporting, funnels, retention, experiments, and context. - **CLI/API:** pulls live project data instead of relying on screenshots or copied dashboard numbers. - **Project context:** stores durable product truth such as goals, activation events, event-name meanings, and major product changes so future reads know what “value” means for this project. For AARRR, that means your agent should: 1. Read recent acquisition, activation, retention, referral, and revenue signals. 2. Map real event names to the five stages. 3. Check whether the product context already defines activation and goals. 4. Identify the weakest stage from live data, not vibes. 5. Recommend one stage-specific change and explain what should be measured next. ## What to ask your AI agent Use concrete prompts, not vague ones. ### Weekly summary > Use the Agent Analytics skill to give me an AARRR summary for the last 7 days across all projects. Show Acquisition, Activation, Retention, Referral, and Revenue. Highlight the weakest stage and one recommended next action. ### Activation diagnosis > Use the Agent Analytics skill to check which projects have the biggest drop-off between signup_completed and project_created in the last 7 days. Rank them and tell me where activation looks broken. ### Retention check > Use the Agent Analytics skill to compare week-1 retention by acquisition source for the last 30 days. Tell me which channel brings users who actually come back. ### Revenue check > Use the Agent Analytics skill to show me which acquisition sources produce paying users, not just signups. ### One-project operator brief > Use the Agent Analytics skill for project X. Give me an AARRR breakdown for the last 14 days and tell me which stage I should improve next. ## What your weekly AARRR brief should look like Every Monday, your AI agent should be able to send something like this: - **Acquisition:** organic search up 18%, Reddit flat - **Activation:** signup rate healthy, but only 42% created a project - **Retention:** week-1 return rate down vs last week - **Referral:** almost no invite behavior yet - **Revenue:** no change in paid conversion - **Diagnosis:** activation is the weakest stage - **Action:** improve onboarding and instrument first-value step more clearly That is much more useful than “you got 1,243 pageviews.” ![Weekly AARRR brief illustration](/images/blog/aarrr-weekly-brief.png) ## Common mistakes 1. **Treating signup as activation** 2. **Ignoring retention because the project is early** 3. **Tracking referral before the product has value** 4. **Looking only at top-line counts** 5. **No next action tied to the weakest stage** ## Final framing AARRR is useful because it forces discipline. Instead of asking: - How much traffic did we get? you ask: - Where is the growth loop weak? - What stage should we improve next? Bullseye helps your agent choose channels. AARRR helps your agent diagnose the loop after users arrive. Read the previous post: [The Bullseye Method for Technical Indie Hackers](/blog/bullseye-method-for-technical-indie-hackers) --- ## Source appendix - https://www.productplan.com/glossary/aarrr-framework/ - https://www.product-frameworks.com/AARRR-Metrics.html - https://mcgaw.io/blog/aarrr-pirate-metrics-for-startups/ ## Why GPT-5.4 Makes Agent Analytics Better > GPT-5.4 improved the capabilities that make AI-agent growth analysis work: long multi-step tasks, tool use, and polished business outputs. URL: https://blog.agentanalytics.sh/blog/gpt-5-4-openclaw-agent-analytics-growth-operator/ Date: 2026-03-07 | Author: Danny | Category: Guide [GPT-5.4](https://openai.com/index/introducing-gpt-5-4/) looks especially strong at three things: - long multi-step tasks - tool use - turning raw information into polished business outputs That matters for Agent Analytics because useful growth analysis is exactly that kind of work. A real analytics question is not "how many pageviews did I get?" It is: - which project has momentum? - where is the funnel breaking? - what changed this week? - which experiment is helping? - what should I do next? To answer those well, a model has to make multiple queries, follow up on anomalies, compare periods, and turn the result into something founder-readable. That is why we are excited about GPT-5.4. Its improvements line up unusually well with the kind of work Agent Analytics is built for. ![Dark cinematic illustration of an AI agent reviewing multiple project metrics and turning them into a polished founder memo.](/images/blog/gpt-5-4-growth-operator/hero.png) ## GPT-5.4 is better at the exact work growth analysis requires OpenAI’s [announcement](https://openai.com/index/introducing-gpt-5-4/) leans into stronger tool use, professional knowledge work, spreadsheets, documents, and polished outputs. That is not just a coding upgrade. It is a meaningful improvement for growth analysis. Older models could query analytics. GPT-5.4 is better at continuing the investigation. It is better suited for workflows like: 1. query traffic across projects 2. compare signups and conversion rates 3. inspect funnel drop-off 4. check retention or experiment performance 5. identify the biggest change 6. turn that into a recommendation That sounds simple when written out, but it is exactly the kind of long multi-step work that weaker models struggle with. They lose track of the question, stop too early, or fail to turn the data into something useful. GPT-5.4 is better at staying with the task. ## Why that makes Agent Analytics more useful ![Conceptual flow showing analytics data, funnels, retention, and experiments flowing into an AI agent and then into a growth memo and action plan.](/images/blog/gpt-5-4-growth-operator/flow.png) Agent Analytics gives the model structured growth data it can actually reason over: - analytics - funnels - retention - experiments - multi-project visibility - agent-friendly querying through API, CLI, and MCP workflows That is the key connection. GPT-5.4 got better at multi-step investigation and tool use. Agent Analytics gives it the measurement layer where those strengths become useful. Without a system like Agent Analytics, a stronger model is still missing the feedback layer. It can ship code, but it cannot reliably answer the most important question: did the change actually work? With Agent Analytics in the loop, the model can investigate performance, explain what changed, and recommend what to do next. That is why GPT-5.4 makes the service better. ## Better model, better outputs This is the other reason the release matters. OpenAI is also clearly pushing GPT-5.4 toward spreadsheets, documents, presentations, and polished professional outputs. That means the value of Agent Analytics is not just that the model can read data. It is that it can turn that data into something a founder can immediately use. Your agent can now turn analytics into founder-readable deliverables like: - a scheduled growth memo - an experiment recap - a KPI brief - a cross-project portfolio review - a launch postmortem - a short summary for a cofounder or investor It is one thing for an agent to tell you that signup conversion fell from 3.1% to 2.4%. It is much more useful when it says: - traffic is flat - CTA clicks are up - conversion is dropping at signup - experiment B improved clickthrough but hurt downstream completion - Project 3 has the strongest momentum this week - next action: fix the signup step before sending more traffic That is the real upgrade. **Agent Analytics gives the model growth data. GPT-5.4 helps turn that data into decisions.** ## Where OpenClaw fits OpenClaw is the execution layer. It gives the model autonomy and the ability to actually run the workflow: query data, follow up with more queries, synthesize what it finds, present the result in chat, and own recurring jobs like an 8:00 AM analytics brief. So the stack becomes very clear: - **GPT-5.4** improves the reasoning, tool use, and business outputs - **Agent Analytics** provides the measurement layer - **OpenClaw** gives the model an execution environment That is why this combination is interesting. Not because it creates another dashboard. Because it creates a better growth workflow. ## A practical caveat One thing worth saying clearly: GPT-5.4 does not feel exactly like the model before it. In my own use, it feels smarter and more capable on hard tasks, but also a bit less autonomous. It tends to ask for permission more often before taking actions. That is not necessarily bad. In many workflows, especially ones that touch production systems, growth experiments, or anything user-facing, that extra caution can be a feature. But it does change the feel of the workflow. So the improvement here is not simply "the model does more on its own." It is more that GPT-5.4 is better at the analysis, better at the reasoning, and better at producing useful outputs once it has the right data. Agent Analytics makes that data available. ## What this unlocks in practice If you are using OpenClaw with GPT-5.4 and Agent Analytics, the workflow starts to look a lot more like a real operator loop: - OpenClaw runs the scheduled check across your projects - notices what changed - runs follow-up queries - identifies the bottleneck - summarizes the findings - proposes the next growth action Not "here is a dashboard." Not even "here is one metric." More like: > Here are the two projects that matter this week, the funnel step that is breaking, the experiment that is underperforming, and the one thing I would fix first. That is the beginning of a growth operator. Not because the model magically became a growth expert overnight, but because GPT-5.4 improved the exact capabilities that make growth analysis work. ## If you already use Agent Analytics + OpenClaw ![A chat-based AI agent generating a weekly growth brief from analytics queries across multiple projects.](/images/blog/gpt-5-4-growth-operator/chat-brief.png) If your OpenClaw session is already set to GPT-5.4, you can paste this directly into chat: ```text Review the last 7 days across all my Agent Analytics projects. I want a founder-style growth brief, not a raw metric dump. Please: 1. Identify which project has the strongest momentum right now 2. Identify the biggest negative change across traffic, signups, funnels, retention, or experiments 3. Compare the last 7 days vs the previous 7 days 4. Run follow-up queries if needed until you can explain what changed 5. Tell me the most likely bottleneck 6. Recommend one concrete growth action for each project 7. End with a short priority list: what I should work on first, second, and third Format the output as: - Executive summary - Per-project analysis - Risks / anomalies - Recommended next actions ``` If you want something more experiment-focused, paste this instead: ```text Use Agent Analytics to review all active experiments and related funnel performance across my projects. I want to know: - which experiment is winning - which experiment looks misleading because downstream conversion is worse - where users are dropping off - which experiment I should stop, keep running, or replace Do as many follow-up queries as needed to produce a clear recommendation. Output a short experiment review memo with one recommended next test. ``` ## The bigger picture The interesting part of [GPT-5.4](https://openai.com/index/introducing-gpt-5-4/) is not just that it is better at coding. It is that OpenAI improved the exact capabilities that make analytics more useful: multi-step investigation, tool use, and polished business outputs. That makes Agent Analytics more valuable. And when you pair that with OpenClaw, you get something more useful than another analytics dashboard: a workflow where the model can participate in the growth loop itself. --- *Previously: [Analytics Closes the Agent Feedback Loop](/blog/analytics-closes-the-agent-feedback-loop) · [Talk to Your Analytics](/blog/talk-to-your-analytics) · [🦞 Set Up Agent Analytics with OpenClaw (5 Minutes)](/blog/setup-agent-analytics-with-openclaw)* ## Analytics Closes the Agent Feedback Loop > AI systems improve when action and consequence stay connected. Analytics is the measurement layer that tells your agent what happened after it shipped. URL: https://blog.agentanalytics.sh/blog/analytics-closes-the-agent-feedback-loop/ Date: 2026-03-06 | Author: Danny | Category: Guide Your agent rewrites a headline, deploys the change, and messages you: > "Shipped." Cool. Did signups go up? Did more people click the CTA? Did retention improve, or did the new copy attract the wrong users? If your agent can't answer those questions, it didn't complete a feedback loop. It completed a task. That's the difference. ## AI Agents Need Tight Feedback Loops AI systems get useful when the gap between **action** and **consequence** gets short. A useful agent loop has **3 basic steps**: 1. **Take an action** — edit a page, change onboarding, launch a campaign 2. **Observe what happened** — traffic, clicks, signups, retention, experiment results 3. **Update the next action** — keep, kill, test, iterate ![Three-step agent loop: act, observe, update](/images/blog/feedback-loop-three-steps.png) That is how humans improve. It's how growth teams improve. It's how agents improve too. Without **observing what happened**, the system is flying blind. Your agent can write code all day. It can deploy 20 changes before lunch. But if it has no reliable way to measure outcomes, it can't really learn. It can only keep shipping and hope. ## Where Most Agent Workflows Break This is the part a lot of agent demos skip. The agent writes code. Great. The agent opens a PR. Great. The agent deploys the change. Great. Then the loop goes dark. What happened after the deploy? Most analytics tools assume a human will open a dashboard, click around, build a report, compare time ranges, and decide what to do next. That breaks the loop for agents. Agents don't want dashboards. They need **structured outcome signals** they can query programmatically. Not screenshots. Not "someone should check Mixpanel later." Not a browser session that expires every day. They need an API, a CLI, or MCP tools that let them answer the question that matters: > "Did the thing I just changed make the product better?" ## Analytics Is the Outcome Signal This is why analytics matters so much in the agent era. Analytics is not just reporting. It's the part of the loop that tells the system what happened in the real world after it acted. For an agent, that means: - **Stats** tell it whether a change moved anything at all - **Funnels** tell it where users drop off - **Retention** tells it whether the improvement actually sticks - **Experiments** tell it which variant wins - **Breakdowns** tell it which audience, page, source, or device is driving the change That is the measurement layer. It's also an important distinction: this is **not** about monitoring the agent itself. We are not talking about token usage, internal traces, or agent observability. We're talking about product and user outcomes. The agent changed something. Analytics tells it what happened next. ## The Loop, Closed Here is what a real agent feedback loop looks like in practice: ![Agent feedback loop diagram](/images/blog/feedback-loop-diagram.png) 1. **Agent edits a landing page** 2. **Agent ships the change** 3. **Agent measures results** — traffic, CTA clicks, signup rate 4. **Agent finds the bottleneck** — maybe the CTA improved but signup completion got worse 5. **Agent creates an experiment** to test the next fix 6. **Agent measures again** and ships the winner Then it repeats. This is the important part: the loop stays closed because measurement is built into the workflow. No human has to remember to log in and inspect a dashboard before the next decision gets made. ## A Simple Example Let's say your agent changes the hero copy on your homepage. A weak workflow looks like this: - ship new copy - wait a few days - maybe remember to check analytics later - guess whether the change worked A tight loop looks like this: - ship new copy - check page performance 24 hours later - compare CTA click rate vs previous period - check the funnel from `page_view -> cta_click -> signup` - see whether the new copy improved top-of-funnel clicks but hurt signup completion - test a more specific CTA next That second workflow compounds. The first one produces activity. The second one produces learning. ## Why Dashboards Break the Loop Dashboards are fine for humans. But they're a bad dependency for autonomous systems. A dashboard is built around the assumption that someone will: - remember to open it - know what question to ask - click through the right filters - interpret the result manually - pass the answer back into the next decision That's a lot of friction. A tight feedback loop needs the opposite: - **low-latency access** to results - **structured outputs** the agent can reason about - **repeatable queries** the agent can run on its own - **clear success/failure signals** tied to real goals That is why agent-native analytics matters. It keeps the measure step inside the loop. ## What This Unlocks Once your agent can measure outcomes directly, it stops being just a coding tool. It becomes a growth operator. Now it can: - check every project each morning and tell you what changed - monitor funnels and find the biggest drop-off - compare channels by signups, activation, or retention - run experiments and ship winners - tell you not just **what** happened, but **what to do next** That is the real promise here. Not "AI can write code faster." The bigger shift is: > your agent can now act, measure, and adapt inside the same system. ## Get Started If you want to set this up today: - **Sign up** at [app.agentanalytics.sh](https://app.agentanalytics.sh) - **Start here:** [🦞 Set Up Agent Analytics with OpenClaw (5 Minutes)](/blog/setup-agent-analytics-with-openclaw) - **Read next:** [Talk to Your Analytics](/blog/talk-to-your-analytics) Because shipping faster is only half the story. The systems that win are the ones that can learn faster too. --- *Previously: [Grow Your Projects from Claude Desktop](/blog/grow-your-projects-with-claude-desktop) · [Funnels: See Where Users Drop Off](/blog/funnels-where-users-drop-off) · [A/B Testing Your AI Agent Can Actually Use](/blog/ab-testing-your-agent-can-use)* ## The Bullseye Method for Technical Indie Hackers > Use OpenClaw as an AI growth agent to explore channels, then use Agent Analytics to measure what actually drives activated users. URL: https://blog.agentanalytics.sh/blog/bullseye-method-for-technical-indie-hackers/ Date: 2026-03-05 | Author: Danny | Category: Guide Most technical founders don’t have a shipping problem. They have a **channel selection** problem. You can build features in hours now. Distribution is the bottleneck. That’s why *Traction* still matters. The Bullseye method is simple: - test multiple plausible channels, - measure outcomes consistently, - focus on the one channel that proves itself now. In 2026, this maps perfectly to our stack: - **OpenClaw** does research + execution, - **Agent Analytics** gives measurement + feedback, - you run a weekly **KEEP / KILL** loop from evidence (not vibes). ![Bullseye hero illustration](/images/blog/bullseye-hero.png) ## The classic idea (without the fluff) Bullseye is not “pick your favorite growth channel.” It’s: 1. Brainstorm broadly 2. Shortlist realistically 3. Test quickly 4. Focus aggressively Different summaries describe different step counts, but the behavior is the same: **Broad exploration → narrow focus.** ## Why this fits agent-native builders If you already use OpenClaw/Claude Code/Cursor workflows, your bottleneck is no longer execution speed. Your agent can now: - map competitor channel presence, - generate channel hypotheses, - prep assets and UTM links, - run tests, - report which channel produced activated users. That turns Bullseye from a theory into a repeatable operating system. ## Step 1) Agent-assisted channel brainstorming (evidence first) Use this prompt pattern: > Analyze our product, audience (technical indie hackers + micro-SaaS founders), and top competitors. Propose 10 acquisition channels ranked by speed-to-signal in the next 14 days. For each include: why now, 7-day test, effort, expected quality, kill condition. Force output into this table: | Channel | Why now | 7-day test | Effort | Success metric | Kill condition | |---|---|---|---|---|---| No matrix = no test. ## Step 2) Competitor channel reconnaissance with OpenClaw Before choosing channels, pull public evidence. Check: - Blog cadence + topics - Docs / integration footprint - Community presence (Reddit/HN/Discord) - Comparison / SEO pages - Launch and update patterns Example evidence table (directional only): | Competitor | Evidence URL | Observed channel | Signal | |---|---|---|---| | Plausible | https://plausible.io/blog | Content/blog channel | Active blog surface | | Plausible | https://plausible.io/docs | Docs-led channel | Public docs hub | | PostHog | https://posthog.com/blog | Content/blog channel | Active blog surface | | PostHog | https://posthog.com/docs | Docs-led channel | Public docs hub | | Umami | https://umami.is/blog | Content/blog channel | Active blog surface | | Umami | https://umami.is/docs | Docs-led channel | Public docs hub | Important: this shows **channel presence**, not channel performance. Use it to prioritize what to test, not blindly copy. ![Competitor reconnaissance diagram](/images/blog/bullseye-competitor-recon.png) ## Step 3) Build a practical shortlist for Agent Analytics Start with channels that fit technical buyers: 1. Developer communities (Reddit/HN/niche Discords) 2. Tactical blog guides (implementation-first) 3. SEO/comparison pages (high intent) 4. Integrations/partner ecosystems 5. Email to existing audience 6. Small paid tests (strict kill rules) Quick rule-of-thumb: - Need fast signal → communities + micro paid tests - Need compounding growth → SEO + blog + integrations - Need trust transfer → deep guides + docs + demos ## Step 4) Measure channel quality with Agent Analytics This is the key positioning: We are not “the tactic.” We are the **measurement layer** that makes tactics agent-operable. Use one shared funnel across all channel tests: `page_view -> cta_click -> signup_completed -> project_created` Attach attribution to every campaign link: - `utm_source` - `utm_medium` - `utm_campaign` Judge channel winners by **activated-user quality**, not raw clicks. Need help getting OpenClaw connected first? Start here: [🦞 Set Up Agent Analytics with OpenClaw (5 Minutes)](/blog/setup-agent-analytics-with-openclaw) ![Bullseye channel selection diagram](/images/blog/bullseye-selection-diagram.png) ## Step 5) Weekly Bullseye loop (KEEP / KILL) ### Monday - Agent delivers 10-channel matrix + competitor evidence - You choose top 3 channels ### Tuesday - Prepare links/assets, verify tracking ### Wednesday–Friday - Run 3 micro-tests ### Saturday - Agent delivers comparison report (funnel + activation + early retention) ### Sunday - **KEEP** 1 winner - **KILL/PARK** 2 losers - Queue 2 new tests This is how Bullseye compounds. ![Weekly keep-kill loop diagram](/images/blog/bullseye-weekly-loop.png) ## Weekly command checklist (copy/paste workflow) 1. “OpenClaw, generate top 10 channel hypotheses with kill conditions.” 2. “OpenClaw, map competitor channel evidence with URLs.” 3. “OpenClaw, create 3 test plans for this week.” 4. “OpenClaw, produce UTM link set for each test.” 5. “OpenClaw, summarize channel performance by activation funnel.” 6. “OpenClaw, recommend KEEP/KILL with confidence notes.” ## Common mistakes 1. Picking winners by clicks only 2. Testing too many channels at once 3. Running tests without kill conditions 4. Using inconsistent funnel definitions per channel 5. No weekly cadence ## Final framing - **Bullseye** = the classic strategy - **OpenClaw** = execution engine - **Agent Analytics** = measurement + decision loop That combination is the point: your agent can run growth work, not just write code. If you like this approach, next read: [Talk to Your Analytics](/blog/talk-to-your-analytics) --- ## Source appendix ### Bullseye / Traction - https://traction.usefedora.com/p/traction-a-startup-guide-to-getting-customers - https://books.google.com/books/about/Traction.html?id=A3_MBgAAQBAJ - https://www.penguin.co.uk/books/289806/traction-by-mares-gabriel-weinberg-and-justin/9780241242537 ### Attribution standard - https://support.google.com/analytics/answer/10917952 ### Agent Analytics references - https://agentanalytics.sh/ - https://blog.agentanalytics.sh/blog/setup-agent-analytics-with-openclaw/ - https://blog.agentanalytics.sh/blog/talk-to-your-analytics/ ### Competitor recon examples - https://plausible.io/blog - https://plausible.io/docs - https://posthog.com/blog - https://posthog.com/docs - https://umami.is/blog - https://umami.is/docs ### Secondary practical explainer - https://www.designwithvalue.com/bullseye-framework ## Advanced A/B Testing: Conditional Logic + Rich HTML Variants > Go beyond headline swaps. Test full sections, conditional experiences, and multi-step flows your AI agent can measure and improve. URL: https://blog.agentanalytics.sh/blog/advanced-ab-testing-conditional-rich-html/ Date: 2026-03-04 | Author: Danny | Category: Guide Most A/B tests are tiny. Change a button label. Change a headline. Maybe move a CTA. That works — but sometimes your biggest wins come from testing **full experiences**, not one line of text. This is where advanced experiments matter: conditional logic, richer HTML variants, and step-level testing that follows your real user journey. And the fun part: your **AI coding agent can run this loop for you** using Agent Analytics — manage tests, measure outcomes, check funnels, and queue the next iteration. ![AI Agent Growth Loop diagram](/images/blog/advanced-ab-loop-diagram.png) ## From “A vs B Text” to “A vs B Experience” Basic test: - Variant A: “Sign Up” - Variant B: “Start Free” Advanced test: - Variant A: short hero + CTA - Variant B: social proof block + value bullets + CTA - Variant C: persona-specific hero + FAQ + CTA Now you're testing *how the page sells*, not just one phrase. ## What to Test with Rich HTML Variants Use rich variants when the hypothesis is about structure, trust, or clarity: - **Hero composition** (headline + subtext + proof) - **Pricing sections** (table vs cards, feature order, guarantee copy) - **Signup flow blocks** (single-step vs guided) - **Onboarding content** (developer-focused vs marketer-focused framing) - **CTA context** (CTA with testimonials vs CTA with product screenshot) This is where a lot of conversion lift hides. ## Conditional Logic: Match the Experience to the User Not every visitor should see the same version. Conditional experiments let you adapt by context: - New visitor vs returning user - Mobile vs desktop - Pricing-page visitors vs docs-page visitors - Organic traffic vs ad traffic Example idea: - Mobile users see a shorter CTA section with fewer fields - Desktop users see fuller comparison content Same experiment goal, better fit for each audience. ## How to Structure Advanced Tests (Without Overcomplicating) A simple framework: 1. **Pick one bottleneck** (e.g., CTA click → signup drop-off) 2. **Write one clear hypothesis** (“Users need trust proof before signup”) 3. **Design 1–2 meaningful variants** (not 8 tiny tweaks) 4. **Measure the right goal** (signup, checkout, activation) 5. **Run long enough for confidence** 6. **Ship winner, then test next bottleneck** The goal is momentum, not perfect lab conditions. ## Where Agent Analytics Helps Most Agent Analytics gives your AI coding agent the full loop: - Query analytics + funnels and spot where users drop off - Suggest hypotheses based on real behavior - Create and manage A/B tests - Check lift, significance, and quality signals - Recommend shipping winners - Move to the next bottleneck automatically That’s how you go from random changes to compounding growth. ## Real Pattern: Step-by-Step Lift Teams usually see this sequence: 1. Start with a copy test (small win) 2. Move to rich variant test (bigger win) 3. Add conditional logic by segment (stability + better quality conversions) 4. Repeat across funnel steps You stop asking “which headline is better?” and start asking “which *experience* converts better for this audience?” ## Common Mistakes to Avoid - Testing too many things at once with no clear hypothesis - Measuring clicks when you really care about signups or activation - Calling winners too early - Ignoring segment differences (mobile/desktop, source, intent) - Running tests without feeding results back into the next iteration Advanced experiments are only valuable if they close the loop. ## The Agent Growth Loop in Practice Use this rhythm daily: 1. **Query:** “Where is conversion leaking?” 2. **Hypothesize:** “What should we change for this segment?” 3. **Experiment:** launch rich/conditional variant 4. **Iterate:** ship winner, queue next test That’s the real unlock: continuous optimization, not one-off tests. ## Get Started - Read the previous guide: [A/B Testing Your AI Agent Can Actually Use](/blog/ab-testing-your-agent-can-use) - Use funnels to find bottlenecks first: [Funnels: See Where Users Drop Off](/blog/funnels-where-users-drop-off) - Then run richer, conditional experiments on the highest-impact steps If your agent can code, deploy, and measure, it should also be running your growth experiments — end to end. ## Grow Your Projects from Claude Desktop > Use Claude Desktop as a growth agent to query analytics, spot bottlenecks, run experiments, and iterate without leaving your chat. URL: https://blog.agentanalytics.sh/blog/grow-your-projects-with-claude-desktop/ Date: 2026-03-01 | Author: Danny | Category: Guide You type "How is my-saas doing?" into Claude Desktop. Ten seconds later, you're looking at a full analytics dashboard — charts, trends, event breakdowns — rendered right inside the conversation. No browser tab. No dashboard login. Just a question and an answer. This is what happens when you connect Agent Analytics to Claude Desktop via MCP. ## MCP-UI: Analytics That Render in Your Chat Agent Analytics supports [MCP-UI](https://mcpui.dev/) — the emerging standard for rich UI components in MCP tools. When Claude queries your analytics, it doesn't just return text. It renders: - **Traffic charts** — events and users over time, right in the conversation - **Top pages** — ranked by page views with visual bars - **Event breakdowns** — page_view, cta_click, signup, feature_used — all at a glance - **Daily trend** — user activity day by day - **KPI cards** — total events, unique users, sessions, bounce rate, avg duration — with week-over-week deltas MCP-UI renders secure, sandboxed HTML components inline. It works with any MCP host that supports the standard — Claude Desktop, ChatGPT (via [mcpui.dev](https://mcpui.dev/)), and more. The result: you ask a question in natural language, you get a visual answer. No context switching. No dashboard tab. ## The Growth Loop Growing a product isn't one action. It's a loop: **Query → Hypothesize → Experiment → Iterate** Most people break this loop because each step lives in a different tool. Analytics in Mixpanel. Experiments in Optimizely. Code changes in your editor. Results back in Mixpanel. Context is lost between every step. With Agent Analytics in Claude Desktop, the entire loop happens in one conversation — and with MCP-UI, you get real charts and visuals at every step. ## Step 1: Query — "How's my site doing?" Start by asking Claude about your projects: > "How is my-saas doing?" Claude queries your data via MCP and renders a full dashboard — visitors, trends, top pages, conversion rates. No tab switching, no dashboard login. > "Show me the funnel from page view to signup" Now you see where users drop off. Maybe 500 people visit, 40 click your CTA, but only 2 sign up. The bottleneck is clear: CTA click → signup has a 95% drop-off. ## Step 2: Hypothesize — "Why are they dropping off?" This is where Claude shines. It has the data AND the context. Ask: > "Why do you think users click the CTA but don't sign up?" Claude can reason about it: maybe the signup form is too long, the CTA promise doesn't match the landing page, or there's friction in the flow. It suggests concrete hypotheses based on your actual data — not generic advice. ## Step 3: Experiment — "Let's test that" Now turn the hypothesis into an experiment: > "Create an A/B test on my-site. Test the current signup CTA against 'Start Free — No Credit Card'. Goal: signup event." Claude creates the experiment via the Agent Analytics API. It gives you the HTML to add the variant — just a `data-aa-experiment` attribute on your element. Declarative, no SDK: ```html ``` Deploy it. The experiment is running. ## Step 4: Iterate — "Did it work?" A few days later, check back: > "How's the signup CTA experiment doing?" Claude checks the results: Variant B converts at 4.2% vs control's 2.1%. Statistical significance at 94%. Almost ready to call it. > "And check the funnel again — did the drop-off improve?" The funnel shows CTA click → signup improved from 5% to 9%. Real progress. > "Ship variant B and let's test the next bottleneck" Claude completes the experiment, and you move to the next step in the funnel. The loop continues. ## Why This Works The power isn't in any single step. It's that **all four steps happen in one conversation.** Context flows naturally: - Claude remembers your funnel data when suggesting hypotheses - It knows which experiment is running when you ask for results - It connects the dots between the A/B test winner and the funnel improvement - It suggests the next thing to test based on everything it's seen No context lost between tools. No re-explaining. Just continuous iteration. ## Setting It Up Agent Analytics has an MCP server that works with Claude Desktop, Cursor, and any MCP-compatible client: 1. **Get your API key** at [agentanalytics.sh](https://app.agentanalytics.sh) 2. **Add the MCP server** to your Claude Desktop config — see our [Claude Desktop install guide](https://docs.agentanalytics.sh/installation/claude-desktop-cowork/) 3. **Start asking questions** — Claude now has access to your analytics That's it. No skill installation needed for MCP — the server handles everything. ## Works Beyond Claude Desktop The same MCP server works with: - **Claude Desktop** — full MCP support with MCP-UI for rich charts - **ChatGPT** — via [MCP-UI](https://mcpui.dev/) - **Cursor** — query analytics while you code - **Claude Code / OpenAI Codex** — via MCP - **Windsurf / Trae** — via MCP And for OpenClaw users, there's a dedicated [skill on ClawHub](https://clawhub.ai/skills/agent-analytics) with even deeper integration. ## The Full Picture Here's what your growth workflow looks like when everything is connected: 1. **Morning:** "How are my projects doing?" → quick stats across all sites 2. **Spot something:** "Show funnel for the pricing page" → 60% drop-off at checkout 3. **Hypothesize:** "What could improve checkout conversion?" → Claude suggests shorter form 4. **Test:** "Create an A/B test for checkout" → experiment is live in minutes 5. **Next morning:** "Check the checkout experiment" → variant B is winning 6. **Ship & repeat:** "Ship it and what should we test next?" → Claude suggests the next bottleneck Every day, your projects get a little better. No dashboards. No context switching. Just conversation. ## Get Started - **Sign up** at [agentanalytics.sh](https://app.agentanalytics.sh) - **Claude Desktop install guide** at [docs.agentanalytics.sh](https://docs.agentanalytics.sh/installation/claude-desktop-cowork/) - **MCP-UI** at [mcpui.dev](https://mcpui.dev/) — rich UI components for MCP - **Open source** on [GitHub](https://github.com/Agent-Analytics) --- *Previously: [Funnels: See Where Users Drop Off](/blog/funnels-where-users-drop-off) · [A/B Testing Your AI Agent Can Actually Use](/blog/ab-testing-your-agent-can-use) · [Set Up Agent Analytics with OpenClaw](/blog/setup-agent-analytics-with-openclaw)* ## What's New in Tracker.js > Declarative events, opt-in browser signals, privacy guardrails, and a public browser smoke suite make the Agent Analytics tracker safer for Claude Code, Codex, Cursor, and your AI agent. URL: https://blog.agentanalytics.sh/blog/whats-new-in-tracker-js/ Date: 2026-02-28 | Author: Danny | Category: Announcement The Agent Analytics tracker just got a major upgrade: richer events from one script tag, clearer privacy defaults, and a public browser smoke test that proves the tracker sends what it should from a real page. The important bit: the tracker is now more explicit. Your AI agent can still add product instrumentation quickly, but the broader browser signals are opt-in, URL-like values are sanitized before they leave the page, and identity only includes email when you call `identify()` with an email trait. Here's what's new. ## Public Browser Smoke Tests We added a real-browser smoke suite to the open-source tracker package. It runs in GitHub Actions on every push to `main`. The test boots Chromium, serves the built tracker on a local test page, captures real `/track` and `/identify` requests, and checks the browser contract end to end: - page views send from a real page - URL and referrer drop query strings and hashes - UTM fields are still preserved - `identify()` normalizes explicit email traits and does not send `email_hash` - click, outgoing link, download, form, scroll, impression, performance, error, SPA, and 404 tracking only fire in the expected conditions - duplicate script tags do not double-track - oversized payloads are bounded - collector failures do not throw into the host page You can run the same gate locally: ```bash npm run build npm test npm run test:tracker-smoke ``` That smoke suite is not a replacement for unit tests. It is the production confidence check: does the tracker actually behave on a page the way the docs say it behaves? ## Declarative Event Tracking You can track intentional product events without writing JavaScript. Add `data-aa-event` to the clickable element: ```html ``` Click the button → a `signup` event is tracked with `{plan: "pro"}`. No `onclick`, no `window.aa?.track()`, no extra script. Add properties with `data-aa-event-*` attributes: ```html See Pricing → ``` This makes it simple for your AI agent to add tracking to the elements that matter. ## Privacy Defaults and URL Sanitization The tracker now has a stricter browser privacy contract: - page URLs and referrers omit query strings and fragments - outgoing link, download, and form action URLs are sanitized the same way - UTM fields are preserved as explicit attribution fields - form field values are not collected - browser-side email hashing is gone - email is sent only when you explicitly pass it to `identify()` - oversized string properties are truncated so payloads stay bounded Example: ```js window.aa.identify('user_123', { email: 'founder@example.com', plan: 'pro', role: 'owner' }); ``` That sends identity through the identify endpoint. Normal event payloads should not infer or scrape email from URLs, text, form fields, or sticky properties. ## Outgoing Link Tracking Want to know when users click links to external sites? Add one attribute to your snippet: ```html ``` Every click on an external link tracks an `outgoing_link` event with a sanitized URL and destination hostname. Useful for affiliate links, partner referrals, and understanding where users go next. ## User Identification You can [link anonymous sessions to real users](/blog/identity-stitching) after signup or login: ```js // After successful signup/login window.aa.identify('user_123', { email: 'founder@example.com', plan: 'pro' }); ``` The previous anonymous ID and the new user ID are linked server-side, so you can see what happened before and after signup. Email is explicit; the browser tracker does not infer it. ## Safer Declarative Experiment Variants Declarative experiment rendering now favors safe text replacement instead of arbitrary HTML injection. That means your agent can still test copy variants, but the default path is safer for public pages. ```html
Build better with analytics your agent can read
``` Variant B swaps the text content. The control keeps the original content. ## Forced Experiment Variants Preview any experiment variant by adding a URL parameter: ```text https://my-site.com?aa_variant_hero_test=b ``` This forces variant B for `hero_test` — useful for QA, screenshots, and sharing a specific variant with your team before shipping. The forced exposure is tracked with `forced: true` so it can be handled separately from normal assignment. ## Cross-Domain Tracking Track users across related subdomains — app, docs, blog, and marketing — with the same anonymous ID. Quick setup: ```html ``` Links between those domains carry the anonymous ID so the same visitor journey can continue across surfaces. ## Do Not Track and Site Opt-Out The tracker can respect browser-level Do Not Track and a per-site opt-out: ```html ``` Users can also opt out for the site. The tracker now scopes browser storage by project/token so one site does not accidentally control another site's tracker state. ## Performance Timing Get real performance metrics for every page load with one attribute: ```html ``` The tracker captures DNS lookup time, TCP connection time, TTFB, DOM interactive, DOM complete, and full page load time as a `$performance` event. ## Time-on-Page Tracking Know how long users actually spend on each page. Enable it with the heartbeat attribute: ```html ``` The tracker sends `$time_on_page` when users navigate away. It pauses while the tab is hidden and resumes when visible. ## JS Error Tracking Catch JavaScript errors automatically for basic error awareness: ```html ``` Uncaught errors and unhandled promise rejections become `$error` events. They are capped and deduped so a broken page does not flood your analytics. ## Global Properties (`aa.set`) Set properties that attach to subsequent events: ```js // After login, tag later events with the user's plan window.aa.set({ plan: 'pro', team: 'acme-corp' }); // Clear a property window.aa.set({ plan: null }); ``` Useful for segmenting analytics by user type, plan, team, or any dimension you care about. ## Consent Management For regions that require consent before tracking, the tracker has built-in consent management: ```html ``` When enabled, events wait until consent is granted: ```js window.aa.grantConsent(); window.aa.revokeConsent(); ``` Consent state is scoped and persisted. Revocation stops tracking and clears the queue. ## Scroll Depth Tracking Know how far users actually scroll: ```html ``` A `$scroll_depth` event records the maximum scroll percentage for the page. ## Content Impression Tracking Track when specific sections become visible using `data-aa-impression`: ```html
``` When the element scrolls into view, an `$impression` event fires once for that element. ## Web Vitals Track Core Web Vitals — LCP, CLS, and INP — with: ```html ``` A `$web_vitals` event reports real user metrics when the browser exposes them. ## File Download Tracking Track downloadable links: ```html ``` A `$download` event includes the sanitized URL, filename, and extension. ## Form Submission Tracking Track form submissions without collecting field values: ```html ``` A `$form_submit` event includes form metadata like id, name, sanitized action, method, and classes. ## 404 Page Tracking Detect 404 pages and track them: ```html ``` Works with `` or the navigation response status. ## Visitor Intelligence Every event includes built-in visitor context: - **Session count** — is this their 1st visit or their 10th? - **Days since first visit** — how long have they been around? - **First-touch attribution** — which UTM source originally brought them? Your agent can segment funnels by new vs. returning visitors or see which acquisition channels bring users who come back. ## Campaign Attribution UTM parameters persist across the session and first-touch UTMs are stored. If a user arrives via `?utm_source=reddit`, navigates around, and converts later, the conversion can still carry the campaign context. ## Dev Mode The tracker auto-detects local development hosts and switches to dev mode, logging events to the browser console instead of sending them to the API: ```text [aa-dev] track page_view {path: "/pricing", ...} [aa-dev] track cta_click {id: "hero_signup", ...} ``` No test data polluting production analytics. ## All From One Script Tag Everything is configured through HTML attributes. Start small and opt into the browser signals you want: ```html ``` One script tag, explicit opt-ins, and data your AI agent can use. ## Get Started Already using Agent Analytics? You're already on the new tracker — it updates automatically. New here? - **Sign up** at [app.agentanalytics.sh](https://app.agentanalytics.sh/?onboarding=agent) - **Install the skill** from [ClawHub](https://clawhub.ai/skills/agent-analytics) - **Read the docs** at [docs.agentanalytics.sh](https://docs.agentanalytics.sh) --- *Previously: [Funnels: See Where Users Drop Off](/blog/funnels-where-users-drop-off) · [A/B Testing Your AI Agent Can Actually Use](/blog/ab-testing-your-agent-can-use) · [Set Up Agent Analytics with OpenClaw](/blog/setup-agent-analytics-with-openclaw)* ## Stitch Users Across Sites > Identity stitching connects anonymous and signed-in behavior so your analytics, and the agents querying it, see one user journey. URL: https://blog.agentanalytics.sh/blog/identity-stitching/ Date: 2026-02-27 | Author: Danny | Category: Guide Everyone starts anonymous. Someone lands on your site from a Google search. They read the pricing page, click around, come back the next day, and finally sign up. In your analytics, that looks like two different people — a mystery visitor with a random ID, and a registered user with your app's user ID. But it's the same person. And the whole story of *why* they signed up just got lost. ## What Is Identity Stitching? When a user identifies themselves — signs up or logs in — their previous anonymous activity gets linked to a stable user ID from your app. If you need support lookup by email later, send the email as a trait, not as the identity itself. ![How identity stitching connects anonymous and known users](/images/blog/identity-stitching-diagram.png) **Before:** Your analytics sees two strangers — an anonymous visitor who browsed your pricing page, and a signed-up user who activated a feature. No connection between them. **After:** One person. You can see the full path: they found you through Google, read pricing, came back the next day, signed up, and used the core feature within an hour. ## How It Works The Agent Analytics tracker gives every visitor an anonymous ID and records their activity. When they identify themselves, you add one line: ```javascript window.aa.identify(account.id, { email: account.email, plan: account.plan }) ``` Use a durable non-email ID — the same user, account, or member ID your backend uses — as the first argument. `traits.email` is optional and exists only for authenticated support lookup later. When it is present, the raw email is transmitted over HTTPS during identify so Agent Analytics can compute a scoped HMAC lookup index on the server. Raw email is not stored in event rows or profile traits by default, and browser-side SHA-256 `email_hash` payloads are no longer part of the public tracker contract. - Every past event gets linked to the real identity - Every future event uses the real user ID - Sessions, funnels, and retention all update automatically No query-time joins. No special configuration. The data just gets corrected — and every analysis your agent runs reflects the true picture. ## When to Use It The most natural place is right after your user logs in or signs up. If you're using OAuth (Google, GitHub), call it when they land back on your site. For email/password login, call it after authentication succeeds. Your agent can help you wire this up — just tell it: > "Add identity stitching after login on my app" ## Works Across Subdomains Too If your product spans multiple subdomains — `app.example.com`, `docs.example.com`, `blog.example.com` — identity stitching ties the whole journey together. A user reads your blog, visits the marketing site, signs up on the app, and reads the docs. With identity stitching, that's one continuous story — not four fragmented visitors across four subdomains. ## Server-Side Identify Sometimes the browser isn't the right place. The most common case: **OAuth callbacks**. When someone clicks "Sign in with Google," they leave your site entirely. The OAuth flow redirects them to Google, then back to your server. At that moment, your server knows who the user is — but the browser tracker hasn't caught up yet. Agent Analytics has a server-side identify endpoint for exactly this. Your backend can call it directly during the auth callback, connecting the anonymous visitor to the authenticated user before the page even finishes loading. ## What Gets Stitched Everything: - **Funnels** count anonymous page views and the signup as the same person's journey - **Retention** tracks users from their first anonymous visit, not from when they signed up - **Unique counts** don't double-count the same person before and after auth - **Session history** shows the complete picture — what they looked at before deciding to sign up ## Why This Matters for AI Agents Without identity stitching, your agent sees fragmented data. "How many users signed up and then used feature X?" becomes unreliable because the signup happened under one ID and the feature usage under another. With stitching, your agent sees one continuous user journey. It can trace the exact path from first visit → signup → activation → retention — and give you real answers about what's working and what isn't. Your agent can finally answer questions like: - "What pages do users visit before signing up?" - "How long from first visit to signup?" - "Do users who read the docs convert better?" - "What's the most common path to activation?" These answers are only possible when anonymous and authenticated activity are connected. ## Get Started Identity stitching is available now. One line of JavaScript, one API call from your server — and your analytics tells the full story. - **Sign up** at [agentanalytics.sh](https://app.agentanalytics.sh) - **Identity API docs** at [docs.agentanalytics.sh](https://docs.agentanalytics.sh/api/#tag/ingestion/POST/identify) - **Install the skill** from [ClawHub](https://clawhub.ai/skills/agent-analytics) --- *Previously: [Funnels: See Where Users Drop Off](/blog/funnels-where-users-drop-off) · [A/B Testing Your AI Agent Can Actually Use](/blog/ab-testing-your-agent-can-use)* ## Funnels: See Where Users Drop Off > Step-by-step conversion analysis your AI agent can query. Find the bottleneck, fix it, measure again. URL: https://blog.agentanalytics.sh/blog/funnels-where-users-drop-off/ Date: 2026-02-26 | Author: Danny | Category: Guide 754 people visited your landing page last month. 28 clicked a CTA. Zero signed up. Where did you lose them? Traditional analytics can tell you — if you log in, build a funnel report, configure the steps, and squint at a dashboard. Or you ask your agent: > "Show me the funnel from page view to signup" And it tells you exactly where the drop-off happens. ## What's New Agent Analytics now has built-in funnel analysis. Define the steps your users should complete, and instantly see: - **Conversion rate per step** — what percentage make it to the next step - **Drop-off rate** — where you're losing people - **User counts** — real numbers at each stage - **Average time between steps** — are users progressing quickly or stalling? Your agent can query funnels as part of its daily routine — no dashboard needed. ## How It Works A funnel is just a sequence of events you expect users to complete. You define the steps, Agent Analytics does the rest. ### For a SaaS landing page ``` page_view → cta_click → signup ``` ### For an e-commerce flow ``` page_view → add_to_cart → checkout → purchase ``` ### For a content site ``` page_view → scroll_50 → cta_click ``` Ask your agent to check any funnel — it queries the data and shows you a clear breakdown of where users progress and where they fall off. ## What Your Agent Sees When your agent checks a funnel, it gets back something like this: ``` Funnel: my-site (last 30 days) 1. page_view ██████████████████████████████ 754 users → 1.7h to next 2. cta_click █ 28 users 4% conversion 3. signup ▏ 0 users 0% conversion Overall conversion: 0% ``` Immediately clear: step 2 → step 3 is the bottleneck. People click the CTA but don't complete signup. That's where to focus next. ## Why Funnels Matter for AI Agents Your agent can edit pages, run A/B tests, and deploy changes. But without funnels, it's guessing where to focus. Funnels close the loop: 1. **Agent checks funnel** → sees 96% drop-off between CTA click and signup 2. **Agent creates hypothesis** → "The signup form is too long" 3. **Agent runs A/B test** → tests a simplified signup flow 4. **Agent checks funnel again** → conversion improved from 4% to 8% 5. **Repeat** on the next bottleneck Without funnel data, the agent tests random things. With it, the agent knows exactly which step is broken and focuses there. ## Funnels + Experiments This is where it gets powerful. Funnels and A/B experiments work together naturally: 1. **Check your funnel** — spot the biggest drop-off 2. **Run an experiment** — test a fix for that specific step 3. **Check the funnel again** — did the bottleneck improve? 4. **Move to the next step** — optimize the next biggest drop-off This is the agent growth loop: **Measure → Hypothesize → Test → Measure again.** Your agent can run this cycle continuously — checking funnels, creating experiments, and iterating — all without you opening a dashboard. ## Segment Your Funnels You can filter funnel steps by properties to dig deeper: - **By page:** funnel only for users who entered via `/pricing` - **By UTM source:** how do Google Ads visitors convert vs organic? - **By device:** are mobile users dropping off at a different step? Your agent can compare funnels across different segments to find which paths convert best and where different audiences get stuck. ## Real Data Here's a real funnel from our own landing page: ``` agentanalytics.sh — last 30 days page_view 754 users ↓ 4% conversion · avg 1.7h cta_click 28 users Overall: 4% ``` The 1.7-hour average time to CTA click tells us people aren't clicking immediately — they're reading, comparing, maybe coming back later. That's useful signal for how to structure the page and where to place CTAs. ## Get Started Funnels work with any events you're already tracking. No extra setup — just tell your agent what steps to analyze. - **Sign up** at [agentanalytics.sh](https://app.agentanalytics.sh) if you haven't already - **Install the skill** for your AI agent from [ClawHub](https://clawhub.ai/skills/agent-analytics) - **Read the docs** at [docs.agentanalytics.sh](https://docs.agentanalytics.sh) --- *Previously: [A/B Testing Your AI Agent Can Actually Use](/blog/ab-testing-your-agent-can-use) · [Set Up Agent Analytics with OpenClaw](/blog/setup-agent-analytics-with-openclaw)* ## A/B Testing Your AI Agent Can Actually Use > Run browser-side experiments with declarative HTML variants, no heavy SDK, and an API your agent can drive from setup to winner. URL: https://blog.agentanalytics.sh/blog/ab-testing-your-agent-can-use/ Date: 2026-02-23 | Author: Danny | Category: Guide You want to test whether "Start Free Trial" converts better than "Sign Up." With most A/B tools, that means a dashboard, an SDK, a snippet, and another place to remember to check later. What if your AI agent could handle the whole loop? ## A/B Testing, Agent-First Agent Analytics has built-in browser-side experiments that your agent can create, wire up, QA, and review through the same API/CLI workflow it already uses for analytics. That matters because the hard part usually isn't launching a test. It's remembering to: - define a real goal - wire the variant correctly - QA both branches - come back and decide what to ship Agent Analytics is designed so your agent can do that work with you. ## What makes it different - **Declarative variants** — for most tests, add `data-aa-experiment` and `data-aa-variant-*` attributes directly in HTML. - **Goal-first workflow** — create the experiment around a real business event like `signup` or `checkout`, not just page views. - **QA-friendly forcing** — load any variant directly with a URL param like `?aa_variant_signup_cta=new_cta`. - **Agent-driven lifecycle** — create via CLI, MCP, or API; read results later and decide whether to keep running, pause, or complete the test. - **Programmatic fallback** — when text swaps are too limiting, use `window.aa?.experiment()` for more dynamic UI changes. > Experiments are available on paid plans. If you still need the base tracker install, start with the [Getting Started guide](https://docs.agentanalytics.sh/getting-started/). ## The recommended workflow The current docs recommend a simple pattern: 1. Pick **one UI element** to test 2. Pick **one goal event** that reflects a real outcome 3. Create the experiment 4. Wire the variant declaratively where possible 5. QA both variants with forced URLs 6. Read results and decide whether to keep running, pause, or complete it That sounds obvious, but it's what keeps tests interpretable. ## Step 1: Choose one narrow change and one real goal Good first experiments are usually a single CTA, headline, or pricing message tied to a real event. Examples of good goals: - `signup` - `checkout` - `trial_started` - another core activation event Avoid using `page_view` as the goal unless the page view itself is the outcome you care about. A good prompt for your agent: > "I want to run an A/B test on my-site. Help me choose one page element to test and one goal event that reflects a real business outcome. Keep the scope to a single CTA or headline." ## Step 2: Make sure the goal event is already tracked Before you create the experiment, make sure the goal event exists and is named consistently. For simple interactions, the tracker docs now recommend declarative event tracking in markup instead of custom click handlers. Example: ```html ``` That sends a `signup` event with `{ plan: "pro" }`. If you prefer, your agent can also use `window.aa?.track()` when the event depends on runtime state. ## Step 3: Create the experiment Tell your agent: > "Create an experiment for the signup CTA on my-site with control and new_cta variants, using signup as the goal event." Or do it directly with the CLI: ```bash npx --yes @agent-analytics/cli@0.5.37 experiments create my-site \ --name signup_cta --variants control,new_cta --goal signup ``` A couple of small but important details from the docs: - Keep experiment names in `snake_case` - Keep the scope easy to explain later - `signup_cta` is much better than something vague like `homepage_test` ## Step 4: Wire the variant declaratively in HTML For most sites, this is the cleanest path. The existing text stays as control, and the variant lives in a `data-aa-variant-*` attribute. ```html

Start your free trial

``` How it works: - the original element content is the **control** - `data-aa-variant-{key}` provides the replacement text for a non-control variant - multiple elements can share the same experiment name and stay in the same assigned variant Example with multiple elements tied to one experiment: ```html

Build better products

Track what matters across all your projects

``` Want more than two variants? Add more `data-aa-variant-*` attributes. ```html

Sign up today

``` ## Step 5: Add the anti-flicker snippet If you're using declarative experiments, add this in `` before `tracker.js` so visitors don't briefly see the control before the assigned variant is applied: ```html ``` A few details worth calling out: - it uses `visibility: hidden`, not `display: none`, so layout stays stable - it only hides experiment elements, not the whole page - the 3-second timeout is a safety fallback if config loading fails - `tracker.js` removes `aa-loading` after variants are applied ## Step 6: QA both variants before sending real traffic This part was missing from a lot of older experiment workflows, and it should not be skipped. You can force variants with URL params: - `?aa_variant_signup_cta=control` - `?aa_variant_signup_cta=new_cta` That makes it easy for your agent or your team to: - check that both versions actually render - verify the goal event still fires - confirm there are no broken styles or copy issues A useful prompt: > "Show me how to force each variant locally so I can QA both versions, then verify that the signup event still fires correctly for each one." ## Step 7: Read results and make a decision Once the experiment has real traffic, ask your agent: > "Check results for signup_cta and tell me whether we have enough data to pick a winner. If we do, recommend whether to keep running it, pause it, or complete it with a winner." Or check directly: ```bash npx --yes @agent-analytics/cli@0.5.37 experiments get exp_abc123 ``` The results include per-variant exposures, unique users, conversions, conversion rate, `probability_best`, `lift`, whether there is `sufficient_data`, and a recommendation. Example shape: ```text signup_cta experiment results: control — 2.1% conversion | baseline new_cta — 3.8% conversion | +81% lift | 96% probability best Recommendation: ship new_cta ``` The key point: make the decision on the **goal event**, not on raw traffic. A variant with more exposures is not automatically better if it does not improve the thing you actually care about. ## The agent loop is the real advantage The nice part is not just that experiments exist. It's that your agent can operate the whole loop: 1. **Create** — define the test and goal 2. **Implement** — wire the markup or programmatic variant logic 3. **QA** — force both variants and verify tracking 4. **Monitor** — check results later through API, CLI, or MCP 5. **Decide** — recommend keep running, pause, or complete with a winner 6. **Repeat** — suggest the next focused test That is the actual difference between "we launched a test" and "we built an experimentation habit." ## For more complex UI changes If you need more than text replacement — different components, layout changes, conditional rendering, image swaps — use the programmatic API: ```js var variant = window.aa?.experiment('signup_cta', ['control', 'new_cta']); if (variant === 'new_cta') { document.querySelector('.cta').textContent = 'Start Free Trial'; document.querySelector('.hero-img').src = '/trial-hero.png'; } ``` `window.aa?.experiment()` gives deterministic client-side assignment, so the same user keeps seeing the same variant. Use this when declarative HTML isn't enough. For simple copy tests, declarative attributes are still the best default. ## Common mistakes to avoid Based on the current docs, these are the big ones: - testing too many elements at once - using `page_view` as the goal instead of a conversion event - creating the experiment before the goal event is actually tracked - forgetting to QA forced variants before sending traffic through the test - bundling copy, layout, and offer changes into one experiment - leaving an experiment active after you already know the winner ## Why this fits agents better than dashboard-first tools Traditional A/B platforms assume a human will keep opening the dashboard. Agent Analytics assumes your agent can: - create the experiment - update the code - verify both branches - query results later - tell you what to do next That makes experiments much easier to keep running in practice. ## Get started - **Start here** — [AI Agent Experiment Tracking](https://docs.agentanalytics.sh/guides/ai-agent-experiment-tracking/) - **Tracker reference** — [Tracker.js](https://docs.agentanalytics.sh/reference/tracker-js/) - **Access modes** — [CLI vs MCP vs API](https://docs.agentanalytics.sh/reference/cli-mcp-api/) - **Full API reference** — [Experiments API](https://docs.agentanalytics.sh/api/#tag/experiments) - **Create an account** — [app.agentanalytics.sh](https://app.agentanalytics.sh) - **Install the skill** — ask your agent to install from [ClawHub](https://clawhub.ai/skills/agent-analytics) - **Self-host** — it's [open source on GitHub](https://github.com/Agent-Analytics/agent-analytics) --- *Previously: [Set Up Agent Analytics with OpenClaw (5 Minutes)](/blog/setup-agent-analytics-with-openclaw)* ## Talk to Your Analytics > Your AI agent can answer analytics questions from quick counts to multi-step analysis across experiments, funnels, and retention. No dashboards. URL: https://blog.agentanalytics.sh/blog/talk-to-your-analytics/ Date: 2026-02-23 | Author: Danny | Category: Announcement ![Talk to Your Analytics](/images/blog/talk-analytics-hero.png) If you use [Claude Code](https://claude.ai/claude-code), [Cursor](https://cursor.com), [OpenClaw](https://openclaw.ai), [Codex](https://openai.com/index/introducing-codex/), or any AI coding assistant — you already have an AI agent. It writes code, runs commands, creates files. Agent Analytics is what happens when that agent can also *read your analytics*. We're not selling you an agent. We're the analytics platform your agent already knows how to use. Connect it, and every question you'd normally answer by opening a dashboard, your agent answers in seconds. ![Quick analytics queries via your AI agent](/images/blog/talk-analytics-simple-queries.png) ## Quick questions > "How many signups from Germany this week?" Your agent calls one endpoint: ``` 47 signups from DE in the last 7 days — up 31% vs previous week. ``` > "Where are my users?" ``` US 4,231 events 1,847 users DE 1,092 events 534 users GB 876 events 421 users FR 654 events 312 users JP 498 events 267 users ``` > "Which pages have 'pricing' in the URL?" ``` /pricing 1,842 views 923 users /pricing/enterprise 341 views 187 users /blog/pricing-update 89 views 54 users ``` These are single API calls. Group by country, substring match with `contains`, and get the answer back fast. Any agent can do this. ## Where it gets interesting The real power isn't a single query. It's combining them. Our API is agent-first. Every endpoint returns clean, structured data that an agent can reason about. So when you ask a complex question, your agent pulls from experiments, funnels, retention, breakdowns, and queries, cross-references the results, and gives you an answer. ![A/B experiment results — your agent finds the winner](/images/blog/talk-analytics-experiment.png) ### "Is the new checkout actually better?" > We've been running **checkout-redesign** for 14 days with enough traffic to be confident. > > The **free shipping badge** is the clear winner — 17% more purchases than the original. People get to the payment step at the same rate, but more of them actually complete it. The badge removes the "what's the total going to be?" anxiety right at the moment they're deciding. > > Removing the phone number field helped too — 8% more completions. Fewer fields, less friction, no surprise there. > > The green CTA button did nothing. Literally 0.2% difference. ![Organic vs paid traffic — which users actually stick around?](/images/blog/talk-analytics-organic-vs-paid.png) ### "Are organic users more valuable than paid?" You're spending $2,400/mo on Google Ads. Is it worth it? > Short answer: your organic users are worth about twice as much. > > People who find you through search stick around — 18% come back within a week, 9% are still active after a month. They sign up at 12% and about 1 in 25 eventually purchases. > > Your paid traffic looks good on the surface (similar visit counts) but the numbers drop off fast. Only 8% return within a week, 3% after a month. They sign up less and purchase at half the rate. > > That $2,400/mo is bringing people who click, look around, and leave. Your blog content is doing a better job of attracting people who actually become customers. ![Monday morning brief — your agent replaces the dashboard](/images/blog/talk-analytics-monday-brief.png) ### "Monday morning brief" This is where an agent fully replaces a dashboard ritual. Schedule the job in Paperclip, OpenClaw, Codex, Claude Code, or whatever agent environment you already use; Agent Analytics gives it the data, and the agent writes the brief: > **my-saas.dev — week of Feb 17–23** > > Good week. 8,234 events, 3,102 unique users — both up double digits. Your best week for signups since launch: 247, up 31%. Most of that came from Monday when your "Why We Switched" blog post hit the front page of Hacker News and drove 340 visits with a 12% bounce rate (your homepage bounces at 45% for comparison). > > The funnel improved too — 4.6% of visitors now make it all the way from landing to first activation, up from 3.8% last week. That's the onboarding changes paying off. > > Two experiments running. **pricing-test** has a winner: showing annual plans first converts 18% better, and we have 1,200 exposures — that's enough data, you can ship it. **onboarding-v3** only has 89 exposures per variant, needs about 5 more days. > > One thing to act on: that blog post is your best-performing content by far. Consider promoting it — the people it attracts are actually signing up. ## Why this matters A dashboard answers the questions you thought to ask when you built it. An agent answers the questions you think of right now — and it doesn't just return a number, it tells you what the number means and what to do about it. "Is the new checkout better?" isn't a chart. It's pulling experiment data, building funnels, comparing where users drop off, and telling you which variant to ship and why. That's the difference between analytics you look at and analytics you talk to. --- *Get started at [agentanalytics.sh](https://agentanalytics.sh). API docs at [docs.agentanalytics.sh](https://docs.agentanalytics.sh). Open source on [GitHub](https://github.com/Agent-Analytics).* ## 🦞 Set Up Agent Analytics with OpenClaw (5 Minutes) > Add analytics to all your projects and let your AI agent track what's working. No dashboards. Just ask. URL: https://blog.agentanalytics.sh/blog/setup-agent-analytics-with-openclaw/ Date: 2026-02-21 | Author: Danny | Category: Guide You shipped five projects this month. You're not opening Mixpanel for all of them. Your AI agent will. Agent Analytics is the analytics platform your AI agent can actually use — track page views, run A/B experiments, and report back to you in chat. And with [OpenClaw](https://openclaw.ai), setup takes about 5 minutes. ## What's New Your OpenClaw agent can now handle your entire analytics workflow: - Create projects and add tracking to your sites - Query stats across all your projects in one conversation - Run A/B experiments and check significance - Run a scheduled daily brief — OpenClaw owns the recurring job, Agent Analytics provides the data No dashboards. No browser tabs. Just conversation. ## How It Works ### 1. Connect your agent Sign up free at [agentanalytics.sh](https://app.agentanalytics.sh) and grab your API key. Store it in your environment secrets (`AGENT_ANALYTICS_API_KEY`), then tell your agent: > "Install the agent-analytics skill from ClawHub. My API key is in the environment variable `AGENT_ANALYTICS_API_KEY`" That's it. Your agent installs the [skill](https://clawhub.ai/skills/agent-analytics), picks up the key, and knows how to create projects, add tracking, query stats, and manage experiments. The key stays encrypted — it never appears in chat logs or conversation history. ### 2. Add tracking to your projects This is where it gets good. Tell your agent: > "Set up analytics tracking for my-site.com" Your agent will create the project, generate a tracking snippet, and tell you exactly where to paste it — one script tag before ``: ```html ``` Page views are tracked automatically — path, referrer, browser, device, UTM params. No configuration needed. Your agent also knows how to add custom events to your CTAs and key actions for deeper insights — signups, purchases, feature usage. Just ask: > "Add click tracking to the Get Started button and pricing CTAs" **Or do it yourself:** Create a project in the dashboard, copy the snippet, and paste it into your site. You'll need to add custom events manually via the tracking API. ### 3. Query your data Ask your agent: > "How's my site doing?" It queries analytics and reports back in chat — stats, charts, and experiment results all in one place: ![Agent reporting analytics in chat](/images/blog/query-data-chat.png) Stats, experiments, traffic, events — all from one conversation. Your agent queries the API and focuses on what matters across all your projects. ### 4. Schedule and manage experiments The real power is agent-owned automation. Tell OpenClaw: > "Create a recurring 8:00 AM analytics job. Every morning, query Agent Analytics for the latest 24 hours across my projects and send me a short brief with anomalies, winners, drop-offs, and one recommended action." With OpenClaw's scheduling, your agent owns the recurring task and Agent Analytics stays the measurement surface. The agent will: - Query stats for all your projects - Compare today vs yesterday and flag anomalies - Check running A/B experiments for statistical significance - Recommend winners and suggest next tests Daily briefs, A/B experiments, scheduling, and recurring tasks belong in the agent environment. Agent Analytics gives that agent the API, CLI, and MCP surface it needs to do the job. ## Why Not Traditional Analytics? Mixpanel and GA are built for humans clicking dashboards. Agent Analytics is built for AI agents that query via API. | | Traditional Analytics | Agent Analytics | |---|---|---| | **Create a project** | Manual setup per project | Ask your agent — it handles it | | **Query stats** | Open browser, navigate dashboard | Ask your agent — it queries for you | | **10 projects at once** | 10 dashboards to check | One API key, one conversation | | **A/B testing** | Separate tool (Optimizely, VWO) | Built in — your agent creates and checks experiments | | **Your agent owns the workflow** | Built for humans, agents bolted on | Built for agents from day one | ## Works With Any Agent Agent Analytics isn't just for OpenClaw. It works with any agent that speaks HTTP or MCP: - 🦞 **OpenClaw** — full skill with CLI integration - **Claude Code / Cursor / OpenAI Codex** — via the [installation guides](https://docs.agentanalytics.sh/installation/) - **Windsurf / Trae** — via the [installation guides](https://docs.agentanalytics.sh/installation/) - **Claude Desktop / ChatGPT** — via [MCP-UI](https://mcpui.dev/) ## Who It's For **Indie hackers** who ship 3-10 projects and lose track of which ones have traction. **Developers** tired of Mixpanel/Amplitude bloat for quick "is anyone using this?" questions. **AI-assisted devs** whose coding agent can query analytics instead of opening a dashboard. **Privacy-conscious devs** who want privacy-first analytics without cookies or PII. ## Get Started - **Sign up** at [agentanalytics.sh](https://app.agentanalytics.sh) — free tier includes unlimited projects and 1,000 events - **Install the skill** — ask your OpenClaw agent to install it from [ClawHub](https://clawhub.ai/skills/agent-analytics) - **Self-host** if you prefer — it's [open source on GitHub](https://github.com/Agent-Analytics/agent-analytics) --- *Next up: [Set Up Agent Analytics via MCP](/blog/setup-agent-analytics-with-mcp) — for Claude Desktop, Cursor, and any MCP-compatible client.* ## Introducing the Agent Analytics Blog > Updates, guides, and thoughts on analytics for products built, measured, and improved with AI agents. URL: https://blog.agentanalytics.sh/blog/introducing-agent-analytics-blog/ Date: 2026-02-20 | Author: Danny | Category: Announcement We built Agent Analytics because we noticed a gap: traditional analytics platforms are designed for humans staring at dashboards. But if you're shipping fast with AI agents, you need analytics that your agent can actually *read*. ## What is Agent Analytics? Agent Analytics is an open-source web analytics platform with a first-class HTTP API. Track page views, custom events, and user sessions — then query everything programmatically. ```bash # Track an event curl -X POST https://api.agentanalytics.sh/track \ -H "Content-Type: application/json" \ -d '{"event":"page_view","properties":{"path":"/blog"}}' # Query your stats curl https://api.agentanalytics.sh/stats?project=my-site&days=7 \ -H "X-API-Key: aak_your_key" ``` Your AI agent can call these endpoints directly — no browser automation, no screenshot parsing, no scraping dashboards. ## What to expect from this blog We'll be posting about: - **Product updates** — new features, API changes, and improvements - **Guides** — how to integrate Agent Analytics into your workflow - **Behind the scenes** — architecture decisions and things we've learned building on Cloudflare Workers + D1 Stay tuned. There's a lot more coming. ## How We Started Agent Analytics > I was paying $28/mo to track pageviews across 5 side projects. I didn't want dashboards. I wanted my AI agent to handle it. URL: https://blog.agentanalytics.sh/blog/how-we-started/ Date: 2026-02-12 | Author: Danny | Category: Story I build a lot with Claude Code and OpenClaw. Side projects, tools, landing pages. At any given time I've got 3-5 things live. Mixpanel has a solid free tier — the dashboards are genuinely impressive. But I didn't want dashboards. I wanted my AI agent to query the data. And for API access? Mixpanel charges $28/mo. Just so my agent could read pageview counts. Oh, and each project needed a separate API key. So I was paying $28/mo for the privilege of letting my agent access basic pageview data across a handful of side projects. It's like they forced me into building an alternative. 😄 ## What I Actually Wanted Reliable analytics with a solid API and CLI that my OpenClaw agent could use natively. Something it could install, query, and act on — without me opening a browser. Every tool I tried assumed a human would open a browser and look at charts. But I was already using my OpenClaw agent for everything else — deploying, managing content, running ads. Why should analytics be the one thing that pulls me back to a dashboard? ## So I Built One Agent Analytics started as a simple Cloudflare Workers project. Edge-deployed, fast, cheap to run. The core idea: **API-first analytics that any AI agent can use natively.** No dashboard-first design. No complex SDK. Four layers, each building on the last: 1. **A ~2KB tracking script** — auto-captures pageviews, custom events, CTA clicks, signups, errors. Drop it in before `` and it works. 2. **An API that does the thinking** — not just raw data. Stats, trends, funnels, retention, A/B experiment results, breakdowns by page, referrer, country, device. Even creating projects and managing experiments is done through the API. Everything is API-first. 3. **A CLI that wraps the API** — so any agent that can run `npx` has full access. Query stats, create experiments, check funnels — all from the command line. 4. **A skill that teaches the agent how to grow** — the [ClawHub skill](https://clawhub.ai/skills/agent-analytics) isn't just API docs. It's a growth playbook. It teaches your agent what to track, when to run experiments, how to read funnels, and how to close the growth loop. The skill turns your agent into a growth machine. ![Agent Analytics: four layers — tracking script, API, CLI, and skill](/images/blog/how-we-started-layers.png) I built it for myself first. Deployed it, added tracking to all my projects, and pointed my OpenClaw agent at it. ## What Changed Once my agent had access to real analytics data, things started compounding. My OpenClaw now: - **Installs tracking snippets** on new projects automatically - **Creates projects** on the analytics service - **Queries stats** across everything — my existing agent can run the scheduled brief - **Runs A/B experiments** — declarative HTML variants, no SDK needed - **Monitors growth** — flags anomalies, spots trends, suggests next moves Combine that with other skills to manage ads or social posts, and it really moves the needle. The agent doesn't just report numbers — it acts on them. ## The Growth Loop This is what clicked for me: AI agents need closed loops to work effectively. ![The Agent Growth Loop](/images/blog/how-we-started-growth-loop.png) My agent could already edit pages, create experiments, and iterate. But the **Measure Results** step was broken. There was no analytics tool my agent could query programmatically without me paying $20-40/mo for API access — and even then, none of them were built for how agents work. That's the gap Agent Analytics fills. Without it, the loop breaks. Your agent can write code and deploy, but it can't answer "did it work?" — so it can't improve. Agent Analytics is the measurement layer that closes the loop. Stats tell you if a project is alive. Funnels show where users drop off. Retention shows if they come back. Experiments tell you if a change was better. Your agent needs all of those signals to make good decisions about what to do next. ## Available Now Agent Analytics is available as a [ClawHub skill](https://clawhub.ai/skills/agent-analytics). Setup is just installing the skill and connecting your projects. The skill plus the analytics service turns your OpenClaw into a growth machine. It's also [open source](https://github.com/Agent-Analytics/agent-analytics) — self-host it on Cloudflare Workers, a VPS, or anywhere Node.js runs. Your data stays yours. Or use the hosted version at [agentanalytics.sh](https://app.agentanalytics.sh) — free tier includes unlimited sites and 1,000 lifetime events to get started. --- *Read next: [Set Up Agent Analytics with OpenClaw (5 Minutes)](/blog/setup-agent-analytics-with-openclaw)*