Stop 2 · the warehouse
Found what the numbers were hiding, then fixed it.
Channel3YC S25
Engineer Intern, GTM · May to Jul 2026 · New York


Product-data API for AI shopping agents.
- The problem
- A 25,000-page launch flooded Google's crawler, and the signup metric the company steered by was mostly bots.
- What I did
- Diagnosed why dead pages never left Google's index, shipped an indexing quality gate, and rebuilt signup tracking to measure the real funnel.
- The result
- Google's daily crawl payload back to 0.03 GB, the first real signup funnel (1,394 signups, 124 verified), and the most-cited of 1,493 domains in tracked AI answers.
- less data Google had to crawl each day, back to pre-launch levels
- 98%less data Google had to crawl each day, back to pre-launch levels
- bot inflation I found in the signup metric
- 4,000xbot inflation I found in the signup metric
- most-cited domain in tracked AI answers
- #1 of 1,493most-cited domain in tracked AI answers
Crawl health
25,000 auto-generated brand pages went live two weeks before I started. They were orphaned and thin. Googlebot's daily download went from 0.03 GB to a peak around 1.23 GB, and average response from 49ms to 509ms.
Brand routes returned 500 on missing brands, which tells Google to retry, so dead pages never cleared. I changed them to 404s, built a brand directory hub so pages were linked, then shipped an indexing gate (quality threshold, robots, sitemap, JSON-LD, pagination).
Crawl payload returned to 0.03 GB/day and response time to 88ms, while Google crawled more pages per day than before.
Google Search Console crawl stats, period means, Apr 30 to Jul 28, 2026
The metric that didn't exist
The signup number was a pageview action inflated about 4,000x: 1.79M person records in three weeks, all with dead attribution. The docs site had no analytics at all.
I rebuilt tracking (GTM on the site and docs, PostHog events, defined conversions) and ran the first real funnel: 1,394 reached signup, 124 verified email. 8.9%.
A logging gap found before launch
I queried 30 days of API metrics in AWS Athena: 1.74M successful calls and zero 401s, ever. Auth failures raise before any handler runs, and metrics are recorded inside handlers.
The new payment flow's 402s had the same shape, so payment conversion would have been unmeasurable. I fixed the logging path before launch.
Distribution where developers and agents look
I listed the MCP server on 7 registries (Smithery: 95 tool calls; Glama: 305 downloads, marked official).
I got Channel3's component registry into shadcn's official directory, after first fixing a license contradiction in the repo (README vs package.json, no LICENSE file). The final directory PR was a +7/−0, one-file change, validated offline against the repo's own schema first. The shadcn listing drove 478 pageviews.
Answer engines
I wrote the posts that made trychannel3.com the most-cited domain of 1,493 in tracked AI answers. Copilot citations grew 12.7x (Bing Webmaster Tools, 0.61 to 7.75 per day). One post ranks #1 on Google for "best product data API."
A developer request that shipped
I built KitDen in an afternoon on the API. Three developers asked for access, all three integrated. One needed product dimensions; I took it to engineering and width, depth and height shipped as structured attributes.
What didn't work
- I bet on SEO at Channel3 and it mostly lost: 744 brand pages got 159 Google clicks, and my posts got single digits.
- Then a worse mistake: I wrote off the MCP listings as dead because they sent zero traffic. An MCP server never sends traffic. Agents call it directly. It had 95 tool calls, and the directory was half of all Copilot citations.
- Now I ask what a channel is supposed to produce before deciding it failed.
- TypeScript
- Cloudflare Workers
- PostHog
- AWS Athena
- FastAPI
- MCP