spring cloud alibaba springboot nacos 版本兼容匹配

Spring Cloud Alibaba VersionSpring Cloud VersionSpring Boot Version
2021.0.1.0Spring Cloud 2021.0.12.6.3
2.2.7.RELEASESpring Cloud Hoxton.SR122.3.12.RELEASE
2021.1Spring Cloud 2020.0.12.4.2
2.2.6.RELEASESpring Cloud Hoxton.SR92.3.2.RELEASE
2.1.4.RELEASESpring Cloud Greenwich.SR62.1.13.RELEASE
2.2.1.RELEASESpring Cloud Hoxton.SR32.2.5.RELEASE
2.2.0.RELEASESpring Cloud Hoxton.RELEASE2.2.X.RELEASE
2.1.2.RELEASESpring Cloud Greenwich2.1.X.RELEASE
2.0.4.RELEASE(停止维护,建议升级)Spring Cloud Finchley2.0.X.RELEASE
1.5.1.RELEASE(停止维护,建议升级)Spring Cloud Edgware1.5.X.RELEASE
正式版本依赖关系(推荐使用)

依赖管理

Spring Cloud Alibaba BOM 包含了它所使用的所有依赖的版本。

RELEASE 版本

Spring Cloud 2021

如果需要使用 Spring Cloud 2021.0.x 版本,请在 dependencyManagement 中添加如下内容

<dependency>
   <groupId>com.alibaba.cloud</groupId>
   <artifactId>spring-cloud-alibaba-dependencies</artifactId>
   <version>2021.0.1.0</version>
   <type>pom</type>
   <scope>import</scope>
</dependency>
Spring Cloud Alibaba VersionSentinel VersionNacos VersionRocketMQ VersionDubbo VersionSeata Version
2021.0.1.0*1.8.31.4.24.9.22.7.151.4.2
2.2.7.RELEASE1.8.12.0.34.6.12.7.131.3.0
2.2.6.RELEASE1.8.11.4.24.4.02.7.81.3.0
2021.1 or 2.2.5.RELEASE or 2.1.4.RELEASE or 2.0.4.RELEASE1.8.01.4.14.4.02.7.81.3.0
2.2.3.RELEASE or 2.1.3.RELEASE or 2.0.3.RELEASE1.8.01.3.34.4.02.7.81.3.0
2.2.1.RELEASE or 2.1.2.RELEASE or 2.0.2.RELEASE1.7.11.2.14.4.02.7.61.2.0
2.2.0.RELEASE1.7.11.1.44.4.02.7.4.11.0.0
2.1.1.RELEASE or 2.0.1.RELEASE or 1.5.1.RELEASE1.7.01.1.44.4.02.7.30.9.0
2.1.0.RELEASE or 2.0.0.RELEASE or 1.5.0.RELEASE1.6.31.1.14.4.02.7.30.7.1
每个 Spring Cloud Alibaba 版本及其自身所适配的各组件对应版本

J2EE框架 Spring

J2EE框架 Spring 推荐

J2EE框架 面向方面AOP/IoC Web框架
Apache
Java
跨平台

Spring Framework 是一个开源的Java/Java EE全功能栈(full-stack)的应用程序框架,以Apache许可证形式发布,也有.NET平台上的移植版本。该框架基于 Expert One-on-One Java EE Design and Development(ISBN 0-7645-4385-7)一书中的代码,最初由 Rod Johnson 和 Juergen Hoeller等开发。Spring Framework 提供了一个简易的开发方式,这种开发方式,将避免那些可能致使底层代码变得繁杂混乱的大量的属性文件和帮助类。

Spring 中包含的关键特性:

  • 强大的基于 JavaBeans 的采用控制翻转(Inversion of Control,IoC)原则的配置管理,使得应用程序的组建更加快捷简易。
  • 一个可用于从 applet 到 Java EE 等不同运行环境的核心 Bean 工厂。
  • 数据库事务的一般化抽象层,允许宣告式(Declarative)事务管理器,简化事务的划分使之与底层无关。
  • 内建的针对 JTA 和 单个 JDBC 数据源的一般化策略,使 Spring 的事务支持不要求 Java EE 环境,这与一般的 JTA 或者 EJB CMT 相反。
  • JDBC 抽象层提供了有针对性的异常等级(不再从SQL异常中提取原始代码), 简化了错误处理, 大大减少了程序员的编码量. 再次利用JDBC时,你无需再写出另一个 ‘终止’ (finally) 模块. 并且面向JDBC的异常与Spring 通用数据访问对象 (Data Access Object) 异常等级相一致.
  • 以资源容器,DAO 实现和事务策略等形式与 Hibernate,JDO 和 iBATIS SQL Maps 集成。利用众多的翻转控制方便特性来全面支持, 解决了许多典型的Hibernate集成问题. 所有这些全部遵从Spring通用事务处理和通用数据访问对象异常等级规范.
  • 灵活的基于核心 Spring 功能的 MVC 网页应用程序框架。开发者通过策略接口将拥有对该框架的高度控制,因而该框架将适应于多种呈现(View)技术,例如 JSP,FreeMarker,Velocity,Tiles,iText 以及 POI。值得注意的是,Spring 中间层可以轻易地结合于任何基于 MVC 框架的网页层,例如 Struts,WebWork,或 Tapestry。
  • 提供诸如事务管理等服务的面向方面编程框架。

在设计应用程序Model时,MVC 模式(例如Struts)通常难于给出一个简洁明了的框架结构。Spring却具有能够让这部分工作变得简单的能力。程序开发员们可以使用Spring的 JDBC 抽象层重新设计那些复杂的框架结构。

Hibernate5 注解 命名策略

对于hibernate注解实体中属性对应数据库表的列名,怎么命名的问题,我们肯定不愿一个个属性去配置

Hibernaet5.1 之前  在applicationContext.xml中的sessionFactory中配置

<property name=”namingStrategy”>
<bean class=”org.hibernate.cfg.ImprovedNamingStrategy”></bean>
</property>

5.1开始

hibernate.ejb.naming_strategy将不再被支持,而是被替换成了两个属性:
hibernate.physical_naming_strategy
hibernate.implicit_naming_strategy

对于physical_naming_strategy有两个常用的配置:

org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy
org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl

对于PhysicalNamingStrategyStandardImplDefaultNamingStrategy的效果,

对于SpringPhysicalNamingStrategyImprovedNamingStrategy的效果。

法1:在sessionFactory的bean里配置

<property name=”PhysicalNamingStrategy”>
<bean class=”org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl”></bean>
</property>

法2:在sessionFactory bean的hibernateProperties property中配置

<prop key=”hibernate.physical_naming_strategy”>org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl</prop>

org.springframework.boot.orm.jpa.hibernate.SpringPhysicalNamingStrategy 是 spring boot 包提供地

<property name=”ImplicitNamingStrategy”>
<bean class=”org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyHbmImpl” />
</property>

或是

<prop key=”hibernate.implicit_naming_strategy”>org.hibernate.boot.model.naming.ImplicitNamingStrategyLegacyHbmImpl</prop>

Spring Data JPA 查询方法支持的关键字

Keyword Sample JPQL snippet
And findByLastnameAndFirstname … where x.lastname = ?1 and x.firstname = ?2
Or findByLastnameOrFirstname … where x.lastname = ?1 or x.firstname = ?2
Is,Equals findByFirstname,findByFirstnameIs,findByFirstnameEquals … where x.firstname = 1?
Between findByStartDateBetween … where x.startDate between 1? and ?2
LessThan findByAgeLessThan … where x.age < ?1
LessThanEqual findByAgeLessThanEqual … where x.age <= ?1
GreaterThan findByAgeGreaterThan … where x.age > ?1
GreaterThanEqual findByAgeGreaterThanEqual … where x.age >= ?1
After findByStartDateAfter … where x.startDate > ?1
Before findByStartDateBefore … where x.startDate < ?1
IsNull findByAgeIsNull … where x.age is null
IsNotNull,NotNull findByAge(Is)NotNull … where x.age not null
Like findByFirstnameLike … where x.firstname like ?1
NotLike findByFirstnameNotLike … where x.firstname not like ?1
StartingWith findByFirstnameStartingWith … where x.firstname like ?1 (parameter bound with appended %)
EndingWith findByFirstnameEndingWith … where x.firstname like ?1 (parameter bound with prepended %)
Containing findByFirstnameContaining … where x.firstname like ?1 (parameter bound wrapped in %)
OrderBy findByAgeOrderByLastnameDesc … where x.age = ?1 order by x.lastname desc
Not findByLastnameNot … where x.lastname <> ?1
In findByAgeIn(Collection<Age> ages) … where x.age in ?1
NotIn findByAgeNotIn(Collection<Age> age) … where x.age not in ?1
True findByActiveTrue() … where x.active = true
False findByActiveFalse() … where x.active = false
IgnoreCase findByFirstnameIgnoreCase … where UPPER(x.firstame) = UPPER(?1)

通过解析方法名创建查询

通过前面的例子,读者基本上对解析方法名创建查询的方式有了一个大致的了解,这也是 Spring Data JPA 吸引开发者的一个很重要的因素。该功能其实并非 Spring Data JPA 首创,而是源自一个开源的 JPA 框架 Hades,该框架的作者 Oliver Gierke 本身又是 Spring Data JPA 项目的 Leader,所以把 Hades 的优势引入到 Spring Data JPA 也就是顺理成章的了。

框架在进行方法名解析时,会先把方法名多余的前缀截取掉,比如 find、findBy、read、readBy、get、getBy,然后对剩下部分进行解析。并且如果方法的最后一个参数是 Sort 或者 Pageable 类型,也会提取相关的信息,以便按规则进行排序或者分页查询。

在创建查询时,我们通过在方法名中使用属性名称来表达,比如 findByUserAddressZip ()。框架在解析该方法时,首先剔除 findBy,然后对剩下的属性进行解析,详细规则如下(此处假设该方法针对的域对象为 AccountInfo 类型):

  • 先判断 userAddressZip (根据 POJO 规范,首字母变为小写,下同)是否为 AccountInfo 的一个属性,如果是,则表示根据该属性进行查询;如果没有该属性,继续第二步;
  • 从右往左截取第一个大写字母开头的字符串(此处为 Zip),然后检查剩下的字符串是否为 AccountInfo 的一个属性,如果是,则表示根据该属性进行查询;如果没有该属性,则重复第二步,继续从右往左截取;最后假设 user 为 AccountInfo 的一个属性;
  • 接着处理剩下部分( AddressZip ),先判断 user 所对应的类型是否有 addressZip 属性,如果有,则表示该方法最终是根据 “AccountInfo.user.addressZip” 的取值进行查询;否则继续按照步骤 2 的规则从右往左截取,最终表示根据 “AccountInfo.user.address.zip” 的值进行查询。

可能会存在一种特殊情况,比如 AccountInfo 包含一个 user 的属性,也有一个 userAddress 属性,此时会存在混淆。读者可以明确在属性之间加上 “_” 以显式表达意图,比如 “findByUser_AddressZip()” 或者 “findByUserAddress_Zip()”。

在查询时,通常需要同时根据多个属性进行查询,且查询的条件也格式各样(大于某个值、在某个范围等等),Spring Data JPA 为此提供了一些表达条件查询的关键字,大致如下:

  • And — 等价于 SQL 中的 and 关键字,比如 findByUsernameAndPassword(String user, Striang pwd);
  • Or — 等价于 SQL 中的 or 关键字,比如 findByUsernameOrAddress(String user, String addr);
  • Between — 等价于 SQL 中的 between 关键字,比如 findBySalaryBetween(int max, int min);
  • LessThan — 等价于 SQL 中的 “<“,比如 findBySalaryLessThan(int max);
  • GreaterThan — 等价于 SQL 中的”>”,比如 findBySalaryGreaterThan(int min);
  • IsNull — 等价于 SQL 中的 “is null”,比如 findByUsernameIsNull();
  • IsNotNull — 等价于 SQL 中的 “is not null”,比如 findByUsernameIsNotNull();
  • NotNull — 与 IsNotNull 等价;
  • Like — 等价于 SQL 中的 “like”,比如 findByUsernameLike(String user);
  • NotLike — 等价于 SQL 中的 “not like”,比如 findByUsernameNotLike(String user);
  • OrderBy — 等价于 SQL 中的 “order by”,比如 findByUsernameOrderBySalaryAsc(String user);
  • Not — 等价于 SQL 中的 “! =”,比如 findByUsernameNot(String user);
  • In — 等价于 SQL 中的 “in”,比如 findByUsernameIn(Collection<String> userList) ,方法的参数可以是 Collection 类型,也可以是数组或者不定长参数;
  • NotIn — 等价于 SQL 中的 “not in”,比如 findByUsernameNotIn(Collection<String> userList) ,方法的参数可以是 Collection 类型,也可以是数组或者不定长参数;

Spring cron 表达式

Cron表达式是一个字符串,字符串以5或6个空格隔开,分开工6或7个域,每一个域代表一个含义,Cron有如下两种语法
格式:
Seconds Minutes Hours DayofMonth Month DayofWeek Year 或
Seconds Minutes Hours DayofMonth Month DayofWeek
每一个域可出现的字符如下:
代码
Seconds:可出现,-  *  / 四个字符,有效范围为0-59的整数
Minutes:可出现,-  *  / 四个字符,有效范围为0-59的整数
Hours:可出现,-  *  / 四个字符,有效范围为0-23的整数
DayofMonth:可出现,-  *  / ? L W C八个字符,有效范围为0-31的整数
Month:可出现,-  *  / 四个字符,有效范围为1-12的整数或JAN-DEc
DayofWeek:可出现,-  *  / ? L C #四个字符,有效范围为1-7的整数或SUN-SAT两个范围。1表示星期天,2表示星期一, 依次类推
Year:可出现,-  *  / 四个字符,有效范围为1970-2099年
每一个域都使用数字,但还可以出现如下特殊字符,它们的含义是:
代码
(1)*:表示匹配该域的任意值,假如在Minutes域使用*,即表示每分钟都会触发事件。(2)?:只能用在DayofMonth和DayofWeek两个域。它也匹配域的任意值,但实际不会。因为DayofMonth和DayofWeek会相互影响。例如想在每月的20日触发调度,不管20日到底是星期几,则只能使用如下写法: 13  13 15 20 * ?,其中最后一位只能用?,而不能使用*,如果使用*表示不管星期几都会触发,实际上并不是这样。(3)-:表示范围,例如在Minutes域使用5-20,表示从5分到20分钟每分钟触发一次

(4)/:表示起始时间开始触发,然后每隔固定时间触发一次,例如在Minutes域使用5/20,则意味着5分钟触发一次,而25,45等分别触发一次.

(5),:表示列出枚举值值。例如:在Minutes域使用5,20,则意味着在5和20分每分钟触发一次。

(6)L:表示最后,只能出现在DayofWeek和DayofMonth域,如果在DayofWeek域使用5L,意味着在最后的一个星期四触发。

(7)W:表示有效工作日(周一到周五),只能出现在DayofMonth域,系统将在离指定日期的最近的有效工作日触发事件。例如:在DayofMonth使用5W,如果5日是星期六,则将在最近的工作日:星期五,即4日触发。如果5日是星期天,则在6日触发;如果5日在星期一到星期五中的一天,则就在5日触发。另外一点,W的最近寻找不会跨过月份

(8)LW:这两个字符可以连用,表示在某个月最后一个工作日,即最后一个星期五。

(9)#:用于确定每个月第几个星期几,只能出现在DayofMonth域。例如在4#2,表示某月的第二个星期三。
举几个例子:

代码
0 0  2  1 *  ? *  表示在每月的1日的凌晨2点调度任务
0 15 10 ? *  MON-FRI 表示周一到周五每天上午10:15执行作业
0 15 10 ? 6L 2002-2006 表示200-2006年的每个月的最后一个星期五上午10:15执行作业
91linux
一个cron表达式有至少6个(也可能7个)有空格分隔的时间元素。
按顺序依次为
秒(0~59)
分钟(0~59)
小时(0~23)
天(月)(0~31,但是你需要考虑你月的天数)
月(0~11)
天(星期)(1~7 1=SUN 或 SUN,MON,TUE,WED,THU,FRI,SAT)
7.年份(1970-2099)
其中每个元素可以是一个值(如6),一个连续区间(9-12),一个间隔时间(8-18/4)(/表示每隔4小时),一个列表(1,3,5),通配符。由于”月份中的日期”和”星期中的日期”这两个元素互斥的,必须要对其中一个设置?.
0 0 10,14,16 * * ? 每天上午10点,下午2点,4点
0 0/30 9-17 * * ?   朝九晚五工作时间内每半小时
0 0 12 ? * WED 表示每个星期三中午12点
“0 0 12 * * ?” 每天中午12点触发
“0 15 10 ? * *” 每天上午10:15触发
“0 15 10 * * ?” 每天上午10:15触发
“0 15 10 * * ? *” 每天上午10:15触发
“0 15 10 * * ? 2005” 2005年的每天上午10:15触发
“0 * 14 * * ?” 在每天下午2点到下午2:59期间的每1分钟触发
“0 0/5 14 * * ?” 在每天下午2点到下午2:55期间的每5分钟触发
“0 0/5 14,18 * * ?” 在每天下午2点到2:55期间和下午6点到6:55期间的每5分钟触发
“0 0-5 14 * * ?” 在每天下午2点到下午2:05期间的每1分钟触发
“0 10,44 14 ? 3 WED” 每年三月的星期三的下午2:10和2:44触发
“0 15 10 ? * MON-FRI” 周一至周五的上午10:15触发
“0 15 10 15 * ?” 每月15日上午10:15触发
“0 15 10 L * ?” 每月最后一日的上午10:15触发
“0 15 10 ? * 6L” 每月的最后一个星期五上午10:15触发
“0 15 10 ? * 6L 2002-2005” 2002年至2005年的每月的最后一个星期五上午10:15触发
“0 15 10 ? * 6#3” 每月的第三个星期五上午10:15触发
有些子表达式能包含一些范围或列表
例如:子表达式(天(星期))可以为 “MON-FRI”,”MON,WED,FRI”,”MON-WED,SAT”
“*”字符代表所有可能的值
因此,”*”在子表达式(月)里表示每个月的含义,”*”在子表达式(天(星期))表示星期的每一天

“/”字符用来指定数值的增量
例如:在子表达式(分钟)里的”0/15″表示从第0分钟开始,每15分钟
在子表达式(分钟)里的”3/20″表示从第3分钟开始,每20分钟(它和”3,23,43″)的含义一样
“?”字符仅被用于天(月)和天(星期)两个子表达式,表示不指定值
当2个子表达式其中之一被指定了值以后,为了避免冲突,需要将另一个子表达式的值设为”?”

“L” 字符仅被用于天(月)和天(星期)两个子表达式,它是单词”last”的缩写
但是它在两个子表达式里的含义是不同的。
在天(月)子表达式中,”L”表示一个月的最后一天
在天(星期)自表达式中,”L”表示一个星期的最后一天,也就是SAT
如果在”L”前有具体的内容,它就具有其他的含义了
例如:”6L”表示这个月的倒数第6天,”FRIL”表示这个月的最一个星期五
注意:在使用”L”参数时,不要指定列表或范围,因为这会导致问题

字段   允许值   允许的特殊字符
秒    0-59    , – * /
分    0-59    , – * /
小时    0-23    , – * /
日期    1-31    , – * ? / L W C
月份    1-12 或者 JAN-DEC    , – * /
星期    1-7 或者 SUN-SAT    , – * ? / L C #
年(可选)    留空, 1970-2099    , – * /
 注意:日和星期是任先其一
  ?:代表可有可无
  *:代表每一年
  秒  分  时  日  月    星期几  年
  0  0  0  10  12    ?    2009      //代表:2009年12月10日0点0分0秒执行(星期几:’?’代表忽略)
  0  0  0  10  12    ?    *        //代表:每年12月10日0点0分0秒执行
  0  0  0  10  *    ?            //代表:每月10日0点0分0秒执行
  0  0  1  1  *    ?            //代表:每月1号1点0分0秒执行
  0  0  1  1  3,6,9    ?            //代表:3月 6月 9月,1号1点0分0秒执行
  0  0  1  1  2-5    ?

图文结合案例解析淘宝店铺运营

投身电子商务做淘宝运营的朋友以及一些中小卖家问到以下几个问题:

一、运营是做什么?

二、运营人员需要具备什么知识?

三、学习运营可以看些什么书?

这三个问题我从后往前按自己的理解先来回答一下。

第三:学习运营可以看些什么书?——淘宝运营更多的是实际操作经验的积累,到目前为止,我还没有看到一本理论体系非常适合的书。所以建议在实操中自学。没事逛逛派代也能学到不少东西。

第二:运营人员需要具备什么知识?——在我看来,优秀的运营人员需要具备非常庞大的知识体系,推广技巧方面,营销策划方面,交互设计方面,视觉设计方面,用户体验方面,数据分析方面,消费者形为心理学等等,当然还要懂产品。

第一:运营是做什么?——这个问题我想不同的团队不同的发展阶段对它的理解都不尽相同。从广义上来看,运营是要来解决以下三个关键问题:流量、转化率、用户粘度。从狭义的角度来看,运营是解决转化率和用户粘度两个问题。关于这三点通俗的理解如下:

流量:把人带到店铺来

转化率:让进来的人买东西

用户粘度:让买过东西的人以后还经常来买

图解:除了把运营工作定义为解决三大关键问题之外。还有另外一种理解方式。运营是解决上游产品到下游客户两者端到端的问题,所以掌握产品,摸清客户成为另一种运营工作思路。

理论的空话先不多说。以下店铺是一朋友所开,近日发给我看,让我给他们提一些建议,那我就结合具体店铺来谈一下我做淘宝运营的几个思路:

一、流量方面

朋友没有给我店铺账号密码,所以对于他们店铺的流量分析就无从做起了,但解决流量问题,我还是可以通过我的思路来说一下有哪些工作分解

以上部分,可能内容还有不尽详实之处。各位派友也可以帮我补充补充。

二、转化率方面

在分析问题之前,同样我先将我的思路图列出来

关于如何提高店铺转化率,可能很多人都能说上来不少方法。按工作内容不同来划分,我将之归为三类,一是产品设计,也可理解为产品的挖掘包装;二是店铺装修,这个大家容易理解,淘宝上卖的就是文字和图片,所以店铺装修是个大问题。三是活动策划。好的产品,好的页面展示,当然配合诱人的活动形式才容易产生最快的购买。

以下就细细来说一下我朋友的店铺。

1、店铺首页设计

首页图片我只截了首屏如下:

分析情况如下:

1)主色调:店铺首页的主色调为大红色,整体效果有点跟小也香水类似。使用醒目色红色来引起注意,聚集视觉焦点,这本身无可厚非。但考虑到当前是炎炎夏目,暖色系大红大黄容易让用户产生烦燥情绪,造成跳失率偏高的情况。相比之下芳草集的绿色调,御泥坊的灰蓝色调,相宜本草的蓝绿色调都更胜一筹,让用户看起来清新舒爽。其实类似这个店铺首屏这张焦点图的效果就非常友好。因此建议在做店铺整体风格设计的时候考试到季节因素气候因素。

2)分类模块:如下图所示:店铺的产品分类存在结构混乱,内容不全的情况。而这个版块又恰恰是非常重要的一个部分。欧美用户更愿意使用搜索功能,因为他们的民族更强调个性化,有冒险精神,而亚洲用户则更偏好使用类目导航的固定路径,相对求同存异,对已知有依赖性。所以,好的类目导航会对用户体验有非常大的提升。

目前为止,我还算是一个化妆品门外汉,但我觉得,化妆品产品的分类至少需要切以下几个维度:一是按功能分,有护肤类,彩妆类,美发美体类;二是按性别分:男士专用,女士专用;三是按肤质分:油性皮肤,中性皮肤,干性皮肤;第四,按品牌分,欧莱雅,The Face Shop,相宜本草等;第五,按热门关键词;第六,按价格区间。。。

也许有人会说,左侧分类栏有详细的分类啊,其它通栏位置还有必要这样详细的分类导航模块吗,我的答案是肯定的,需要。

如果不做这样的分类。举个例子,我是一个油性皮肤的人,进了店铺半天也没看到跟油性相关的产品或关键词,那我可能没有兴趣浏览下去了,直接关掉网页

3)框架布局。在框架布局方面,应该更多的考虑到用户的浏览习惯。根据Google的眼动仪测试报告。用户在浏览网页的时候,习惯路径是从上到下,从左到右。综合起来,就是“F”型的热点区域。因此店铺首页在做布局设计的时候,也要考虑到这些方面。西红柿美肤馆这个店铺显然没有考虑到这一点,三屏以下,基本上采用的都是相类似模块的重复堆砌,例如下图,两张图如此近的堆砌,究竟是让用户看哪一张呢

2、单品页设计问题

1)宝贝标题:我将当前店铺中销量最高的一个拿来做案例。此商品标题如下:

镇店之宝 Cetaphil/丝塔芙 舒特肤温和洗面奶118ML 洁面/抗敏感

首先说一个常识,宝贝标题不是简单对产品作一个文字描述,宝贝标题中的每一个关键词都是一条路径,这条路径在用户进行搜索行为的时候,就能把陌生的他与自己的商品建立一条通道联系。所以选择匹配度高的热门关键词作为宝贝标题是正确的选择。先看一下这个宝贝标题各个关键词在淘宝的日搜索量。

从上面这个图就能看出来,有两个宝贝标题关键词日搜索量为0,还有一个搜索量不到300,那么这三个关键词就应该被优化掉。举个例子“护肤”这个关键词日搜索量就有5000多,为什么不用呢。

2)产品介绍:这个单品页里面对产品的介绍顺序如下:

产品文字描述——使用需知——产品图片展示——品牌介绍——名人推荐——效果评测——用户体验反馈——产品细节展示——热销纪录

当我看完整个单品页后觉得脑子里面很混乱,我发现我没有装进去多少有价值的信息。是内容不够多吗,不是,内容已经够多了。问题在于,陈列顺序出现了逻辑上的混乱。

当你向我推荐一个东西的时候,你先要告诉我你是个什么东西(品牌),买来有什么用(功效),如果我觉得有兴趣,我还会接着问,你这个东西是正品行货吗(资质认证),还有谁在用(热销记录)。最后被你说服了,我想买了,但我还有最后一个问题,这个东西怎么用呢?(使用需知)

结合以上思维路径,我建议单品页的内容介绍按以下步骤来:

产品文字描述——产品图片展示——产品细节展示——品牌介绍——效果评测——名人推荐——用户体验反馈——热销纪录——使用需知

另外,西红柿美肤馆这个单品页的部分图片也太不专业了,例如如下所示,感觉很山寨。

3、分流页设计问题

分流页我想说两个问题:

第一:不同类的产品,应该使用不同的单品页模板。不同的单品页模板设置不一样的分流模块。

为什么这么说呢,如果所有的单品页点进去都是相同的分流模块,那跟人家想进商场你在门口硬塞给他一张传单有什么区别呢。其实应该这样,例如卖服装的,外套的单品页里面分流模块就应该放裤装的产品,男士护肤品的单品页里面分流模块就应该放男士护肤的专用产品。油性皮肤护肤单品的分流模块就应该推荐一些其它适合油性皮肤的产品,等等。

第二:分流模块的产品其实除了掌柜热卖和特价秒杀团购外有更多选择。

还是举个例子来说,单品页的分流模块分为宝贝详情上方,宝贝详情下方两个位置。在一个洗面奶的单品页里面,宝贝详情上方的分流模块可以放什么呢,我认为在这个位置,你要告诉客户的是,买了这个洗面奶,你还可以买以下相配套的爽肤水,隔离霜哦。那宝贝详情下方的分流模块又可以放什么呢?我认为客户浏览到这里的时候有可能会对本产品不感兴趣,有跳失的可能。所以在这里,我们可以告诉他,如果这个洗面奶你不喜欢,还可以选择其它品牌性价比更多的洗面奶哦。

综合来说,分流页模块不是简单地把自己热卖的,或者搞特价的商品强推给客户。如果是这样,关联销售根本就提高不起来。我想超市里面啤酒和尿不湿的案例大家都听过了吧。

有句话是这么说的,关联销售不是为不同的买家找共同的产品,而是为不同的产品找到共同的买家。这句话有点绕,大家慢慢理解。

我这朋友家西红柿美肤馆的分流页模块就犯了这个问题,既单调又单一。如下图所示:

4、活动策划问题

为什么产品好,还要做活动呢,我想用一句话可以概括。在中国人的思维里,买东西不是为了买便宜,而是为了占便宜。有一个案例是这样的:某超市某品牌牙膏正常日销量为2000盒。有一次,他们做了一个促销活动,降价5毛,仅限一日。结果当天该品牌牙膏的日销量是10000盒。真的是消费者买到便宜了吗?不见得,一盒牙膏正常情况下一个人可以用一个月。也就是说超市降价5毛等于每个人每个月节约了5毛钱。5毛钱多吗,如果我说地上每天有一毛钱让你捡,一个月捡3块,我估计没有几个人愿意捡的。因此。店铺经常策划一些活动就是为了让消费者觉得在你这里买东西占到了便宜。

我观察过西红柿美肤馆这个店铺一段时间。发现他们的店铺活动非常之简单,没有花样,没有主题。除了打折,还是打折。

其实店铺活动策划这方面,是有很多种选择的。我分成了下面这四类

一是常规营销活动:比如常年满多少包邮之类的,收藏送红包,送优惠券之类的

二是主题系列活动:例如周未购,每周秒杀,新品抢先购之类。通过第一季,第二季,第三季这样的持续形式来促使新用户的回头,老用户的积累。相当于每周给客户一点盼头。

三是节点促销活动:例如情人节,感恩节,国庆节,暑假等等,都可以包装成活动。活动形式灵活多变,满减,满送等,例如:五一我要“价”给你,暑“价”集中营等等

四是噱头促销活动:这个很多店铺玩过,比如说冲冠特价,掌柜搬家清仓等等。

本来还有再分析下其它几个方面,奈何本人一向不喜欢篇幅太长,打住吧

三、用户粘性方面

还是先上图,把我的思路先抛出来,如果有高手觉得内容不充分,也可补充。在我看来,要解决用户粘性的问题,需从以下几方面着手:

以上内容不作解释了,相信应该都看得懂。具体到西红柿美肤馆这个店铺,因为在他们这没买过东西,所以CRM做得如何,售后服务做得如何,就不得而知了。我仅仅从页面上获取的信息提出几点想法。

1、化妆品的消费人群有一个特性,就是除了买东西之外,还有一个交流分享的需求。在这方面,NALA做得还不错。通过QQ群来进行有效的管理。给客户一个自由交流分享的渠道。

其它除了QQ群。还有淘宝店铺帮派这个东西可以充分利用起来。把店铺帮派打造成一个小论坛,小社区。满足客户在这方面的需求。此外,店铺帮派还可以填充一些关于美妆护肤的专业知识。做信息内容的输出。提高可读性。

再有,就是利用时下比较热的微博来做CRM。通过与客户的在线沟通互动,增加用户的粘性。提高客户的复购率。

很遗憾的是,在这两方面,我朋友这家店铺都没有重视起来。

2、对于淘宝上的用户来说,店铺忠诚度是非常低的,那么如何来打造自己的忠实客户人群呢。我想利用好售后服务卡是非常关键的。

一般情况下,售后服务卡大多数人都理解为退换货表。在我看来,不仅仅如此简单,里面大有文章可做。一张设计精美的售后服务卡,可以让用户爱不释手,可以拿来当书签。增加了跟用户的“对话”时间,也即增加了用户回访店铺的可能性。不要好不容易跟一个客户产生了交易又彻底消失在他的世界里。要学会挖掘客户终生价值。

此外,如果可以的话,这张售后服务卡上还可以印上店铺红包的领取代码,或者直接充当一张有限期为一个月的包邮卡均可,让客户在收到货的同时有一个小小的惊喜。也大大提高了店铺的回访率和复购率。

总结一下,淘宝运营是做什么呢?

第一:通过运营手段提高店铺流量,降低店铺流量获取成本

第二:通过营销策划,店铺设计来提高店铺的转化率

第三:通过CRM,来增加店铺的忠实客户。