淘宝如何留住羽翼渐丰的大卖家

在大淘宝这个生态圈中,卖家的成长是非常重要的一环。淘宝让众多有着商业敏锐和发展思维的卖家从白手起家到日进斗金,这条致富和成长的道路已经被无数卖家走过,也经过了淘宝的大肆渲染。但是,淘宝只解决了让卖家成长壮大的问题,却一直没有很好的解决如何留住羽翼渐丰的大卖家。

1. 从卖家出逃说起……

众所周知,在过去的一两年中,淘宝经历了一个大卖家集体出逃的时期。当时,淘宝长期以来所表现出的善变和趋利,让众多大卖家心里始终是十五个吊桶打水——七上八下,不知道哪天自己就成了某个政策调整的牺牲品。在大卖家看来,必须得要多筑几个窟,才能避免随时可能发生的倾覆之灾。于是,以“柠檬绿茶”为首的一批大卖家,都开始自建B2C门户之路。后话就不在这里说了,且回到正题上来。

这些问题的起因,是卖家对淘宝信任感的丧失。在这一点上,淘宝过去的善变无常和诸多潜规则,确实有失一个大平台的风度。因此,为了挽回卖家的信任,淘宝开始效仿华为,制定企业自己的宪法,这就是后来的“刘庄项目”。从制度上给卖家一个清晰可期的保障和承诺,无疑对重塑卖家信任有着非常重要的意义。

然而,博得了卖家的信任,就能长久的留住大卖家了么?不然!

2. 谁主沉浮?

卖家成长到了一定阶段后,必然希望能自己掌控更多的因素。淘宝作为一个平台,必须兼顾各方的利益,尤其是确保中小卖家的成长通道,这就势必会对大卖家产生一个不可避免和制约。虽然平台有着这样一些无法摆脱的根本原则,但同时也有着一些独立B2C网站难以具备的价值。商家通常都是以利益为最高原则的,所以,只要我们合理的控制前者,充分的强化后者,那么在去与留的岔路口,相信大卖家自己也会作出明智的选择。

在很多人看来,商户平台的建设是淘宝留住大卖家的核心手段。但事实上,商户平台所做的东西,却并非前面所说的平台价值所在。当然,这并非否定商户平台在大淘宝中的价值,恰恰相反,他们所做的东西,都是淘宝服务卖家的根基,是吸引卖家,尤其是大卖家加入淘宝所不可或缺的必要工作。这些工作,从卖家的角度来看,其实都并非“无法取代”的。独立网店的页面设计可以远超“店铺装修”的所能达到的效果;大商家长期使用的进销存系统,也远比淘宝提供的后台更易用;企业自己的数据分析团队,远比淘宝现阶段的数据报表更专业……

3. 平台之“网”

真正无法被取代的,必然是一个平台所独有的,无法被复制的核心价值。就像腾讯之所以能独霸中国互联网的半壁江山,正是依靠QQ无法被复制的核心价值——用户的好友圈子。对大淘宝而言,这个核心价值就体现在“买家关系”上。说的具体一点,包括信用、口碑、回头率等一系列衔接买卖家关系的要素。可以想象,离开了淘宝,卖家所积累的信用将从零开始;离开了淘宝,卖家所打造的口碑只能在常客眼中得到一点点保留;离开了淘宝,买家回头率只能重新依靠促销和服务一步步培养……

但今天的淘宝,其实还远无法达到上面所希望的效果。因为我们的信用体系,正在渐渐丧失他的公信力和价值;我们还没有一个可以帮助卖家打造百年老店的口碑机制;我们也缺乏一个为卖家体现类似线下店铺回头率的游戏规则。只有我们下大力气去强化和运营这些维系买卖家关系的核心要素,才能真正引导卖家群体参与其中,一起编织这个比蛛丝更坚固和更富韧性的买家关系之网,最终实现像Apple那样,让用户(卖家)甘愿在这个平台上“作茧自缚”。


后续,我将陆续撰文详解“买家关系”中各个要素的强化与运营之路……

评价机制在C2C网购发展历程中的浮沉变迁

和不少人聊过关于网购的评价机制,尤其是C2C模式下的评价,大部分人都会抱怨淘宝或是拍拍现有的评价体系中存在着这样那样的问题。但实际上,评价机制也是随着C2C市场环境本身的变化,而在发生着相应的改变。只不过有时候市场的变化很快,走在了前头,而评价却有些跟不上脚步……

第一阶段:网购市场的圈地时期

在网购诞生的初期,C2C市场可以说是一个冒险者的乐园。大部分在这个时期接触并开始网购的人,都能回想起那种“提心吊胆”的网购感受。那个时候,市场其实还很单纯,并没有多少投机的商家,尤其是在淘宝推出“担保交易”的背景下。

初期的C2C市场,需要的是高速的、爆发性的增长,网购相关的机制设计都围绕着这个中心展开,评价也不例外。“好中差评”机制虽然从现在的眼光来看,有着种种内在的缺陷,但在当时的历史条件下,它所强调的“量”的积累价值和对“好评率”的追求,承载了拉动和助推网购高速发展的关键作用。

第二阶段:爆发式增长后的巩固时期

当C2C网购经历了初期的爆发式增长后,市场规模已变得日渐庞大。这个时候,必然会出现各种各样的市场秩序搅局者。“好中差评”的方式,也开始逐渐暴露出其负面的问题:

继续阅读评价机制在C2C网购发展历程中的浮沉变迁

用Guice+Peaberry实现OSGi环境下的JIT注入

Guice是一个Java下非常强大的依赖注入框架,相比其它同类框架,我更喜欢Guice这种“配置亦代码”的风格。除了开发友好性之外,Guice的过人之处还体现在它灵活的JIT(Just-in-time)注入上。利用@ProvidedBy()注解可以方便的为接口绑定定制的Provider,从而实现结合了动态逻辑的Lazy注入。

当Guice和OSGi框架碰撞到一起时,就会遇到一些观念上的矛盾:OSGi的动态生命周期在Guice本身的静态绑定下无法发挥其应有的作用,而Dynamic Service也无法方便的与Guice对接。好在开源社区已经有人意识到这些问题,并为两者搭起了一座鹊桥,这个项目就是“Peaberry”。

这两天在捣腾Peaberry时,发现它的设计主要是针对静态绑定,在与Guice的JIT注入一起用时,却还差那么一两块砖,于是自己把它给砌上了,顺便分享出来与大家交流一下。

按照Peaberry的用户手册,静态绑定一个DS服务的写法是在Module.configure()中使用:(以LogService接口为例)

bind(LogService.class).toProvider(Peaberry.service(LogService.class).single());

如果转为JIT注入,则必须提供一个相应的Provider类。虽然Peaberry.service(…).single()返回的正是一个Provider,但鉴于Java注解只能用字面类(Literal Class),所以这里需要包装一下。我的办法是定义一个抽象的公共Provider,用反射去识别派生类的具体泛型类型:

public abstract class JitProvider implements Provider {

	protected JitProvider() {
		@SuppressWarnings("unchecked")
		final Class clazz = (Class) ((ParameterizedType) getClass().getGenericSuperclass()).getActualTypeArguments()[0];
		provider = Peaberry.service(clazz).single().direct();
	}

	@Override
	public T get() {
		return provider.get();
	}

	@Inject
	protected void setInjector(final Injector injector) {
		injector.injectMembers(provider);
	}

	private final Provider provider;
}

具体使用JitProvider的接口以如下形式声明:

@ProvidedBy(Foo.Provider.class)
public interface Foo {
	...
	static class Provider extends JitProvider {}
}

这样,所有使用Foo服务的Bundle都完全实现了即需即用,不必再像过去那样在每一个用到该服务的Bundle的Activator中事先进行一遍Peaberry繁琐的bind配置。经此精简优化,Peaberry的易用性得到了明显的提升,使用起来也更加直觉化了。

解决Cisco AnyConnect VPN客户端的DNS优先级问题

Cisco AnyConnect VPN的客户端是一个工作于并行隧道(Split Tunnel)模式下的VPN软件,它可以方便的同时使用内外网两不误。它通过连接VPN后动态激活平时禁用的VPN虚拟网络适配器,并根据远端网关的配置应用相应的DNS和路由配置,实现了与默认网络环境无缝并行。但正是在其上述设计中的一个理想假设,为“中国特色”的互联网环境下使用它埋下了一个隐藏很深的问题。

如果你所连接的VPN网络本身是与Internet连通的,而且DNS也可解析外网的网址,由于AnyConnect会将VPN网络适配器的优先级提升到最高,因此远端的DNS配置会取代本地网络(例如家里的宽带网络)。如果你的本地网络和远程网络是同一接入线路,倒还感觉不到这之中的差别。但如果其中一个是电信线路,另一个是联通(网通)线路,你就会遇到一个很悲惨的状况:本地网络访问国内主要网站的速度会显著降低,因为DNS对大型网站CDN的解析结果是和你现有路由完全不同的线路,想象一下在你的联通(网通)宽带下访问电信线路的网站,那种感觉……

继续阅读解决Cisco AnyConnect VPN客户端的DNS优先级问题

[译] 富士F75EXR拍摄指南(适用于其它EXR系列相机)

原文:Fuji F70EXR — How to Shoot It MkII 作者:Kim Letkeman


注:这些设置适用于任何基于EXR的相机,包括F75EXR,F85EXR,Z707EXR,F200EXR和S205EXR。

我已经在这篇文章中涵盖了我关于这款相机中各种模式的思索。我甚至今天还更新过那篇文章,根据一个读者在邮件中的建议,增加了关于电影模式相关的部分。

不过,在那篇文章中,我涵盖了几乎所有的东西,并在我的学习和掌握过程中不断的附加补充,因此读起来可能会比较难跟上其中的逻辑。所以,我在这里再用简洁的方式介绍一下F70EXR的拍摄技术。

第一件事情:先调低一两档你的液晶屏亮度,这样通常可以让图像看起来像比较真实。但你还是经常需要通过回放中的缩放以确认关键局部的曝光程度,因为富士相机的固件没有提供这方面的辅助。

保持在以下3种主拍摄模式间用拨盘切换:

继续阅读[译] 富士F75EXR拍摄指南(适用于其它EXR系列相机)

Google Wave终于支持非Wave用户匿名浏览

下面这个嵌入式的Wave就是Google Wave团队的官方公告Wave,现在你不用登录Wave就能看到它了。不过匿名用户还只能浏览,参与互动仍然需要登录。但这样已经让Google Wave的可用性大大增强了,可以在更多Web领域发挥它应有的价值。

结合Google Wave API的Proxying-for,我们也可以自己实现匿名式交互,或者与其它身份系统集成(比如OpenID)。有时间的话,我会尝试做一个OpenID Proxy的Sample。

节能环保,你开始行动了么?

昨天的“地球一小时”,熄灯的时候,你是否有所思考,或已决定行动?节能、环保,需要从身边的点滴行动开始。

前不久,我在淘宝上买了一个50元左右的计量插座,可以监测即时功率、分时段用电量(最近1小时、1天、1月),最大功率2200W,夜光显示也很实用。适合用来评估家里各种用电设备的耗电情况,尤其是电脑。以下是初步测量的一些个人数据,供参考:

冰箱:运转功率70w,平均每天耗电0.6度
电脑(包括显示器):200-230w,节能(显示器待机、华硕 EPU-6激活) 130w,待机(S3) 4w,关机 2w
音箱:空载 18w,关闭 18w(说明这个开关纯粹只是个mute……)
无线路由器(D-Link DIR-615):6w
ADSL Modem:3.5w
电视机(老20吋):约 50w,关机 2w
电热毯:66w
(待补完)

从收集的数据来看,和我原本的预期有些出入。总结下来:

· 冬天的主要耗电大户还是空调和电热水器。
· 冰箱虽然也不省电,但不如我想象的那么耗。
· 电脑的功率中,显示器占据了大约1/3(可能因为24″更耗电吧……),所以尽可能在系统的电源设置中包含“关闭显示器”。
· 音箱关机不关机的耗电量没差别,所以平时务必要断开电源。

另外,再提供一些节能的实用技巧:

· 调低显示器亮度,可显著节能(对笔记本尤其适用)
· 如果你的主机有节能功能(如华硕的EPU),请将其置为自动节能状态(空闲时,功耗可下降5-15W)。
· 通宵下载时,请配合实用DShutdown软件,自动在下载完成或网络拥塞时关机。(通过网卡流量监测)
· 热水器、加湿器等使用频率较高的用电器,可以考虑配备一个定时插座(机械式/数字式),合理节能。
· 冰箱冷藏室一般下层较上层更冷,所以合理放置冷藏的物品,可以不必将冰箱温度调的很低。
· 电脑周边最好在关机后也一并切断电源。如果有关闭插排电源的习惯最好,没有习惯的话,可以考虑用这种“智能插排”

开发跨UI体系的Symbian应用

一直以来,Symbian都是基于OS + UI体系分离的设计,这种分离又不同于Android,后者的不同UI只是视觉呈现的差异,对应用而言,是完全兼容的。但Symbian的不同UI体系,如S60、S80、UIQ、QT等,彼此间连UI的API都不兼容,对应用开发者来说,这真是一个噩梦。虽然也可以通过将UI API的使用限定于Uikon UI(S60、S80、UIQ等当代UI体系共同的继承源),从而实现最大程度的兼容,但这样做是以牺牲广泛的可用UI元素为代价的,对稍复杂的应用而言都不太现实。况且即将取代现有各种UI体系的QT,又是一次颠覆性的变革,不用指望任何的兼容可能了。

那么,在这样一个变革到来之前的暗夜,如何开发一款可跨UI体系的Symbian应用呢?这并非没有可能,但有着诸多的限制。如果你的应用能满足这些限制的话,那么完全可以成为真正意义上的跨UI体系的Symbian应用。

继续阅读开发跨UI体系的Symbian应用

Google Buzz的解读误区

Google发布Buzz后,网络上迅速出现了大量对Buzz的评论,有正面的,有负面的,有炒作概念的,有跟着起哄的,甚至引发了大家对Gmail安全的担忧。这其中不乏一些对Buzz的误读,所以,在这里以我个人的理解来解释一下。

“Google Buzz是Twitter杀手!”

这是大多数媒体最喜欢的炒作方式,又一个Killer App出现了,于是编辑们都兴奋了,又可以赚足眼球了。事实上,Google Buzz和Twitter总体来看并不是一个层面上的应用,还构不成真正意义上的Killer。一些冷静的分析还是看的比较清楚,Google Buzz其实主要针对的是FriendFeed,因为它们都是聚合平台,让不同源头的信息聚合在一起。Buzz相对于FriendFeed的最大进步在于,它除了聚合信息之外,还创造性的利用Social Graph来聚合人际关系。

当然,Google Buzz除了聚合功能外,自身也充当了一个简单的信息源,可以在Buzz上发表富媒体信息。但事实上,你有自己充分的选择权,完全可以保持原有的习惯,在WordPress上写Blog,在Twitter上唠叨几句,这些信息最终都会自动被汇总到Buzz中来。

“我们不需要又一个社交网络”

当你迫不及待的跑来Buzz上兴奋的吼了几句后,才意识到它和Twitter也没多少差,反而在这里找不到Twitter上那种“振臂一呼,Follower百应”的成就感了。没过多久,你就会逐渐淡忘掉Buzz。这是因为,你把Buzz当成了一个和Twitter、Facebook、MySpace一样的社交网络。“又一个新的SNS,我不得不又一次花费时间从头建立我的关系网络。”其实这不奇怪,不光是你,连Microsoft也这么认为

本质上,Buzz并不想打造一个新的社交网络,恰恰相反,它的目的是推进一系列开放标准,使用户不必在各个SNS维护一个又一个彼此独立的关系网络,使人际关系得以重用和汇聚,进而构造起一个去中心化的Social Graph,不依附于某一个特定的SNS。

Buzz倡导运用XHTML Friends Network (XFN) 和 Friend of a Friend (FOAF) 挖掘和汇聚用户既有的关系网,实现SNS间的互操作性。如果各个开放SNS都能响应这一号召的话,那么将来我们就再也不用担心自己的人际关系被锁死在某个SNS中,甚至还可以借助新的SNS发现原有SNS中漏掉的好友。

“Buzz让信息的回复和评论更加破碎了”

这一点确实是目前不争的事实,因为无论你从Twitter往Buzz同步也好,还是打算反过来从Buzz发布到Twitter,你都得面对一个问题,回复和评论的不同步。你很可能因为只在Twitter上读消息而遗漏了Buzz里别人的评论,或许在习惯了Buzz后,又冷落了Twitter上的Followers。在Web应用越来越多的引入“聚合(Aggregation)”功能后,这个问题逐渐凸显出来。Google Buzz现在没有解决这个问题,但这只是因为目前的Buzz还尚不完整。Buzz的API文档中有一节“Coming Soon”,其中提到了Buzz未来对这一问题的解决之道——Salmon

之所以现在没有推出Salmon支持,我猜想,一方面是由于这个规范尚处在Draft阶段,另一方面它无法从Google单方面实现,因为信息源和聚合者都必须遵从Salmon协议,才能完整的实现评论同步。这个事情倘若让任何一家其它互联网公司来推,可能都收效甚微,但由Google Buzz倡导,其影响力就不可同日而语了。因此,Google在完成Salmon的支持前,先放出Roadmap来,让大家都意识到Google开放的心态和坚定的决心,这样Salmon才有机会得到广泛的认可和支持。

所以,就如同Wave对大多数人来说也不过尔尔,只有当你透过API去洞察其背后所希望表达的真正意图后,才能深刻理解Google每一款产品的前瞻和愿景。在大多数人被Buzz的优雅与便捷所打动时,我更看重的是它将对整个SNS生态圈所产生的深远影响,和它在推动开放和标准化上的显著贡献。

【闲言碎语】淘宝电器城、网瘾战争、轩网、GAE、tb.ly、第一推动丛书……

自从习惯了Twitter后,Blog写的是越来越少了。Twitter虽好,但相对于Blog,它其实很不利于内容的沉淀,再加上因国情问题而导致很多朋友无法访问,有价值的信息就此流失。为此,我准备尝试每周做一个Tweets的合辑,让这周中那些不是废话的内容能有机会沉淀下来,并且让更多人有机会从中获取有用的信息。当然,也随时欢迎在Twitter上Follow我

继续阅读【闲言碎语】淘宝电器城、网瘾战争、轩网、GAE、tb.ly、第一推动丛书……