1、 我看SNS的商业模式
目前的SNS APP自发地而非自觉地利用社会网络的性质(邀请好友)。
所以,利用商业模式的要素论,假设开发这样一个SNS APP——为女性开发的瘦身APP工具(其它,旅行):
² 价值主张:分为两个部分,一个是APP界面与功能,作为瘦身辅助工具;一个是理论部分,利用复杂网络与数据挖掘为APP用户建立社会支持。
瘦身辅助工具,包括APP界面与功能,比如瘦身日记、经验交流、心理互助、食品热量、团购服务等等。然后进一步提供其它信息,比如婚恋、服饰、家居、旅游,建立产品与服务的数据库等等。
而社会支持这个理论部分,是根据APP用户的特性,例如年龄、职业、性格、地域、爱好、阶段、体质等等,将特性相同或近似的用户形成一个簇群(性格可以互补),建立社会支持。为什么要提供社会支持,因为瘦身是一项长期的、艰苦的行为,很容易半途而废。虽然现在有学术论文对此作了研究,但目前的网络社区只有圈子功能,交流的效果非常有限,更谈不上社会支持。
² 消费者目标群体:想瘦身的女性。从瘦身开始,然后是身体塑形,然后是健身等。因为她们自身有强烈的诉求,但是瘦身过程漫长,容易失去信心。所以不仅仅是要提供APP的界面与功能,更需要建立一个良好的社会支持。
APP的目标群体定位为需要瘦身的女性,这些用户的需求和特性也未必相同。SNS如何精确投放广告?是采用分类还是聚类进一步划分用户群?如何利用小世界网络的长程连接、得到的簇群如何组织,使得传播的阻尼更小?
² 分销渠道:对于APP用户来说,APP的分销渠道当然是SNS平台。
但是对商业客户而言(从瘦身的产品和服务开始,逐渐进入其它领域),是采取点评网的加盟方式,还是采取代理方式,还是采用SaaS(提供CRM),根据发展阶段与时机而定。可以多准备几个方案。
² 客户关系:如果客户指的是APP用户,那么APP开发商通过SNS平台与客户进行联系。而且SNS平台根据APP的需求对用户进行分析。这部分功能可以运行在SNS平台,或者运行在APP公司。从原则上,应该由SNS平台作为CRM提供给APP开发商及下游企业。
如果客户指的是那些提供产品或者服务的企业,可以由APP开发商自行解决,也可以由SNS平台提供。但是,从SNS平台与APP开发商的实力与整体利益出发,应该由SNS平台建立一个类似于阿里巴巴、阿里妈妈这样的体系结构。SNS平台及之上的APP应该逐渐发展成为SaaS。
² 价值配置:即资源和活动的配置。这个我不懂,在商业模式这个语义中,资源与活动指的是什么?
² 核心能力:前面把价值主张分为两个部分,一个是APP功能与界面,另一个部分是社会支持的建立。
APP功能与界面对于APP用户的体验非常关键。但是,APP功能与界面很容易被抄袭。这种情况的避免,依赖于SNS网站的用户聚集与挖掘的能力。按照APP用户的特性和需求,这些用户形成不同的簇群,从而获得社会支持。
² 合作伙伴网络:自然,APP开发商与SNS平台成为合作伙伴。至于其它公司,比如广告设计、产品设计、生产厂商、服务商、各级代理等,也是合作伙伴网络的一部分。可以直接套用现有的成熟形式,不过更倾向于SaaS这样的形式。
² 成本结构:即所使用的工具和方法的货币描述。这个我不会。
² 收入模型:收入最终来源于相关产品和服务提供商。如何与APP开发商分成?APP开发商应该为这些高级功能付费?或者采用类似于现在的salesforce或阿里软件? 如何将CRM、B2C、SaaS和广告这几种收入来源组合起来,保证可操作性?应避免分类信息网站的覆辙。
2、 理论部分
为SNS建立一个抽象的逻辑体系结构。第一层为SNS层,第二层是面向应用的拓扑结构层,第三层是应用层。
集中式SNS的抽象逻辑体系结构
2.1 应用层
在上面的示意图中,顶层为应用层。UGC、APP、游戏、娱乐、视频、文件共享等都在这一层。在应用层中实现社区的外在表现,如下图(不完整)。社区的定义等机制放在面向应用的拓扑结构层中实现。
瘦身APP的外观示意图(不完整、非正式)
2.2 SNS层
SNS层负责个人用户的信息的存储与维护,一般不直接用于各种应用的消息传递。考虑当前架构的兼容性,可以直接将既有的基于Web的SNS作为底层。
2.3 面向应用的拓扑结构层
所谓面向应用的拓扑结构层,在集中式的SNS网站中,是一个为APP创建的描述社区的定义与划分的数据结构。这个数据结构可能是一个层次结构,也可能是平面结构。
在拓扑结构层中,为每个APP选择/设计的一个聚类器和分类器,或关联等数据挖掘,将特性相近的用户形成不同簇群,并统计运营性数据:
² 满足用户社会性需求:通过APP表现出来的社会性用户需求各种各样,需要在拓扑结构层解决。例如,“坚持不下去了。继续寻找身高165CM/60-65KGS 的姐妹一起相互监督”。在形成簇群时,情况可能非常复杂。例如,有的人要求性格相同,而有的人可能要求性格互补。
² 簇群尺寸:簇群的成员数量为N,而簇群为K连通,N大于等于K。也可以用簇系数来描述。簇群尺寸过小,可能没有足够的活跃用户。簇群尺寸过大,可能消息过多。
² 静态还是动态:现有的APP可能有许多用户,那么对于已有的用户,簇群划分是静态的。如果是新加入的用户,是批量处理,还是实时处理?
² 是否可以调整?用户是逐渐是增加的,而且用户可能自已迁移到另外一个簇群,如何利用这种自组织性?
² 聚类与分类算法的选择、聚类器与分类器的设计,两者的结合使用。增量聚类与精度的权衡。算法的并行化、分布式化?
² 在簇群划分过程中,如何利用小世界现象的长程连接?连通性如何保证(用户可以属于多个簇群,或者共享)?
² 连通支配集如何用于簇群划分?是否采用权值,如果设定权值?
² 最大流/最小割,是否可以有效地发现最佳传播通道?
² 如何利用集中点?
² 是否采用关联分析发现APP之间的关系?
² 特定的消息组播?比如说,团购、聚会?
² 查询/发现。在集中式的SNS,采用什么样的数据结构,包括内存与外存。
² 围绕簇群,形成一个安全或隐私边界?
² 运营性统计数据包括什么,类似于CRM?
² 其它,包括营销手段?
2.4 基于P2P的SNS
分布式SNS的抽象逻辑体系结构
前面是集中式的SNS,或者基于Web的SNS。那么是不是可以考虑一下基于P2P的SNS(在IM客户端实现):
² 用户习惯(在线用户数量与在线时长)
腾讯在2007年声称,QQ空间的单月活跃用户超过1亿,而QQ的同时在线用户量超过3000万。两者相差30倍。虽然没有两者在线时长的数据,但是大多数用户都是开机就运行QQ,因此有理由相信,QQ用户的在线时长也应超过QQ