全网最全2020年跨境电商营销日历，赶紧收藏！！！
2019年的旺季快结束了，普遍的反响却不尽如人意，特别是一些做FBA精品的卖家，很多人的反映都是收获了一大批的库存而已，而且由于精品模式导致主力赚钱的就那么几个SKU，所以整体的抗风险能力特别的弱，可能一个链接遭到恶意投诉，整个公司的旺季就毁了。所以说，之前一直坚持精品路线的亚马逊老卖家，如今也是抱怨连连，下面是两位自诩为老韭菜的亚马逊精品卖家的一些肺腑之言，我觉得特别有代表性：
当然了，凡事不能绝对，我在调查上面也难免有疏漏。我也不否认今年还是有很多坚持精品模式的公司继续逆势上扬取得非常不错的战绩，那对于在精品模式上尝到甜头的企业来说呢？他们的日子就会越来越好吗？我想并非如此。
道理是相似的，在垂直行业的卖家也会看到和整个平台一样的缩影，每一个细分品类的增长都会越来越疲软，没有那么多增量需求可供挖掘。更加讽刺的是，你在某个细分品类的垄断地位越高，摆在你面前的增长问题就越严峻，相信增长乏力已经是今年很多亚马逊精品大卖的普遍现象了。
当然了，如果你能忍受一直吃老本，每年赚点小钱，吃不胖饿不死，甚至一年比一年赚的少，那倒也无妨。但若你的企业还想要有增长，摆在你面前的选择就只有一个——有限多元，开启第二、第三曲线，甚至在第一曲线还在增长之时就开启新的品类计划。Anker是亚马逊平台精品模式的标杆企业，但它的增长也需要新业务的推动。
如果说精品模式目前已经劣势尽显，不再是以前所信奉的神准则。那么2020年转去做铺货会不会是一个好的选择呢？答案依旧是否定的，今年已经有很多铺货大卖开始重兵布局精品了，原因很简单，就是之前堆人效的传统铺货模式也玩不转了，动销率年年走低，增长乏力愈发的凸显，除了现金流比较好以外其他的优势已经逐渐流失不在。
同时，由于大量的卖家涌入平台，竞争日趋激烈，买家们变得异常挑剔，大批量粗放式提供的产品出单的成功率越来越低，靠大量堆人疯狂铺产品“散弹枪式”的时代结束了。
更要命的是，依托红利建立的运营模式在红利耗尽之时，给所有铺货卖家们留下的只有巨大的库存和极低的人效，而这些会让所有企业被压得喘不过气来。于是，企业失速了，增长停止了，噩梦开始了。
成就你的是时代，抛弃你的也最可能是时代。错把时代的推力当做自己的能力，这是所有人都应该吸取的教训。
于是，卖家们也逐渐惊醒，开始反思自己的模式，并且意识到盲目追求规模和速度的代价，开始逐渐有了这样的共识：要学会有所选择，拒绝盲目——有所铺，有所不铺，精铺模式是精品模式和铺货模式的绝妙平衡，也是2020年我们亚马逊卖家的新方向！
◆◆
做好精铺模式的必要条件
◆◆
既然精铺模式是精品模式和铺货模式的绝妙平衡，那么卖家该如何掌握这个平衡，有没有什么心法是精铺模式的精髓所在，或者什么是做好精铺模式的必要条件？我认为有以下几点：
首先虽然是精铺，但是铺字还是不能丢掉，如果上架的listing就只有三三两两那就是精品模式而不是精铺模式了。简单来说，我所认为的精铺首先肯定是要多SKU的，而且是FBM自发货的模式，然后从自发货的listing里面选取有出单的，且潜力不错的产品来单独发FBA，按照精品来进行打造！另外个人建议虽然是铺货为先，但是一定不能乱铺、瞎铺，而是尽量去选好一个类目来铺，类目尽量要垂直，铺货也要按照垂直类目铺货法才是最高效率的！
关于类目的选择我个人建议大家尽量避开一些标品普货居多的类目，而多去选择一些有风格有style需要去选择的类目，比方说：服装服饰、饰品、户外、家具等等这些类目更好。因为标品普货类目太过于注重搜索流量，但是铺货你再怎么铺你也不可能铺到关键词首页上面去，而那些非标品类目其实流量不会集中在搜索这里，相对来说更分散，而且买家更喜欢挑选选择，你想一下你老婆买衣服的时候是搜一下关键词就买首页前三的么？
除了尽量避开标品普货类目以外，如下图所示，我们还需要对选择精铺的类目做更详细的调研, 毕竟精铺类目的理想对象应该就是市场容量够大但是卖家相对较少的类目。
Credit to 鸥鹭
思路已经讲清楚了，那么具体玩法就要各自发挥主观能动性了，毕竟每个人的情况是不一样的，为了方便大家更深刻的理解我上面说的思路，给大家举一个我们做过的精铺案例，希望方便大家更好的理解吸收：
简单来说就是首先认准一个垂直细分类目，比如说女式泳装这种垂直细分类目。然后通过自己的铺货工具或者ERP开始批量的上货，基本上上的SKU都是各式各样的女式泳装，全部都是FBM自发货，由于垂直类目肯定铺货的时候苦于SKU数量有限，这个其实是可以解决的，比如每一个款式，我们尽可能的变换图片和描述，尽量重复去铺，一个SKU最多可以变成40-60个SKU，其实产品还是同一个产品，目的也是尽可能的增加产品的曝光！只要你图片和描述尽可能区分开来，亚马逊也不会去merge或者发现到的，毕竟现在市面上同质化的listing有那么多！另外一些配件类产品是非常好这么玩的，比如一些汽车配件可能能够适配100多种型号，那么这个产品其实是能够铺100多个listing的。
与此同时，尽可能把售价压的很低，特别是相对于同类目FBA的竞品，价格可以压到他们的一半。这么做目的也很简单，FBM本来成本就比FBA要低很多，会有很大的价格优势，即使低价也不至于亏损顶多是少赚钱。另外还有很重要的一点是：这样大批量低价多种类的自发货SKU就可以极大的挤压同类目FBA的生存空间，尽可能的提高曝光，增大产品的动销率，而且也容易让好的产品能够尽快的脱颖而出。这种方法在欧洲小语种国家和垂直细分类目效果会非常好！大家大可以一试！
所以，基本上只要铺货量够大，都会有一定的动销率，针对动销的产品拿出来，做二次选品分析，选取几个自发货出单不错而且有爆款潜质的产品，重新改造一下listing然后就可以发FBA开始按照精品模式打造大推了。而且这么做还能够省掉FBA之前的测款环节，因为在前期动销完成以后，其实整个测款环节也就完成了！
讲完了“铺”的过程，下面就和大家聊聊如何“精”，因为从铺货里面脱颖而出的产品直接就发FBA还是太过于草率，所以我们还是需要进行更加精细化的考虑！关于精细化的选品和运营要讲的地方实在是太多太多了，可能三天三夜都说不完，我今天挑选两个相对来说更重要的部分，来和大家深入的聊一下：
第一部分
首先就是产品变体问题以及属性选择的问题，在初期预备发FBA产品选择的时候很容易就会遇到变体的问题，很多产品都是有变体的，单独发一个变体过去肯定不合适，而且卖家也很难判定哪一个变体可能是最好卖的，哪一个变体可能是最不好卖的，从而做出科学的备货方案。所以说，变体产品应该如何备货如何发FBA其实非常的重要，一旦不慎重的话就容易造成库存的积压，滞销变体的亏损直接吃掉畅销变体的利润，导致整个产品线还是亏损的！除了变体问题，产品性能和款式也会对初期的选择造成困扰，一款产品可能功能侧重点不同所以会有衍生出来很多的产品线，比如光是香薰机，都可以根据功能属性形状划分出来二三十款完全不同的产品。当我们确定一类产品的时候，也需要根据对他们特性的分析，选出来一款最适合的功能属性产品。
所以说，如下图所示，前期做好不同变体或者不同属性功能的产品数据调研至关重要：
耳机行业不同的功能特征的受欢迎程度对比：
Credit to 鸥鹭
服装行业不同颜色和尺寸的受欢迎程度对比：
Credit to 鸥鹭
第二部分
除了上面说的这部分以外，第二部分就是一个推广ROI的预估，毕竟精品运营是需要推广预算的，也就是一个先花钱后收获的一个过程，所以你可以把打造一个新品的全过程当做一个风险投资项目来看待，这样相对来说会更理性。那么前期的钱我花不花的起？资源跟不跟得上？中间风险大不大? 还有最后成功了我的利润又是多少？这些都是我们在发FBA之前需要考虑的点，如果发现ROI太差或者风险太大的情况，我们都需要放弃这个产品，就像你放弃投资一支股票或者风险基金一样。
那么前期的ROI预估如果去做呢？有一个相对来说比较简单粗暴的做法：我们可以把一个爆款产品的完整推广流程及生命周期做一个复盘，大致就能够知道一个产品想要达到爆款的程度我们需要做哪些动作了，而且相应的推广预算和资源投入也会一并算出来！另外我们还可以参考一下竞争对手或者明星大卖的具体运营手段！
那么这个产品推广的全流程应该如何获取呢？这里向大家推荐一款名叫鸥鹭的工具软件！大家先看下边这张图片，在一个产品完整的生命周期里，每一个运营动作和每一次变化都被完整的呈现出来了。大家如果仔细看的话，会发现这个图里边的信息量非常大。
Credit to 鸥鹭
鸥鹭为了这个功能更加全面完整的展示一个产品推广的全部流程，把亚马逊上所有影响买家购买决策的点全部都监控起来了，总数有80个之多。
Credit to 鸥鹭
除了大家平时一定会关注的BSR、价格、黄金购物车、评论、评分/星级、问答、Deal、跟卖之外，还有很多大家可能平时都没关注过的但是对销量影响巨大的点都被他们悉数监控到产品中。比如亚马逊今年开始在关键词搜索结果前面强势插入的自营商品（Tops from our brands）、Amazon's Choice商品和编辑推荐商品（Editorial Recommendation），导致大家的商品在流量关键词下的自然排名没有变化甚至上升的情况下，订单量却下降了很多。
Credit to 鸥鹭
所以根据使用鸥鹭对竞品的全方位监控，很容易就能够得出一个产品的完整推广地图，这样可以方便大家去做更好的产品ROI的预估，以及相应的推广资源准备，还有预算的安排，以及了解学习到竞品的推广策略和详细打法，并且能够为产品变体和属性的选择起到很大的指导参考作用。
今天就和各位聊到这里了，如果大家对精铺的模式和玩法感兴趣的话后面我也会继续深挖的。
我们建了一个亚马逊卖家交流群，里面不乏很多大卖家。
现在扫码回复“ 加群 ”，拉你进群。
热门文章
*30分钟更新一次
