# 1000个精准用户和10万个普通用户，哪个更有价值？

URL: https://caijiao.org/posts/214
Source: docs/posts/214.md
Description: 假设十万个普通用户带来十三万次会话，按每千次会话六点八九美元只值八百九十六美元；一千个精准用户哪怕只有百分之二点四掏钱，两边就打平。

TinyWow 的访问构成里，美国占 20.17%，印度占 14.63%，英国占 3.22%。这句话比"月访问 180 万到 230 万"更能解释一个现象：同样是十万访客，两个站点的收入可以差出好几倍。

![TinyWow 官网首页截图](/images/2026-09/tinywow.com.png)

*TinyWow 首页的分类卡按工具数量排：PDF 45+ 最多，Video 和 AI Write 各 10+。*

要把这道题答清楚，只能把两边都换算成同一个单位的钱，再比大小。只比人数是比不出结果的，因为人身上挂着的东西不一样：一边是"这次访问值多少钱"，另一边是"这个人一年能带来多少钱"。

所谓精准，落到操作层面是可以量化的一句话：他搜的那个词，能不能反推出一件他正在花钱去做的事。能反推出来的人，一千个已经够用；反推不出来的人，再多也只是在页面上滑过去。

## 10 万这一侧，先要扣掉一层地域折扣

TinyWow 有 250 多个免费工具，每月 180 万到 230 万访问，可美国访客只占两成出头。展示广告的单价随访客所在地浮动，近八成流量来自美国以外，等于把整站的平均单价往下拉。

再看它的来源构成：约 47.29% 是直接访问，约 33.83% 来自搜索。近一半的人不需要再付一次排名成本，这部分流量才是最值钱的部分，而它的价值同样要先乘过地域系数才作数。

## 把两边都换成美元：1000 人这一边赢

先算 10 万普通用户。假设人均带来 1.3 次会话，这是我的假设，10 万用户对应 13 万次会话；按 terrific.tools 公开的每千次会话 6.89 美元计算，130 乘以 6.89 约等于 896 美元一个月。这就是十万普通用户的广告价值，数字并不夸张。

再算 1000 个精准用户。参照 Data Fetcher 的客单价——23000 美元 MRR 除以 600 个付费客户约合 38 美元，这是我按公开数据反推的——假设其中 5% 付费，得到 50 个付费客户，50 乘以 38 就是 1900 美元月收入。

两个数字摆出来，1000 人这边是 10 万人那边的两倍有余。更关键的是临界点：用 896 除以 38 约等于 23.6 个付费客户，也就是说这 1000 人里只要有 2.4% 掏钱，两边就打平。对一个"来的人带着具体问题"的页面来说，2.4% 是很低的门槛。

反过来把这 1000 人拿去跑广告展示，1300 次会话按同一单价只有大约 9 美元。同一批人，挂上不同的变现装置，结果能差两百倍。

这个差别还可以换个方式读：决定结果的是变现装置，不是人数本身。先决定要让这批人去做一件什么事，再倒推需要多少这样的人，顺序反过来就容易在人数上纠缠不清。

## 1000 人这一侧的麻烦：它也看得见天花板

把同样的算式往上推一层，就会碰到它的边界。要拿到 Data Fetcher 那种 23000 美元的月收入，按三十八美元客单价需要约六百零五个付费客户；若转化率仍是前面的百分之五，一个月就得找到约一万两千一百个带着同一类具体问题的人。这个量的精准流量已经不是写几篇页面能凑出来的，它通常要靠产品本身被人反复提起才攒得起来。

所以更现实的做法是两边都要：广告那一层把广泛流量接住，转化这一层只挑最有可能掏钱的那部分人去优化。十万和一万的争论听起来像选择题，实际上多数站点都是同时握着这两条线，只是比重不同。

## Gusto 的一万七千次访问说明了剩下的一半

Gusto 那个免费的时薪工资计算器，所在词 wage calculator 搜索量 17000，月访问约 17776，来的人都在核算员工薪资。Shopify /tools/ 下的利润率计算器峰值月访问超过 2 万，来的人都在开店。

这类页面的价值不在规模，在于访问本身就是一次举手。1000 个这样的访问者，比十万个搜完就关页面的访问者更容易被推到第二步，也更值得为它单独写一页。

它们的另一个特征是竞争者极少。一个大词背后往往站着几十个站点，而"具体税种的时薪怎么算"这类问题，愿意认真做一页的人不多。人群少，恰好也是门槛。

代价是要耐得住冷清。这类页面上线后的头几个月通常没什么动静，等到收录稳定、外链慢慢攒起来，某个季度突然开始稳定进人，之后再回落一点，然后横在那里。习惯这种曲线的人，才适合拿一千个精准用户去换十万次展示。

## 混合收款时，金额要算准

一个站同时收广告费和订阅费，两套金额会流进同一张报表。不要用 JavaScript 原生浮点去累加：多个 5.99 相加会出现 5.989999999999999 之类的尾差，月度汇总时肉眼可见。把金额交给 [decimal.js](/decimaljs/) 处理成定点数，税率与折扣率另用字符串保存，是这个环节最简单的正确做法。

至于那 2.4% 从哪来，取决于页面把入口给了谁：广告位越密，首屏越慢，愿意掏钱的人越容易在半路掉出去。要同时向两边要收入，至少得在 [SQLite](/sqlite/) 里把"哪个入口进来的人点了付费按钮"记成一条事件，而不是对着 [Google Search Central](/google-search-central/) 后台的会话总数反推原因。

记事件这件事听起来不起眼，可它决定了你后面能不能回答一个最要命的问题：多出来的这一千个人是从哪一页来的。少了这张表，所有的优化都只能靠感觉排序。

人数本身从来不是资产，能追溯到具体某笔钱的人数才是。

---

*数据来源：TinyWow 流量、地域与来源占比为第三方估算（2026 年上半年）；terrific.tools、Data Fetcher 数据来自创始人公开披露；Gusto、Shopify 流量为第三方估算。*