用青虎Agent做Shopee选品：站点类目与价格带

用 Shopee 做选品，最容易犯的错误是把整个平台当成一个市场来看。它实际上是若干个相对独立的市场拼在一起的集合，不同站点之间的消费水平、类目偏好、主流价格带、履约条件都不一样。同一个品类在这个站点卖得动，换到另一个站点可能连基本的搜索量都不够。

这个特性直接决定了分析方法：在 Shopee 上做选品分析，第一步不是选品类，而是选站点；确定了站点之后，才谈类目结构和价格带。顺序颠倒的话，后面所有的结论都会建立在错误的前提上。

这篇文章把 Shopee 选品的判断逻辑拆成三层：站点怎么选，类目结构怎么看，价格带怎么定。操作部分用青虎Agent 做示例，技能市场覆盖 Shopee，可以按站点分别取数再横向对照，这个能力恰好匹配这个平台的判断需求。

数据边界照例先说清楚。青虎Agent 取回的都是平台公开数据，包括站点的类目结构、商品的公开挂牌价格、销量档位、评价数量级与评价正文。店铺后台的真实成交、广告花费、转化率属于卖家私域数据，任何第三方工具都拿不到。这条边界在站点差异判断上尤其重要，因为很多看起来像销量数据的指标，实际反映的是别的东西。

一、为什么先选站点，再选品类

站点的差异体现在三个层面。第一个层面是消费能力，也就是买家愿意为一个同类商品付出的价格量级。第二个层面是类目偏好，也就是哪些品类在本地本来就卖得好，哪些是后来才被带起来的。第三个层面是基础设施，也就是物流时效、支付方式、退换处理这些影响体验的条件。

三层差异叠加起来，会让同一个品类的可做性在不同站点上出现很大落差。一个高客单的品类在成熟市场站点可能有稳定的需求，在新兴市场站点上则可能因为价格超出主流接受范围而完全走不动；反过来，一些客单价低、使用频次高的品类，可能在新兴市场站点上表现更好。

所以站点选择不是执行层面的细节，而是判断链条的起点。先用公开数据把站点之间的差异看清楚，再决定做什么，比先想好品类再去找站点要可靠得多。前者是从市场出发，后者是从自己的偏好出发，后者的失败率明显更高。

还有一个现实原因让站点先行更有必要：跨站点的运营成本很高。不同站点的语言、客服、退换处理、结算方式都不一样，同时推进多个站点的团队通常需要更多人力和更复杂的流程。把站点选对，等于把有限的资源集中到成功率更高的地方。

站点先行还有一层好处与资料沉淀有关。按站点组织调研记录，同一个站点的判断会不断累积：这次的类目结构结论、下次的价格带变化、再下次的评价活跃度趋势，都能接在前面的记录上。反过来，如果不按站点拆开，每次调研都要从头建立对市场的认知，前面的工作很难复用。

需要说明的是，站点先行不等于只看一个站点。判断一个品类是否普适，需要在多个站点之间做对照；但如果团队的实际资源只够做好一个站点，那么先把一个站点看透，比同时铺开几个站点更现实。判断顺序和投入顺序是两件事，不要混在一起。

还有一个常被跳过的动作：在确定站点之前，先确认自己的物流和售后能力能不能覆盖这个市场。公开数据能告诉你需求在哪里，但覆盖能力是你自己的条件。把这两件事分开判断，避免出现市场看好、履约跟不上的情况。

二、站点差异怎么看：三组对照维度

站点差异不需要凭印象判断，公开数据里能读出明确的对照关系。下面三组维度是最常用的观察角度。

对照维度	怎么观察	对选品的影响
消费能力	同品类商品在站点的挂牌价格分布与主流区间	决定价格带定位与产品规格选择
类目偏好	该站点类目结构里各类目的商品数量与评价活跃度	决定哪些品类有本地需求基础
供给密度	同类目下的商品数量级与卖家分布情况	决定竞争强度与切入方式
评价活跃度	商品评价数量级与内容更新节奏	判断这个类目在当地是否真的在成交
履约条件	商品的配送方式与时效说明	判断模式可行性与体验预期

这张表里，最容易被忽略的是第四行。一个站点里某个类目商品数量不少，但商品的评价数量普遍处在低档位、评价内容更新也很慢，通常说明这个类目在当地还处在货架铺开的阶段，真实成交并没有跟上。这种情况下靠商品数量判断机会，很容易高估。

与之相对，商品数量不多但评价活跃、评价内容持续更新的类目，说明有真实的购买行为在发生。这类类目数量看起来小，但需求是实的。判断一个站点要不要做某个类目时，评价活跃度比商品数量更有参考价值。

评价活跃度还有一个延伸用法：把它和商品数量放在一起看，能大致判断出这个类目在当地处在什么阶段。商品少而评价活跃，说明类目还处在早期、但需求已经出现；商品多而评价活跃，说明类目已经成熟、竞争充分；商品多而评价冷清，说明货架被铺开但成交没跟上。三种阶段对应完全不同的切入策略。

把阶段判断写进结论时，建议连判断依据一起写，比如因为该类目商品数量处在中低档位、评价活跃度相对较高，判断其处在早期但有真实需求。依据写清楚之后，过几个月回看时可以判断当时的判断是否成立，这比只留下一个阶段标签有用得多。

判断阶段的时候，建议把时间维度也带上。同一个类目半年前的形态和现在可能完全不同，如果只在某一次取数里看到静态结果，很容易把阶段判断错。把几次观察的时间点标出来，阶段判断才有依据。

第五行的履约条件也需要提前看。不同站点在配送网络和时效上差异明显，有些站点的买家对配送时效格外敏感，商品详情里的时效说明会直接影响购买决策。这一点在选品阶段就要考虑，等到上架之后再调整，成本会高出很多。

图2：站点差异要拆成消费能力、类目偏好、履约条件三个层面分别观察

三、类目结构：层级和本地供给一起看

类目结构的观察方式和搜索型渠道的思路相通，但在 Shopee 上要多加一层本地化视角。平台的类目体系是统一的，但每个站点里类目的饱满程度差别很大。

判断类目结构时，建议先看类目层级下的商品覆盖情况。同一个二级类目，在成熟站点可能已经被填满到三级子类目都有大量商品，在新兴站点可能只在一级层面有商品。这个差异说明本地供给还处在什么阶段，也决定了你的切入位置。

再看类目内部的商品形态分布。同一个类目在不同站点里，主流商品形态可能完全不同。原因往往是本地使用习惯和居住条件的差异，比如同一类家居用品，在不同站点里主流规格、套装数量、材质偏好都可能不一样。看形态分布，比看类目名称更能说明当地买家在买什么。

还有一个观察点常常被忽略：类目里是否存在明显的价格断层。健康成熟的类目，商品价格通常从低到高连续分布；如果某个类目里大量商品集中在很低的价格带，中间档次几乎没有商品，这个断层往往说明当地的消费能力或者供应链条件还不支持更高价位的产品。

把这几层看完，你对一个站点的类目结构就有了明确判断：饱和的位置在哪里、空白的形态是什么、价格断层出现在哪一档。这些判断都是基于公开的商品分布数据得出的，不需要依赖任何后台数据。

类目结构里还有一层与合规相关的内容值得关注。不同市场对商品资质、标签、认证的要求不一样，这些要求有时会直接体现在商品详情的公开信息里，比如是否标注了当地的认证信息。做跨境选品时，把这一点纳入判断可以避免做出无法上架的选择。

把这些观察落成一份记录时，建议按类目层级组织，而不是按商品组织。类目层级的结论可以复用在下一次同类目调研里，单个商品的结论则很快就会过期。记录的颗粒度决定了它能用多久。

还有一个容易被忽视的类目结构信号：类目里是否出现了同一商品的多种变体聚集。同一个商品以多个规格、多个颜色、多个套装形式集中出现，通常说明这个类目已经进入了运营细化的阶段，卖家在用变体覆盖更宽的需求。这样的类目里，单纯靠上新很难拿到位置，需要有明确的产品差异点。

四、价格带判断：为什么必须按站点分开做

价格带是 Shopee 选品里最容易出错的一环，出错的原因通常是把不同站点的数据混在一起算平均数。把几个消费能力差异明显的站点合在一起，得到的价格分布看起来平稳，实际上掩盖了所有有用的信息。

价格带位置	通常对应的市场状态	切入时需要注意
低位带	价格竞争激烈，买家对价格高度敏感	靠成本和规模，产品差异化的空间有限
中位带	供给相对集中，买家开始关注品质与体验	是否有明确的功能或规格差异点
高位带	对应站点的消费能力上限，供给相对少	需要匹配站点的实际接受度，避免脱离主流区间
断层带	该档位缺少商品，可能由消费能力或供应链造成	先确认是需求空白还是需求不存在

这张表的使用方式是先定位，再判断。定位指的是先确认你要看的商品主要落在哪个价位区间，判断指的是这个位置对应什么样的竞争形态和切入方式。跳过定位直接判断价格高低，得到的结论没有可操作性。

具体做法是按站点分别取价格分布，再对比同一品类在不同站点的主流区间落在哪里。对比之后通常会发现两种结果：一种是某个品类在所有站点的主流区间都接近，说明这个品类的价格弹性较小；另一种是区间差异明显，说明价格带高度依赖当地的消费能力。前者适合做标准化产品，后者必须在产品规格和定价上做本地化处理。

还有一个细节要注意：挂牌价格和实际成交价格通常有差距。公开数据里能看到的是挂牌价格区间和活动价格的公开信息，具体成交价、优惠力度这些属于卖家自己的经营数据，任何第三方工具都拿不到。用挂牌价格做判断时，把它当作相对位置的参考，而不是绝对定价依据。

价格判断还要结合产品规格一起看，否则容易得出错误结论。同一个品类里，不同规格商品的挂牌价格差距可能很大，如果不区分规格直接比价格，看到的差异其实是规格差异，不是价格带差异。取数时把规格条件写进任务描述，得到的价格分布才是在同一个口径下的比较。

把价格带结论写成固定格式也很有帮助。建议写成某站点该品类主流挂牌价格落在某一区间、中位带商品数量占比相对集中、高位带供给相对稀疏这样的句式。句式固定之后，跨站点、跨时间的对照可以直接做，不需要重新理解每一句话的含义。

五、用青虎Agent 跑一遍站点选品

把上面的判断逻辑串成动作，就是一次完整的站点选品分析。青虎Agent 把选品分析、市场分析、Listing生成、商品库、技能市场放在同一个界面，在青虎AI 平台左侧导航栏点开「Agent」即可进入。下面五步可以照着做。

图1：从确定候选站点到痛点归档，五步把站点差异转化成可以对照的候选清单

五步里最需要坚持的是第二步和第三步不要合并。很多人为了省事，一次性让 Agent 把几个站点的数据一起取回来，结果得到一份平均值，站点之间的差异全部消失。分开取、分开存、最后再横向对照，是这个平台判断的关键操作。

追问环节可以按固定顺序推进：先把缺失的站点补齐，再调整价格区间和时间范围，最后把结论整理成给采购或给运营看的版本。如果一开始就在格式上反复调整，实质内容反而没补上。

还有一点关于任务描述的实操建议：把要求按站点分开取数这句话明确写进去。Agent 默认会按你的描述组织任务，但如果你只说了看几个站点的情况，结果可能是合并后的概览。要求写明之后，回来的就是每个站点一份独立结果。

取数完成后，建议先做一次站点间的一致性检查。同一个品类在两个站点的字段结构应当一致，如果某个站点的结果明显缺字段，多半是取数范围或关键词写法的问题，补一次再往下走，比在不完整的结果上做判断更省时间。

六、从候选清单到站点策略

清单出来之后，下一步是把它转成可以执行的动作。这一步的关键是逐站点确认三件事：这个站点做不做、用什么价格带做、用什么商品形态做。

做不做，取决于需求是否真实。判断依据是类目的评价活跃度，而不是商品数量。评价数量处在低档位、内容更新缓慢的类目，即便商品很多，也说明本地的购买行为还不活跃，这时候进入容易变成陪跑。

用什么价格带做，取决于主流区间的位置和断层的性质。如果主流区间集中在低位带，需要判断自己有没有成本优势；如果断层出现在中位带，需要先确认这个空位是需求空白还是需求不存在，方法是对比相邻站点的同类目结构。

用什么形态做，取决于类目内部的商品形态分布和评论里的高频问题。形态分布告诉你当地买家在买什么，评论告诉你他们在抱怨什么。两个信息合起来，就是商品定义的基础。这一部分结论还可以继续用于 Listing 文案的卖点描述。

三件事确认之后，建议写一份跨站点对照表：每一行是一个站点，列是这个站点对应的价格带、主流形态、竞争水平、评分与评价活跃度、以及准备做什么。这份表比一堆分散的结论更有决策价值，也方便团队讨论时对齐认知。

对照表里还有一列值得加上：这个站点需要额外确认的问题。比如某个站点的价格断层需要验证、某个类目的评价活跃度还需要再看一个周期。把待确认事项写进表里，下一次取数就有了明确目标，不会又从头做一遍。

表格之外，建议给每个站点留一句结论性的描述，比如这个站点适合做中位带的标准品、那个站点更适合做高使用频次的低价商品。一句话的结论看起来粗略，但它在团队沟通中的效率远高于一份详细数据，也更容易被记住。

最后补一个关于节奏的建议。站点层面的数据，建议固定每月跑一次同类目的观察，把结论按时间顺序排在一张表里。单次结论的价值有限，连续几个月的结论排在一起，就能看出这个站点的类目结构是在变密还是变松、价格带是在上移还是下沉。这种趋势判断是单次取数给不了的。

七、四个常见误区

四个误区的共同点是把平台当成了一个均质市场。Shopee 的特性恰恰是站点之间高度分化，分析方法必须跟着这个特性走。把站点当作分析的基本单位，判断的稳定性会明显提升。

还有一个与流程相关的误区：只在进入新站点时才做站点分析，之后就不再更新。站点的消费能力和类目结构会随着市场变化而移动，半年不看，原来的结论可能已经失效。把站点分析做成周期动作，而不是一次性动作，判断才有持续的有效性。

八、四个提高判断质量的技巧

四个技巧都围绕同一个原则：让站点成为分析的基本单位。记录按站点拆、观察按站点排、价格按站点比、断层按站点标。这个原则坚持下来，选品判断就不再依赖对某个市场的模糊印象。

技巧的落地顺序建议是这样：先把第一条和第二条固定下来，也就是按站点建记录、先看评价活跃度再看商品数量，这两条决定结果的可比性和方向正确性；第三条价格带按区间描述属于书写习惯，改起来很快；第四条断层标注适合在跑熟之后加上，它需要一定的样本积累才有意义。

如果团队里有多个人在做同一个平台的调研，建议把这四条技巧写进共同的记录模板里。模板统一之后，不同人产出的站点结论可以直接拼接使用，不需要先花时间对齐口径。这也是把个人经验变成团队资产的最简单做法。

九、三个可以照做的使用场景

图3：说明站点、品类与产出形式，是 Shopee 选品任务的常见下发方式

十、总结：Shopee 选品的站点优先原则

十一、常见问题解答

图4：站点判断、价格带结论与候选清单分别流向不同的后续环节

Shopee 选品分析的难点不在数据获取，而在把站点差异当成前提而不是补充说明。把站点当作分析的基本单位，把价格带按站点分开算，把类目结构加上本地化视角，三件事做到之后，剩下的判断就变成了常规的横向比较。