小语种SEO按母语人口排优先级，排在最前面的那几门往往最后才该动

摘要：把小语种按母语人口从多到少排一列，再从上往下做，是这几年最常见也最贵的一种排法。真正决定一门语言值不值得做的不是有多少人说它，而是三个语言层的量：能用它在网上搜商品的人占多大比例、它的词形与写法会把关键词表撑成几倍、这门语言里已经有多少人在写同一类内容。这三个量都能手工估出来，估完之后排出的顺序，跟按人口排的那一列常常差着一大截。

为什么按母语人口排小语种优先级，第一年就会做反？

母语人口和会用这门语言搜商品的人不是一个数

拿到一张语言人口表，最直接的用法就是从上往下数，挑几门排名靠前的语言先做。

这张表统计的是把某门语言当母语的人，而不是会在浏览器地址栏里用这门语言打字的人。

两者之间隔着三道过滤：这些人有没有上网、上网时用不用这门语言、买东西时会不会用这门语言搜。

每过一道，人数就掉一截，掉的比例还在不同语言之间差得很远。

有的语言三道过滤下来只剩两成，有的语言能剩八成，而人口表上它们可能只差一名。

按未经过滤的数字排序，等于拿一个跟结果关系很松的量在排优先级。

还有一层过滤常被忽略：同一门语言在手机和电脑上的实际使用比例并不一致，手机出厂时预装的界面语言往往是本地语言，而办公电脑常年停在另一套界面上，同一批用户在两台设备上会打出两种语言的查询。

把这三道过滤画成一个漏斗，再给每一层填上自己市场的实际比例，最后剩下的那个数才是这门语言真正的目标人群。多数团队从来没画过这个漏斗，直接拿漏斗口的数字当结论用了好几年。

名义语言人口里，有多大一块根本不用这门语言搜

很多市场存在一门通用的第二语言，它在搜索这个场景里的占比远高于日常口语。

原因不复杂：搜索框里打的多半是商品名和型号，而这类词在当地往往就是外来形态。

受教育程度越高、品类越偏技术，用第二语言搜的比例越高，这一点在任何市场都成立。

所以同一门语言在食品品类里可能覆盖九成搜索，在电子配件品类里只覆盖三成。

这意味着优先级不是语言的属性，而是语言与品类交叉之后才成立的一个量。

不带品类谈某门语言值不值得做，讨论一定会停在各说各话上。

有个不用查任何统计就能判断品类外来度的土办法：看这个品类的商品包装上，规格参数是用哪种语言印的。包装印本地语言的品类，用户多半也用本地语言搜；规格全印英文的品类，用户大概率照着包装打字。

还有一个信号是本地零售商自己的选择：他们的商品标题用哪种语言写品类名。做生意的人对用户怎么搜最敏感，他们的标题写法本身就是一份免费的市场调研结论。

一门语言的实际可触达面该怎么估

手上没有现成数字的时候，可以用三个能自己拿到的量拼一个估计值。

第一个量是这个市场的上网人数，各国统计部门每年都会公布，误差不会大到影响排序。

第二个量是用这门语言的网页在该市场网页里的大致占比，靠抽样搜十几个品类词就能看出量级。

第三个量是本站已有流量里来自这个市场的部分，按浏览器语言与访问语言分开数一遍。

三个量相乘得到的不是精确值，但它跟人口表给出的顺序常常完全不同，这就够用了。

估算的目的从来不是算准，是把明显排错的位置挪回去。

第四个可以自己拿到的量藏在服务器日志里：浏览器发过来的语言偏好请求头一直在被记录，只是几乎没人去统计它的分布。把这一栏按国家分组数一遍，得到的语言占比比任何外部报告都贴近你自己的用户。

一门语言的关键词表会膨胀几倍，能不能先算出来？

词形复杂度决定词表的基数倍数

同一个商品概念，在不同语言里对应的搜索写法数量差得非常悬殊。

词形基本不变的语言，一个概念对应一到两种写法，词表规模跟中文差不多。

名词有格变化的语言，一个概念要展开成六到十几种写法，还要跟形容词的形态配套。

后缀能一层层往上叠的语言更夸张，一个词根接出来的形态在实际语料里能有几十种。

这个倍数不用查论文，翻一眼这门语言有没有公开的词干剥离算法、规则有多少条就能看出量级。

规则条数越多、例外越密，说明形态越复杂，词表膨胀得越厉害。

Snowball公开的词干算法清单是个很省事的参照，能查到算法的语言，形态规律基本都已经被总结清楚。

看词干算法时有个细节要单独盯：规则条数之外还要看它附带的例外词表有多长。例外表越长，说明规则本身覆盖不了的情况越多，这门语言上任何按规则做归并的工具都会漏，人工核对的比例要相应提高。

另外要注意形态复杂度和用户实际打字习惯不完全一致。有些语言虽然名义上有十几种形态，但搜索框里出现的高频形态只有三四种，剩下的形态在书面语里才用。先按语料估一遍高频形态占比，能把词表规模砍掉不少。

估形态倍数时不要只看名词，形容词跟着名词变形的语言，商品标题里的属性词会连带展开一遍，实际组合数是名词形态数乘形容词形态数，这个乘法关系才是词表真正膨胀的地方。

书写系统的数量是第二个乘数

有的语言只有一套字母，有的语言在实际使用中同时跑着两套甚至三套。

两套字母意味着同一个词有两条完全不同的字符序列，搜索时不会自动互通。

更麻烦的是第三种形态：用户拿另一套字母把这门语言拼出来，既不属于第一套也不属于第二套。

这三种形态在关键词表里都要占位置，否则总有一批搜索落不到你的页面上。

Unicode已经收录的书写系统列表可以用来确认一门语言到底牵涉几套字符集合。

确认完之后，把书写系统数量当成一个直接乘到词表规模上的系数就行。

还有一个容易漏的细节：同一套字母在不同语言里用到的字符子集并不相同，多出来的那几个字母往往正是区分语言的关键。做字符白名单和输入校验时要按语言取子集，整块拿一套字母表进来会放进一堆本语言根本不用的字符。

地区变体是第三个乘数

一门语言跨几个国家使用时，同一个商品在各地的常用叫法经常不一样。

这不是方言口音的差别，是名词本身换了一个词，两边的用户互相听得懂但不会那么搜。

变体的数量取决于这门语言覆盖几个有独立零售市场的国家，通常在一到四之间。

把变体数当乘数时要打个折，因为大量通用词在各地是一致的，只有品类名和属性词会分叉。

经验上打到六折比较接近实际，两个市场的变体大约让词表增加六成而不是翻倍。

这一层的成本主要不在写词，在于要有人能判断哪个词属于哪个市场。

实际拆词表时会发现，分叉最密集的从来不是品类主词，而是两类词：容器与包装单位的叫法，以及折扣促销的固定说法。前者影响商品标题，后者影响活动页，两类都直接对着转化，偏偏最容易被当成小事一笔带过。

判断某个词有没有跨市场分叉，最快的办法是把它丢进两个市场各自的本地零售站站内搜索里，一个有结果一个没有，就说明这个词在其中一边不是常用说法。

三个乘数连乘之后的实际工作量

形态倍数、书写系统数、地区变体系数三者相乘，得到的是这门语言的词表膨胀系数。

系数落在一到三之间的语言，关键词研究的工作量跟英语市场是一个量级。

系数落在三到八之间的，要多准备一倍的时间，工具给的数据要人工重新归并。

系数超过八的语言，靠工具跑不出可用词表，必须先建一套形态归并规则再谈选词。

把这个系数写在优先级表的第二列，比写搜索量有用得多，因为它直接对应人力预算。

顺带一说，这一列也能帮团队回答一个老问题：为什么同样是做一门语言，有的两周就上线，有的排期三个月还没出词表。

把这三个乘数写清楚以后，排期争论会少一大半。

膨胀系数还有一个不太直观的用处：它同时决定了内部链接的维护成本。在形态丰富的语言里，同一个目标页面在不同上下文里的锚文本要跟着句子变形，写死一种形态的内链读起来会明显不通顺，这部分工作量按页面数线性增长。

竞争密度该看工具给的难度分，还是看这门语言里有多少人在写？

关键词工具在小语种上给的数字为什么不能直接用

工具给的搜索量和竞争度都建立在样本上，样本量在小语种上往往薄到不可靠。

更常见的问题是它把一个词的所有形态合并成一行，让人以为这个词的搜索集中在一种写法上。

还有一种情况是它把这门语言的查询和邻近语言的查询混在同一个数字里。

数字越小的语言，这几种误差占比越高，最后可能整整差一个数量级。

所以在小语种上，工具数字适合用来判断有没有需求，不适合用来判断需求有多大。

判断竞争强弱要换一个更笨但更可靠的口径。

还有一个结构性偏差：这类工具通常按语言聚合数据，而不是按国家。跨国使用的语言拿到的是几个国家加总的数字，其中大头可能来自你根本不打算做的那个市场。拿到数字后要按国家再拆一次，拆不出来就只当作有无需求的信号。

还要留意一种数据错配：有些工具会把拼写相近的邻近语言词条归到同一行，两门语言在词表层被悄悄合并，你看到的搜索量里混着一部分根本不属于这个市场的查询。

本地内容供给密度怎么手工估

挑十个这门语言里的核心品类词，逐个搜一遍，只看首页十条结果。

数三件事：有几条是本地站、有几条是跨国站的翻译版、有几条根本是别的语言的页面。

本地站占八条以上的品类，内容供给已经饱和，进去要拼的是内容质量而不是有没有内容。

本地站不足三条、其余全是翻译版和外语页面的品类，说明这门语言里几乎没人认真写过。

后一种情况是最值得先做的，因为把内容写对本身就是差异化，不需要额外的花招。

这个手工采样十个词只要半小时，比任何一个难度分都更贴近实际情况。

数结果的同时顺手记一件事：这些本地站的页面是什么时候写的。如果前十条里的本地内容大多停留在两三年前，说明这个市场没有人在持续更新，入场之后只要保持更新节奏就能拿到位置，成本比数字显示的低。

这个采样还能顺带回答一个问题：这个品类的结果里，有多少条是标题堆词、正文空洞的老式页面。这类页面在很多小语种市场里仍然占着位置，而它们经不起任何一次针对内容质量的调整，2003年那场影响面很大的算法调整已经演示过一次这类页面是怎么整批消失的。

采样时把结果按页面类型记一列，商品列表页、单品页、导购内容页各占多少。三类比例不同，代表这个市场的内容竞争阶段不同，也决定你第一批该铺哪一类页面才最快见效。

供给稀薄和需求稀薄要分开看

一门语言里没人写内容，可能是因为没人搜，也可能是因为没人愿意做。

这两种情况看上去一样，处理方式完全相反，判错了就是白扔预算。

区分的办法是看这个市场的广告投放密度，有人肯为这类词付钱，说明需求是真的。

广告位也空、自然结果也空的品类，多半是需求本身就不存在，绕开就好。

广告位满、自然结果空的品类，是最理想的入场点，说明钱在流动但内容还没跟上。

保哥在给一个做宠物食品的站排语言顺序时，就是靠这一条把一门排在第七的语言提到了第二位。

还有第三个信号可以用：本地的问答站和论坛里有没有人问这类问题。广告位空、自然结果空、但论坛里讨论热烈，说明需求真实存在只是还没被商业内容覆盖，这种组合是所有情形里最值得先进的一种。

借词多的语言，是不是可以少做一半功课？

用户直接搜外来原词的那部分流量

有些品类的词在很多语言里根本没有本地对应，用户直接用原词搜。

这部分查询的写法跟英语几乎一致，理论上现成的英语页面就能接住。

但接住的前提是页面语言与用户预期一致，用户搜的是英文词，想看的是本地语言的页面。

所以借词多不等于工作量减半，只等于关键词表里少了一部分要翻译的词。

内容本身、价格、配送信息、客服语言，一样都不能少。

把借词比例当作省钱理由，通常在上线三个月后被跳出率打脸。

这两类词的意图也不一样：打外来原词的用户更多在查资料和比参数，打本地词的用户更接近下单。所以它们该落到不同类型的页面上，原词接科普与对比内容，本地词接商品列表和详情，混在同一个页面上两边都接不好。

借词的本地拼写会分裂成好几种写法

借词进入一门语言之后，往往会长出一套本地拼写，跟原词并存。

有的语言会把它按本地读音重新拼一遍，有的语言原样保留，还有一部分用户两种都打。

更麻烦的是形态语言会给借词也接上格尾，于是原词和本地拼写各自再展开若干形态。

这时候借词不但没让词表变小，反而制造了一批跨形态的重复。

处理这类词的正确做法是原词与本地拼写都做，但只给其中一种做落地页。

另一种放进页面正文和内部锚里，靠语义关联接住，不必单开页面。

分裂通常不是从单数形态开始的。单数写法两边一致，复数或者带格尾的形态却各走各的，这种情况在实际语料里非常普遍，也正是只查词典原形的选词方式最容易漏掉的一块。

借词比例高的语言反而更容易漏词

直觉上借词多的语言好做，因为看得懂；实际情况正好相反。

看得懂会让人省掉验证这一步，直接把原词抄进词表，漏掉本地拼写的那一半。

而本地拼写往往是普通用户更常用的形态，专业用户才习惯打原词。

一个站如果只覆盖原词，接到的就是专业用户那一小撮，转化率数据还会显得很好看。

看着转化率不错就不再扩词，这个坑一埋就是好几年。

所以借词多的语言要额外做一件事：把每个借词的本地拼写单独查一遍，不能靠感觉。

有个成本很低的补救办法：抓十家本地零售站的商品标题，做一次粗糙的分词统计，出现频次最高的那批词就是本地用户真实在用的写法。这份表跟你自己的词表一对照，漏了什么一眼就看出来，不需要任何语言学知识。

一门语言里有几套写法，就要按几套算预算吗？

同一门语言两套字母的情形

有些语言在法律和习惯上同时使用两套字母，两套都算正式写法。

这种情况下两套字母之间通常有严格的一一对应，机器转换可以做到完全可逆。

能可逆意味着内容可以自动生成两份，边际成本主要落在页面数量和索引量上，不在写作上。

但要注意两套写法的用户群不完全重叠，年龄和地区分布都有差异。

先做用户量大的那一套，另一套等第一套跑出数据之后再决定要不要铺。

这类语言的预算不是翻倍，大概是一点三到一点五倍。

技术上有一条要提前定死：两套写法的转换要在服务端一次性生成两份内容，不要做成浏览器里的实时切换。实时切换看着省事，代价是两套写法共用同一个地址，搜索侧永远只能看到其中一套。

同一门语言两套正字法的情形

另一种情况是两套写法不能机器互转，因为它们在词汇层就有分歧。

这时候两套写法背后其实是两套词表，甚至是两批不同的写作者。

预算要按接近两倍算，而且要提前想清楚这两份内容之间的关系怎么表述。

如果只做一套，要选的是覆盖用户多的那套，而不是更规范的那套。

规范程度对搜索的影响，通常比不上用户实际打字习惯的影响。

这一条在任何有正字法争议的语言里都成立，没有例外。

分歧的落点也有规律：本土固有词在两套正字法里通常写法一致，真正分叉的是外来词的转写规则。而商品品类名恰恰有很大比例是外来词，所以正字法分歧对做电商的影响，比对做新闻的影响大得多。

转写与原字并存的情形

第三种情况最容易被漏掉：用户用另一套字母把这门语言拼出来。

这种拼法没有任何官方地位，拼写也不统一，同一个词能出现四五种拼法。

但它在搜索日志里的占比常常不小，尤其在移动设备和公共电脑上。

处理这类形态不需要单独做页面，只要在页面正文和内部链接里覆盖几种主流拼法即可。

如果这门语言的转写形态占比超过两成，那它就该在预算里单列一行。

把这一行漏掉，等于默认放弃了两成的搜索面。

判断这类形态占比时，站内搜索日志比外部数据更能说明问题。外部搜索会做拼写纠正和同义扩展，把转写形态悄悄纠回原字；站内搜索一般没有这层处理，用户打了什么就记什么，比例是原始的。

语言之间的距离，能不能折算成内容复用率？

近亲语言之间能共用的是哪一层

两门语言互相听得懂，不代表两个市场的内容可以共用一份。

可以整块共用的通常只有三类东西：图片、尺寸与规格数值、以及不含文字的结构。

需要逐词替换的是品类名、属性词和促销用语，这部分是分叉最密集的地方。

必须完全重写的是标题、页面描述和正文，因为这三处直接决定能不能被搜到。

把资产按这三档分类，复用率就能变成一个可以填进表格的百分比。

百分比出来之后，排期和预算的争论会立刻变成算术题。

数值型属性看起来最安全，其实也有一个坑：数值本身可以共用，写法不行。小数点用逗号还是点、千位分隔怎么写、单位符号放在数字前还是后，这几处在近亲语言之间经常不一致，而它们直接出现在商品标题里。

距离近不等于能省钱

两门语言越近，反而越容易出一类隐蔽问题：内容看起来对，读起来别扭。

用户不会写反馈邮件说哪里别扭，他们只是不再往下读。

这种损耗在数据上表现为停留时间短、加购率低，很难归因到语言上。

所以近亲语言的复用要么做到位，要么干脆分开做，卡在中间是最贵的。

做到位的标准很简单：找一个母语用户读一遍，问他这像不像本地人写的。

这一步的成本比返工低得多，但经常被排期挤掉。

近亲语言之间最贵的一类词是形态相同意思不同的那批。人眼扫过去不会停顿，机器比对也发现不了，只有母语用户读到具体句子时才会觉得别扭。把这类词整理成一张对照表，是近亲语言项目里回报最高的一次性投入。

用复用率给近亲语言打包排序

把复用率高的几门语言打成一包，整包评估投入产出，比单门语言评估更接近实际。

一包里做第一门语言的成本最高，第二门和第三门的边际成本会明显下降。

所以整包的收益要用总和算，不能用第一门语言单独的收益来判断值不值得开工。

这也解释了一个常见现象：某门语言单看不值得做，放进它所在的语族里就值得。

打包评估的前提是先把三档资产分清楚，否则边际成本下降只是想象。

估完之后按包排序，包内再按市场规模排，顺序就出来了。

包内的顺序还有一条经验：先做语族里形态最复杂的那门语言。从复杂往简单推，形态归并规则可以直接裁剪复用；反过来从简单往复杂推，前面做的规则基本用不上，等于重做一遍。

整包评估还要留一条退出线：如果第一门语言跑完之后实际复用率明显低于预估，就该重新评估整包而不是硬着头皮往下做，复用率是这类打包决策唯一真正的支撑点。

三笔账怎么合成一个能拿去开会的分数？

三个变量各自的取值区间

第一笔账是可触达面，用上网人数乘语言占比得到，单位是人。

为了方便比较，把它换算成相对值，最大的那门语言记作十分，其余按比例折算。

第二笔账是词表膨胀系数，取值一到十二，直接对应人力成本。

第三笔账是内容供给密度，按首页十条里的本地站数量取值，零到十。

三个数量纲不同，所以要先各自归一化再进入下一步。

归一化的方式不重要，重要的是全程用同一套，中途换算法就没法比了。

归一化的方式虽然可以自选，但有一个选择明显更好：用对数而不是线性。语言人口跨着好几个数量级，线性归一会让除了最大那几门之外的语言全挤在接近零的位置，整张表就失去了区分度。

另一个实操细节是保留原始值。归一化之后的分数便于比较却不便于解释，会上有人质疑某一格时，能立刻翻出原始的人数和采集来源，讨论就不会卡住。表里多两列的成本，远低于当场答不上来的成本。

加权还是相乘

三个变量之间不是彼此独立的贡献，而是有明显的相互制约关系。

可触达面再大，如果词表膨胀系数高到做不出来，实际收益就是零。

内容供给密度再低，如果没人搜，空着也没有意义。

所以这三项更适合相乘而不是加权求和，任何一项接近零，总分就该接近零。

具体算法是可触达面分数除以膨胀系数，再乘以供给稀薄度，得到一个综合分。

这个式子不精确，但它至少不会让某一项的短板被另外两项的高分掩盖过去。

相乘式要配一个下限保护。任何一项低于事先约定的阈值，就直接标记为本轮不做，而不是让它乘出一个很小但非零的分数继续排在表里。小分数会给人一种再努努力就能做的错觉，实际上短板是结构性的。

算完之后建议手工验算两三个极端例子：一门人口极大但形态极复杂的语言、一门人口很小但完全没人写的语言，看它们的分数排在哪里。如果排位明显反直觉，多半是某一项的归一化范围没设好。

分数出来之后怎么分档

把所有候选语言的综合分排一列，通常会自然分成三段。

头部几门明显高出一截，这几门是要投入完整资源做的。

中间一段分数接近，彼此差异在误差范围内，这时候按团队现有语言能力选。

尾部一段分数很低，明确写进不做的清单，附上原因和复审时间。

写清楚为什么不做，比写清楚为什么做更能减少后面的反复讨论。

半年之后拿出来复审一遍，供给密度这一项变化最快，可能会把某门语言推上来。

复审时只重算变化最快的那一项，另外两项半年内基本稳定，不必每次全算。

分档的边界不要用固定百分位，用分数序列里的自然断层。把分数从高到低排一列，逐个算相邻两项的差值，差值最大的那两个位置就是天然的分界线。这样分出来的档，讨论时基本不会有人觉得某门语言被硬塞进了错误的那一档。

分数表要带哪几列才不会被推翻

只给一个总分的表最容易被质疑，因为没人知道分是怎么来的。

把三个原始量、三个归一化值和最终分并排放在一张表里，讨论就有了共同起点。

再加一列写清楚每个数字的来源和采集日期，半年后复审时不用重新考古。

最后加一列写这门语言目前团队里有没有人能读，这一列常常直接决定实际排期。

有了这五类列，这张表就能一直用下去，而不是做完一次就扔。

会上真正争论的其实很少是分数本身，多半是某个数字的来源可不可信。

还可以加一列敏感度标注，写清楚这一格的数字如果错了会有多大影响。三个变量里，词表膨胀系数错一档的后果最严重，因为它直接对应人天；可触达面错三成基本不影响排序结论，标注清楚可以让复审时的精力花在对的地方。

分数排完，第一门语言该怎么挑？

先挑一门用来校准模型的语言

第一门语言的作用不只是拿流量，更重要的是验证这套估算靠不靠谱。

所以第一门最好选一门形态不太复杂、团队里有人能读、市场规模中等的语言。

形态简单能让上线速度快，有人能读能让问题及时被发现，规模中等能让数据有统计意义。

分数最高的那门语言常常不满足这三条，急着上反而拖慢整个计划。

先用一门好做的语言把流程跑通，再上难的，总时间反而更短。

这个顺序看着不直觉，但做过两轮的人基本都会这么排。

如果本站已经有一门语言在自然获得少量流量，那它就是最好的校准对象。有基线才分得清提升来自内容本身还是来自这个市场本来就在增长，从零开始的语言两个月后拿到的数字，很难判断算好还是算差。

第一门语言的验收指标该定什么

不要用收入当第一门语言的验收指标，周期太长，也受太多非语言因素影响。

更合适的指标是关键词覆盖率：词表里有多少词能在结果里找到自己的页面。

第二个指标是形态覆盖率：同一个概念的各种写法有没有都能落到同一个页面上。

第三个指标是本地用户的可读性反馈，找三到五个真人读一遍就够。

这三个指标都能在两个月内拿到结果，足够决定要不要往下推。

收入指标放在第二门语言开始之后再看，那时候才有可比的基线。

形态覆盖率的具体测法值得写死：抽二十个核心商品概念，每个概念把实际可能出现的形态全部列出来，逐个搜一遍，看是不是都能落到同一个页面上。落到不同页面或者落不到，都算未覆盖，这个口径不会有歧义。

这三个指标还有个共同的好处：它们都不受市场大小影响。换一门语言继续用同一套指标，数字可以直接横向比较，几轮下来就积累出了各语言的执行质量对照，比单纯看流量更能反映团队的实际能力。

除了这三个指标，还要记一个过程量：从词表定稿到第一批页面上线花了多少天。这个数字是后面所有语言排期的基准，没有它，第二门语言的时间估算又只能靠拍脑袋。

校准完之后往下推的顺序

第一门语言跑完，回头把估算模型里的三个量重新校一遍。

实际的词表膨胀系数几乎总是比估计值大，通常大三成到五成。

把这个偏差系数记下来，后面每门语言的估算都乘上它，排期就准多了。

可触达面这一项通常估得偏保守，因为没算上邻国用同一门语言的用户。

供给密度这一项最准，因为它是手工数出来的，没有中间环节。

校准之后的第二轮排序，跟第一轮相比通常会有一到两门语言换位置。

偏差系数最好按内容类型分别记。商品页的实际膨胀系数通常比预估高得多，因为属性词的组合会成倍展开；而资讯类内容页的形态压力小得多，用同一个系数去估两类内容，一定会有一类排期严重失真。

这套账在什么情况下会算错？

数据源本身不可靠的情形

上网人数和语言占比这两个数，在部分市场只有口径不一致的几份统计。

遇到几份数据差异超过三成的市场，不要取平均，取最保守的那一份。

取保守值的好处是排序结果偏稳，不会因为一个乐观数字把某门语言硬推上去。

如果连保守值都拿不到，就用邻国同类市场的数字做代理，并在表里标明这是代理值。

标明代理值不是形式主义，半年后复审时它决定了要优先重新采集哪一格。

整张表里代理值超过三分之一时，这轮排序只能当参考，不能当决策依据。

口径本身也要看清楚。官方公布的语言普及率统计的多半是能用这门语言，而搜索关心的是会主动用它打字。这两个数在很多市场差得很远，看到一个高得反常的比例时，先去确认它统计的是哪一个。

品类与语言的耦合被忽略

前面说过优先级是语言与品类交叉的量，但实际做表时很容易只按语言排。

同一套语言排序拿去给两个差异很大的品类用，一定有一个会做错。

正确的做法是每个主力品类各做一张表，三个变量里只有可触达面需要重算。

词表膨胀系数和内容供给密度可以在品类之间共用，改动量不大。

做两张表的额外成本大概是半天，比做错一门语言的成本低两个数量级。

如果品类跨度实在太大，那本来也不该用同一个站去覆盖。

差异有多大常被低估：同一门语言在礼品类和工业耗材类上的可触达面，差距可能比两门完全不同的语言之间还大。所以真正需要多做几张表的不是语言维度，而是品类维度，这一点跟直觉正好相反。

团队里没有母语人的情形

三个变量里，内容供给密度这一项需要能读懂结果页才能数。

没有母语人时可以靠机器翻译大致判断，但误差会明显变大。

补救办法是把采样量从十个词加到三十个词，用样本量换准确度。

另一个办法是只数结果的域名归属，本地后缀域名的比例是个粗糙但可用的代理指标。

这两个办法都能让这一项勉强可用，但都不能替代真正读懂内容。

所以团队里第一个该招的不是更多写手，是一个能读目标语言的人。

用机器翻译辅助判断时，要把任务限定在它能做好的那一类上。判断一条结果是不是本地站，看域名后缀、地址和货币符号就够，机器翻译只要能读出这几项就行；判断内容质量高不高则完全不可靠，不要让它做这个决定。

把语言当成国家来算

最后一类错误是把语言和国家画等号，一门语言配一个国家。

实际上一门语言可能跨五个国家，一个国家也可能有三门通用语言。

按国家排会把跨国语言的可触达面严重低估，按语言排会把多语国家的复杂度低估。

正确的做法是两张表都做：语言表决定内容做几套，国家表决定站点结构和履约。

这两张表本来就该分开，混在一起是很多多语言项目一开始就走偏的原因。

说白了，语言决定你写什么，国家决定你怎么收钱和发货，两件事没必要挤在一个格子里。

跨国语言还要按国家分别数一遍供给密度。同一门语言在两个国家的竞争强度可以差出三倍，因为本地零售生态完全不同。只数一个国家就把这门语言的竞争度定下来，另一个国家的机会要么被高估要么被彻底忽略。

两张表之间还要留一条对照线：语言表里的每一门语言，要标明它对应哪几个国家；国家表里的每个国家，要标明它需要哪几门语言。两边对不上的格子，通常就是项目后期最容易出问题的地方。

优先级排完之后，哪些事本来就不归语言层管

域名与目录结构不在这笔账里

选独立域名、子域名还是子目录，是站点架构问题，跟语言本身的难度无关。

这个决定影响的是维护成本和权重集中程度，不影响关键词表要写多少词。

把架构决定和语言优先级混在一起讨论，会让两个问题都得不到结论。

正确的顺序是先定做哪几门语言，再定这几门语言的内容放在什么结构下。

顺序反过来的项目，通常会因为架构方案迟迟定不下来而拖住内容排期。

架构那半边的判断标准另有一套，本篇不重复。

语言表最终要交给架构那一侧的其实只有一个数字：内容总份数。这个数不等于语言数，两套字母的语言算两份，需要按地区再分的语言按地区数算。接口只有一个数字，两边的责任边界就非常清楚。

把这个数字定下来还有个附带好处：它同时是内容团队的排期基数和技术团队的工作量基数，两边不用再各自估一遍。以往很多多语言项目的排期分歧，根子上就是两边心里的份数不是同一个数。

用哪个搜索引擎也不在这笔账里

有些市场的主流搜索引擎不是同一个，这确实会影响操作细节。

但它影响的是提交方式、收录节奏和排序偏好，不影响这门语言有几种词形。

语言层的功课做完之后，引擎层的差异是可以另外补的，反过来则不行。

先按引擎排语言优先级，会得到一个跟内容工作量完全脱节的顺序。

这两层的关系可以这么理解：语言决定你要准备多少弹药，引擎决定你往哪个方向打。

准备弹药的账，跟选方向的账，本来就该分开算。

引擎差异确实会反过来影响一点语言层的工作量：有的引擎自己会做词形归并，有的基本不做。前者可以少铺一些形态变体，后者必须把主要形态都铺出来。但这只是调整铺词的细度，不改变这门语言本身有多少种形态。

支付、物流和法务不在这笔账里

能不能收到钱、能不能发到货，是这门语言值不值得做的前置条件，不是评分项。

把它们当条件，先筛掉不可行的市场，再对剩下的语言算三笔账。

混进评分里会出现一种怪现象：某门语言分数很高但根本发不了货，表却看不出来。

所以这几项应该出现在表的最左边，作为通过或不通过的开关列。

开关列为否的语言直接不进入评分，省得后面反复解释为什么排在前面却不做。

把条件和评分分开，是这张表能长期用下去的关键。

开关列还要写上复审日期。物流覆盖和法务限制都是会变的，今年发不了货的市场明年可能就通了，写了日期才会有人回头去看，否则这几格会一直保持着第一次填写时的状态，把一个已经可做的市场长期挡在门外。

常见问题解答

手上完全没有目标市场数据时，这套账还能算吗？

能算，但要接受结果只能用来排序不能用来定预算。三个变量里，词表膨胀系数完全不依赖市场数据，翻词干算法和字母表就能估出来；内容供给密度只要能搜到结果页就能手工数，不需要任何工具授权；只有可触达面这一项需要外部统计。所以在完全没数据的情况下，可以先用另外两项排一个初步顺序，把明显做不动和明显没人写的两头先分出来，中间那一段等拿到流量数据再细排。实际操作里，光靠后两项就能把候选语言从二十门砍到六七门，剩下的差异本来也需要真实数据才判断得了。还有一个补充办法是拿邻近市场做代理：语言不同但经济结构和零售形态接近的市场，其供给密度和品类结构往往有参考价值，先借来排个大概，等自己的数据攒够再替换掉。

词表膨胀系数具体怎么手工估出一个数？

先确定形态倍数：查这门语言有没有公开的词干剥离规则，规则在二十条以内取二，二十到五十条取六，超过五十条或者以后缀叠加著称的取十。再确定书写系统数，实际在用的字母套数是几就取几，用户自发的转写形态额外加零点五。最后确定地区变体系数，覆盖一个零售市场取一，两个取一点六，三个以上取二。三者相乘就是膨胀系数。这个算法粗糙到会让语言学出身的人皱眉，但它的输出跟实际投入的人天数相关性相当高，而且任何人算出来的结果都差不多，这一点比精确更重要。算完之后建议把这个系数和实际投入的人天记在同一张表里，做过三门语言就能反算出属于自己团队的换算比例，之后的排期估算会比任何通用经验值都准。

综合分相同的两门语言，该先做哪一门？

先做团队里有人能读的那门。这不是妥协，是因为分数相同意味着模型已经区分不出优劣，这时候决定实际产出的是执行质量，而执行质量高度依赖有没有人能当场判断内容对不对。如果两门语言团队都没人能读，那就先做能找到本地审校的那门，找人的难度本身就是一个有效的排序依据。还有一个次要判据是这门语言的资料是否公开可查，词典、语料库、正字法规则能在网上找到的语言，做起来的摩擦会小很多，遇到疑问不用每次都等外部回复。还有一条容易被忽略的判据：这两门语言里有没有一门属于某个语族的核心，先做核心那门，后面同语族的几门都能吃到它的形态规则和词表结构，等于顺手买了一份期权。

内容供给密度靠手工数十个词，样本会不会太小？

对于排序目的来说够用，对于定预算不够。十个词的采样能可靠区分出饱和、中等和稀薄三档，这正是排序需要的粒度。如果要用这个数字去说服人批预算，那就把样本加到三十个词，并且按品类分层抽样，每个主力品类至少三个词。另外要注意采样时间：同一批词隔三个月再数一遍，如果本地站数量明显上升，说明这个市场正在被别人发现，入场窗口在收窄。这个变化速度本身比绝对值更有决策价值，很多团队只数一次就再也不数了，等于放弃了这个信号。采样时还要记下每条结果是商品页还是内容页，这个比例决定了你该先铺哪一类页面，两个市场供给密度相同但结构不同时，切入点完全不一样。

这套优先级模型多久该重算一次？

整体半年一次，其中内容供给密度这一项建议三个月一次。可触达面和词表膨胀系数都是慢变量，上网人口占比一年内变化有限，语言的形态更是几十年不变，重复计算的收益很低。内容供给密度是快变量，竞争对手进场、本地媒体开始做导购、平台方推本地化内容，都会在几个月内把某个品类从稀薄推向饱和。重算时只更新这一列，另外两列沿用上次的值并标注采集日期。整个复审工作量控制在一天以内，才有可能真的坚持下去，做成一天以上的流程通常第二次就没人做了。复审时把上一轮的预测和这一轮的实际结果并排放一次，模型的偏差方向会很快显现出来，通常两三轮之后估算精度就能稳定在一个可用的范围内。

如果老板坚持要先做人口最多的那门语言，怎么办？

把三笔账做成一张表给他看，重点不是结论而是中间的数字。多数情况下争议来自双方看的是不同的量：老板看的是市场潜力，执行团队看的是完成所需的人天。把词表膨胀系数这一列摆出来之后，讨论会从要不要做变成需要多少时间和人，这是个能谈的问题。如果最后还是决定先做那门语言，那就把它当成第一门语言来做，但要同步调低第一年的目标，并明确说明原因是形态复杂导致词表工作量翻了几倍。写清楚了，半年后复盘时不会变成执行不力的问题。真到了这一步，可以退一步提个折中方案：那门语言照做，但同时用很小的成本铺一门形态简单的语言当对照组，两个月后拿两组数据说话，比继续争论有效得多。

语言优先级和站点架构应该谁先定？

语言优先级先定，架构后定，中间不要交叉讨论。原因是架构方案的选择依赖于最终要做几门语言、每门语言有几套写法、内容是否需要按地区再分，这些都是语言层的输出。反过来先定架构，会导致语言方案被架构限制，比如已经定了每门语言一个子目录，后面才发现某门语言需要两套字母各一份内容，结构就得推倒重来。正确的节奏是语言表出来之后，把最终需要的内容份数交给架构那一侧，由他们去选结构方案，两边的接口就是这个份数，非常清晰。如果时间上实在没法完全串行，可以把架构方案先收敛到两三个候选，等语言表里的内容份数一确定，立刻就能从候选里选定，这样既不阻塞也不会推倒重来。

权威参考资料