分类 闲言碎语 下的文章

Github项目地址

程序特点及设计初衷:

  • PMecho名字的来历

我的职业是互联网产品经理PM,程序是PHP语言的,使用了Markdown,echo请看下一条。

  • 程序质量

毫无质量可言,PMecho只是为了完成拖延已久的学习目标,__如果需要一款更强大的博客程序,请使用 typecho__,作为typecho开发组名义上的一员,我没有提交过几次代码,他们写得太优秀了。

  • 使用md作为日志的存储载体

统计一下自己过去10年的博客,即使算上几次意外丢失的部分,总数量也不会超过500篇,使用mysql作为存储浪费了,备份起来也多了一道工序。现在只需要把md文件保存到对应的目录即可。

  • 没有评论功能

在社交网络极度发达的今天,更多的交流发生在微信、微博、twitter、facebook上,在博客上互动少了很多。

  • 没有分页、分类、标签、模版、插件、扩展

日志数量有限,没有必要做,再者也因为我不会。

使用说明

  1. md文件第一行和第二行请不要修改demo文档的写法,会导致出错。
    第一行:# 请用#的方式写标题
    第二行:__2016-05-06__
  1. achive_list.php文件是用来保存数组的,请保持可读写,也就是777。
  2. run_my_site.php会生成achive_list.php,请修改为只有自己知道的文件名。
  3. config.php是配置文件,请自由修改。
  4. 使用了 Parsedown 作为markdown解析器。
  5. 使用了 Typo.css 作为中文网页重设与排版样式。

市场规模

汽车保有量

几个数据如下:

2015年底,全国机动车保有量2.79亿辆,11个城市的保有量超过200万辆

北京日常晚高峰严重拥堵路段达70多条

哺乳动物尿尿时间为21秒

其中北京保有量 550 万辆,由于限行,路上车辆理论上限为 440 万辆,周末及节假日依然有 550 万辆。设高峰期同时上路车辆为150万辆,困在各拥堵路段的车辆为50万辆,其中有15000人有内急或其他需求(如避免迟到),可以转化其中30%,即是5000个用户,扩展到一二线城市及路怒症发作时候的代价,每日可获取50000个用户。

商业模式

核心逻辑

全量用户的高频需求已经被大互联网公司和先行者吃掉了,所以,

局部高频刚需切入市场

局部高频刚需切入市场

局部高频刚需切入市场

直接需求用户量不足,可作为市场切入功能存在,重点发展后续的汽车后市场,如车险、二手车、车用尿不湿等

产品架构

  1. 线上产品:APP一枚,详见uber
  2. 线下服务:

    • 在上下班高峰期,在重点拥堵路段根据车流量安排蹲点代驾师傅,就近代驾
    • 提供摩托车快速带离拥堵带,并抵达目的地(洗手间或其他目的地)的增值服务

运营玩法

提高信任感

  • 没有大品牌背书:

    • 在重点路段设置小货车改造的移动洗手间(融资重点),相当于落地店面,跑不了,缩短代驾时间,有利于重复接单
    • 默认购买丢车险(实际上拥堵太厉害,无需担心车辆丢失)
  • 有大品牌背书:

    • 属于信任扩散,不需特殊策略

摊薄成本

  • 利用拥堵时段躲避高峰的出租司机
  • 利用限行期间不开车的司机

互联网企业移动支付的特点

  1. 支付服务本身同质化程度高,需要结合上下游服务形成差异化
  2. 互联网企业的支付场景集中在用户消费一端,线上服务(如线上娱乐)发展优于线下服务(实体店消费)
  3. 规模效应明显,阿里和腾讯在竞争中处于优势地位
  4. 受政策和场景影响,高频低额度支付为主,增长依赖补贴

用户增长的基本模型

首先,是容易理解的基本模型

接触用户 * 转化率 = 获得用户

分解分析基本模型的的要素,如果需要获得更多的用户,需要做如下:

接触更多用户

控制支付流程中的必经节点

基本逻辑如下:

支付功能在消费大场景下,是通过设备和网络,以某种功能形式,将资金在不同账号间划转,连接的是 人与服务 ,支付本身并不能满足人群需求,满足需求的支付后反馈给用户的服务。

  • 控制物理网络或结算通道

    • 用支付账号登录商业Wi-Fi,认证账号获得更高网速或上网时间,同时分发代金券,本质上是流量广告
    • 线下的支付入口部署,如拉卡拉的实体机器,微信支付与支付宝的设备部署
  • 利用物流的控制力(实体消费服务的最终完成,依赖物流),反向影响支付用户选择
  • 利用信息流的控制力(虚拟消费服务的最终完成,依赖信息流),反向影响支付用户选择

2和3都是一种服务独占产生的排他性垄断,适合直接面向C端用户的强势企业,如苏宁和顺丰利用物流能力推广易付宝和顺丰支付,网易利用游戏推广网易自身的支付。

将支付能力或以支付能力为核心的服务输出到大用户量的合作方,与高频场景结合

基本逻辑如下:

需求场景不能被创造,可以被适配,思路从创造场景向获取场景变化,提供场景工具给合作方,提升高频行为的用户一侧价值

  • 高频低额度场景优先

    • 高频

      • 全局高频(阅读、检索、衣食住行)

        • 单用户需求高频,容易在工具型产品发现
        • 场景需求高频,容易在社交娱乐型产品发现
      • 局部高频

        • 细分人群高频(车主缴费、彩民购彩、烟民买烟、游戏玩家充值……)
        • 周期性高频(季节性或计划消费,如春节红包、定投存款、重大节日纪念日消费)
    • 低额度

      • 支付门槛低,安全性障碍小
      • 容易使用补贴作为获客手段
  • 已有能力的打包输出,增强合作商变现能力

    • 提供用户运营工具

      • 提供社区型网站的用户积分消耗(合作商积分兑换指定代金券,导入支付渠道)工具,增强合作商用户粘性,参考“兑吧”
    • 提供通用用户高频行为的增值

      • 站内或应用内搜索,基于关键词发放代金券或其它广告
      • 提供抽奖、一元夺宝、签到、微型游戏等基础运营工具,覆盖高频需求

提高转化率

重新包装支付能力及其形式,增强支付能力

基本逻辑如下:

将某种能力以某种形式打包成产品,对接不同服务,适配不同场景

应用这个逻辑:

为支付能力设计新的交互流程及方式,包装成与用户熟悉的场景契合的产品。支付的核心功能是 改变账号的金额 ,在用户消费场景下,遵循如下模式:

条件 -> 操作 -> 反馈

  • 条件,在何种情况下执行操作,或在何种情况下禁止操作
  • 操作,减少金额
  • 反馈,获得服务

应用这个模式:

  • 以时间做执行条件,可以将支付能力自动化,帮助用户应对周期性事件。如定期还贷、上缴工资、孝敬父母、投资、购彩等,对周期性支付金额可以做预测来优化体验
  • 以时间、地点、网络、支付对象、余额等做禁止条件,可以帮助用户实现更高的支付安全性

将支付能力与上下游服务组合,形成新竞争力

支付结果存在两种情况:

  • 增加金额,外部价值的流入
  • 减少金额,内部价值的流出

从这角度考虑上下游,新竞争力形成在:

  • 使更多金额进入账号。将赚钱的能力与支付能力组合,形成价值链条。

    • 对接资本获利能力(流动性高的货币基金如余额宝、流动性弱收益高的固定期限投资等)
    • 对接劳动获利能力(任务分发、广告分发,参考网赚APP)
  • 使更少金额流出账号,并获得更多服务。将互联网的规模效应与支付能力结合,降低用户成本,同时增加边际成本较低的产品销售,使服务商获得更多收益。

    • 会员类权益合并支付,降低用户月费
    • 团购消费

整合增强后的支付能力与上下游服务,可以包装出有竞争力的服务:

  • 用投资收入,定期用于购买彩票、视频网站会员、话费、投入公益事业等,不必消耗用户本金,又获得服务或收益, 碎片收益用于碎片消费,获得丰富服务
  • 将商户账号上的空闲资金,用于流动性高,风险低的投资,抵充交易费用

__包装起来__:

  • 应援宝,主打粉丝人群,投资收益定期用于购买偶像物品,刷榜
  • 公益宝,投资收益部分定期投入公益
  • 彩票宝,网络段子的实现,投资收益定期购买彩票
  • 视频通,投资收益部分定期用于支付视频网站会员费
  • 不停机,投资收益部分定期购买话费
  • 还款助手,定期划扣并还款

……

判断服务是否成立的标准如下:

  • 是否提供了足够改变用户行为的价值补偿
  • 是否提高了资源的使用效率

    • 在同等投入的情况下,扩大了系统规模
    • 在同等产出的情况下,降低了系统成本

与互联网金融紧密结合的未来趋势

  • 支付通道掌握真实的交易数据,能介入实际交易,非常适合作为数据密集型核心企业,开展供应链金融相关业务
  • 利用大数据帮助用户资产配置以及消费配置,成为用户金融入口

BI,Business intelligence,中文大都称为“商业智能”,我所理解的BI,是服务于产品或企业管理者,以决策支持为目的,对现有数据进行有效整合,并形成可视化报表作为决策依据的完整解决方案。

解读如下:

受众及目标

面向的是管理者,管理者的最主要工作是决策,决策有两个方面,一是对明确目标的做与不做,二是借助一定工具(BI就是这么一个工具)和方法分析现有信息,决定采用何种方法和步骤来实现目标。由此可以看到,管理者需要做某些方向的决策,BI就提供出与这些决策相关的数据提供参考。

受众和目标决定了BI作为完整解决方案的边界和架构,即是依据业务决策项不同而变化的数据支持服务,决策不被BI驱动或替代,通俗说,有什么决策就要什么样的数据,而不是有什么数据去做什么样的决策。

现有数据收集

产品或服务产生的数据繁杂多样,万变不离其宗,能支持决策的一定是终端用户产生的与业务目标相关的数据,可以近似看成用户的消费(不限于实际的购买行为,也包括虚拟物品如音乐、游戏等消费,甚至包括某个工具属性功能的使用也可以视为消费)数据、行为数据和消费品数据。

通常这些数据被储存在CRM、CMS及日志中,包括不限于以下:

  • 用户消费记录,尤其要关注用户在时间上前后相继的上下游消费
  • 搜索、收藏、分享等UGC
  • 用户的网络特征及设备特征
  • 用户的人口学信息(实际应用中由于准确度的问题,意义不大)
  • 用户浏览操作行为,内容型产品尤其重要
  • 用户间互动及关系链数据

还有一些信息在管理者所处系统的外部,如竞品信息和行业信息,需要额外收集和分析

竞品监控

  • 通过招聘职位和招聘人数确定对手发展方向
  • 通过专利申请数确定对手优势
  • 通过百度指数和关键词流量估算对手数量级
  • 通过社交网络或是问答网站的内部人员言论研究对手

行业监控

  • 通过关键词订阅关注行业政策变化
  • 通过权威机构发布的报告研究用户及客户在行业中的位置变化,预测下一步行动

对数据的有效整合

有效整合数据如同淘金,可分为三个阶段:

数据降噪

能收集到的数据很多,需要去除杂质,否则数据过大会影响到分析效率,甚至导致出现方向性错误。一般可经过这样几步来完成这个过程。

1.定义有效数据

  • 有效数据与产品或服务的目标高度一致,与终端用户的需求一致
  • 是准确且可重复获取的
  • 能覆盖用户群的大多数,在必要时才只覆盖活跃用户
  • 有效数据的获取的性价比高,可操作性强

2.简化参数和逻辑

  • 存在高度相关的参数时,保留其中一个
  • 存在相关度低,但证明同一结果的参数时,保留其中一个
  • 因果关系的推理过程是简单直接的

3.量化有效数据

过滤出有效数据后,还需要对不同的有效数据进行量化归一,举例说明,确定用户对某个电影的喜爱程度,用户将这个电影分享给很多好友的行为比仅仅观看该电影这个行为要高得多,量化(标准可以灵活,但是要明确且唯一)来标记这些行为,为后续的机器计算铺路。

数据结构化

把数据结构化,实际上是为了给BI创建决策模型做准备,这些数据可以准确描述参与到产品和服务中的各关键角色,如用户和消费品

  • 以用户为中心组织数据,划分为不相互依赖的维度,通常是用户特征和特定行为
  • 以被消费产品为中心组织数据,通常是不同维度的tag

数据分析

数据分析的方法和工具非常多,包括不限于以下:

  • 通过图模型、贝叶斯等完成用户偏好分析或用户分类
  • 通过统计工具确定用户质量分布和各操作节点的转化率
  • 通过回归预测趋势

决策依据

从决策过程来看,无论是组织决策还是个人决策,都有以下过程(BI输出的数据需要与决策匹配,因此输出项就产生在决策过程中):

  1. 发现终端用户问题并形成决策目标。重点是定义问题和定义最终目标(多以消费为最终目的)
  2. 描述每个方案的可能性。重点是定义影响决策的变量参数(BI的输出项)以及方案中要素的重要程度(BI输出项的权重)
  3. 定量评估方案。虽然是理性判断的基础,但量化本身又依赖于以往的知识结构,有感性部分。
  4. 综合决策。决策需要综合各种学科的知识能力,BI通过自动化输出决策关键信息来简化决策前期消耗的时间。

准确报表

报表是BI的最常见输出物,现代BI不局限于此,利用了大量数据可视化的成果,帮助理解数据,同时加入了异常监控、重要事件节点记录、方案资源管理等等功能,形成了完善的系统。

产品定位:服务于 唱片公司 ,以 消费脑残粉 为主,充斥着 炫耀和膜拜线上社区

比较好的情况下是有百度贴吧这样的平台来支持,社区不应当将用户隔离开,账号要统一,平台要具备很强的媒体性,比如微博。当然我最初是按游戏公会APP的路子来想的,方便会长召集。写了很久了,居然忘记放到博客上。

对唱片公司的意义

  • 将粉丝团放在平台,而不是放在个别的员工和团长手里
  • 多一个向粉丝销售歌曲或其他物品的通道
  • 占领粉丝手机,为每个艺人带来高活跃粉丝

对粉丝的意义

  • 高度归属感的同好官方社区
  • 与偶像高度互动的入口
  • 购买支持偶像的地方
  • 粉丝团有自己专属的APP

产品构成

服务器端

  • 闪屏管理
  • 简易CMS
  • 会员管理
  • PUSH管理
  • 专辑发布
  • 收益管理平台,销量查询

偶像版APP(或者获取微博内容)

  • 发布自拍
  • 发布语音
  • 发布文字
  • 论坛各项功能

粉丝版APP

  • 官方新闻(更新有push)
  • 偶像发言(更新有push)
  • 偶像行踪(更新有push)
  • 论坛各项功能
  • 数字专辑购买

会员分级

  • 管理员(删帖功能)
  • 偶像(删帖功能)
  • 版主(删帖功能)
  • 荣誉会员
  • 普通会员

会员勋章

  • 通过购买专辑获取
  • 通过购买虚拟物品获取

论坛功能(类百度贴吧)

  • 发图
  • 版主可删除对应版块内容
  • 可以展示用户勋章数

虚拟商城

  • 专辑展示
  • 购买记录

基础功能

  • 手机号注册(需要短信通道支持)
  • 微信、QQ、微博账号登录,规避自有账号注册,可拿用户头像、昵称等资料,也支持分享到这些社交网络
  • 接口加密保证安全
  • 消费安全

难点

  • 脑残粉的不可迁移性
  • 已经与其他APP合作产生的排他性

给唱片公司用的粉丝APP结构图

UI Demo,图有点大,所以不直接加载了