Product Growth Scanner

Use the Product Growth Scanner when you only have a public URL or want a scanner-informed preview before your agent installs analytics from the codebase.

The scanner reads a public site like a senior product manager or growth lead would. It looks for the decisions the site is trying to drive, the blind spots in current measurement, and the first signals worth collecting.

• growth questions the site should be able to answer
• prioritized minimum viable instrumentation
• measurement blind spots
• what each recommended event unlocks
• what not to measure yet

Start from the web page:

Scan your website

Or ask your coding agent to use the scanner when repo access is unavailable or when you want a scanner-informed preview before it inspects code and installs tracking:

Use the website scanner to review this public product surface before setup. Tell me what data we are not collecting yet. After browser approval, create or identify the matching project, ask me to confirm the initial product goal before storing durable context, inspect the repo if available, install the project-owned tracker, add only meaningful events tied to the confirmed goal, explain what each event enables, and verify the first useful event.

The goal is not to add more events. The goal is to give the agent enough product judgment to install the first events that create useful answers.

The scanner also gives your agent eyes on data that does not exist in your analytics yet. For deeper work, ask it to scan additional public websites you own, such as marketing, docs, pricing, signup, support, changelog, or launch pages, then compare the blind spots before it instruments the code.

When to use it

Use the scanner before setup when:

• your site is live but analytics is not installed yet
• a product, landing page, docs site, or signup flow needs clearer growth measurement
• you own multiple public sites or pages that all shape the same growth loop
• page views alone will not answer what to improve next
• you want to avoid random click tracking
• you want the agent to find useful data you are not collecting yet
• you want a short plan the agent can continue from

Do not use it as a full conversion audit. It is intentionally narrow: what should be measured first so the next growth questions have useful data.

Optional scanner-informed setup preview

The Product Growth Scanner is a preview and sales/setup helper, not the normal center of Agent Analytics setup. When repo access exists, the agent should inspect the code and workflows before deciding what to install.

When an agent uses scanner context before installing analytics, it should:

1. analyze the public root page
2. scan any additional owned public surfaces the user names for the same growth loop
3. read minimum_viable_instrumentation, current_blindspots, not_needed_yet, goal_driven_funnels, and after_install_agent_behavior
4. compare blind spots across scans before deciding what to install first
5. request browser approval or login if full analysis is needed
6. create or identify the matching Agent Analytics project, using the scanned URL as the primary surface URL/origin when you run create <project> --domain <url>
7. ask the user to confirm the initial product goal before storing durable context
8. install the tracker plus only the high-priority recommendations tied to that confirmed goal
9. verify the first useful recommended event
10. summarize what the installed events now let the agent answer

Anonymous preview

Anonymous previews analyze the supplied root domain and show a one-time measurement plan.

They do not create an aas_* agent session and they do not attach the analysis to an account by themselves.

The preview is enough to see the first measurement plan. Full analysis and project linking require browser approval or account auth.

Agent handoff

After the preview, use this handoff prompt with your coding agent. The agent should handle project creation, installation, and verification from the analysis context without depending on scanner state.

Use the Agent Analytics website-analysis preview as setup context.
Map any additional owned public sites I name to the right project or portfolio.
Create or identify the matching project.
Ask me to confirm the initial product goal before storing durable context.
Install only the high-priority measurement plan tied to that goal.
Do not add generic click tracking.
Verify the first useful recommended event.
Explain which growth question each event unlocks.

What the measurement plan includes

Agents should start with minimum_viable_instrumentation.

Each recommendation includes:

• event name
• priority
• where to instrument it
• why it matters
• what growth question it unlocks
• implementation hint

Use the smallest tracker capability that answers the question:

• data-aa-event for named click or intent events
• data-aa-impression for meaningful section exposure
• window.aa.track(...) for computed client state
• server-side tracking for durable outcomes such as completed signup, payment, install, or account creation

Page views, paths, referrers, UTMs, device/browser fields, country, session ids, session count, days since first visit, and first-touch attribution are automatic. Do not add custom duplicate events for those.

Good prompts

Run an Agent Analytics product growth analysis for this project, then install only the high-priority recommended events. Avoid generic click tracking and verify the first useful event.

Scan our owned marketing site, docs site, and signup surface before setup. Compare the measurement blind spots and tell me which data we are not collecting yet, then install only the first high-priority events.

Use the website-analysis preview as setup context. Create or connect the Agent Analytics project, ask me to confirm the initial goal, install the minimum viable instrumentation tied to that goal, and explain which growth questions the first events will answer.

Review this site's Agent Analytics analysis. Tell me which measurement blind spots matter now and which recommendations should wait until we have more traffic.

What success looks like

The first successful setup is not “analytics installed.”

It is:

• the project exists
• the tracker is live
• one high-priority recommended event has been verified
• the agent can answer the first useful growth question from real traffic

After that, continue with Session Paths or AI Agent Experiment Tracking when there is enough traffic to diagnose and test changes.