每个产品经理都有一颗创业的心，这是第二遍重新读《途客圈创业记》，有选择性地主要关注创业本身，对技术篇章选择性地跳过，很受启发；自己不由自主的融入故事，各种画面复现在脑海里。

故事本身讲的是「陈天」一次完整的创业经历，从创始人组队，到进入创新工场进行为期四个月的孵化，再到 15 万美金的天使，再到团队膨胀为节约支出裁员、搬进民居，最后创始团队因为对业务战略的分歧选择退出。

下面主要说说故事对我的触动：

1、行业的选择
小米的「风口飞猪」论还是有一定的道理，陈天选择的旅游行业本身是一个低频，并且已经有一些巨头，比如马蜂窝、穷游、携程等。当下，移动互联网的时间已经逝去，接下来是 AI 的时代了，尽量往上面来靠。

2、业务一定要聚焦
我们对标的不是携程这样的巨头，而是精细化的用户群，有很明确用户画像的那一部分。

3、需先问自己下面 7 个问题
1）问题（最重要的 3 个问题）/ 客户区隔（目标客户，用户画像）
2）独特价值主张（为什么你与众不同，核心价值）
3）解决方案（最重要的 3 个功能）
4）渠道（获取客户的路径）
5）支出构成 / 收入来源
6）关键指标（要度量的关键性行为，数据指标）
7）排他的竞争优势（无法被轻易复制或购买，就是壁垒）

4、创人团队的构成和股权
务必要相互互补，最大的忌讳就是交集过多，其一浪费人才，其二相互不服。还有另外一点，整个创始团队中，有且只有一人是核心，占大股，有绝对的话语权，创业有些时候就需要一些「独裁」。

5、创始团队一定要有工资
在初期自己掏腰包的时候可以暂时不发工资，但一旦有现金就需要，即使低于市场行情。仅靠激情是无法支撑数年的，激情过后总是需要回归到生活的油盐材米。

6、创始成员不一定要都是 CXO
CEO 好像是必不可少的，但 CTO、COO、CFO 就未必，可以先冠名「总监」，以后根据公司的成长来提升，一定要有个 open 的心态。因为很有可能公司的成长超越自己的成长，最后自己已经无法驾驭公司的业务，就需要吸入有能力的人来胜任核心的角色，比如 CTO。给自己留个台阶，進可以攻，退可以守。

7、创始人的瓶颈就是企业的瓶颈
站的高看的远，创始团队没有高于常人对业务的认知，很难杀出血路。所以在选成员的时候首先具备行业背景或者有上下游资源的。

8、膨胀是最大的忌讳
初创团队膨胀多和顺利融到资相关，想想初期的苦日子，再想想现在银行账户里躺着的「大笔现金」，放开了干。最明显的表现就是团队成员迅速翻倍，工作不饱和。

9、定期复盘是很必要的
埋头苦干很容易成为井底之蛙，得跳出业务本身来进行周期性的复盘，将问题暴露出来。

10、人员扩张
只有在你自己因人手缺乏而深感痛苦的时候再考虑扩充人手，否则人员膨胀会很厉害，会很烧现金流。

11、让新员工快速融入
留人要从入职的第一天做起，一个热烈的欢迎邮件和全体的一次自我介绍。通过新员工培训能到达两个作用：其一，让新人迅速融入团队；其二，让新人感受到公司对自己的重试。

12、白纸黑字
重大的决策一定要落实到纸上，人生百态，时过境迁，有些时候是无力去执行当初的口头承诺，不是我不想。还是一个大前提：相信大家都是好人。

====下面是我比较中意的几句话===

创业是从零开始创业一个事业，理所当然会遇到各种问题和挑战。所以除了信仰和勤奋这两种特质是创业者身上必不可少的素质，系统和深入地思考也是必须具备的素质。

当你犯错时，不知道问题的根源是很可悲的，因为你无从改进；更可悲的是，知道了问题的根源，却刻舟求剑，南辕北辙，力气花了更多，得到了一个更坏的结果。

上周去了趟上海，在高铁上体验了一回 12306 App 在线订餐，只有济南和南京这两个大站能预定，其次预定截止时间是到站时间的前两个小时，我预定的时候济南已经关闭预定，所以我就预定了南京的老娘舅，下午 1 点 20 用餐。

车从南京站驶出几分钟之后列车乘务员就将订餐送到我的座位上，整个过程还算流畅，不足之处就是让我饿到 1 点多才能吃上饭。下面具体说说整个流程和我的一些思考。

1 流程

整个流程中涉及到四种角色，乘客、餐厅、配送员和乘务员，具体流程见下图：

2 盈利

再谈盈利之前我们先聊聊成本：

1. 订餐系统的开发成本
2. 餐厅的洽谈接入成本
3. 推广给终端乘客的营销成本

对于掌握丰富资源的铁道部来说，2 和 3 很容易无偿实现，至于 1 应该需要一笔支出，但正是因为基于系统，模式可以上量，服务 100 次、1000 次或者更多次火车的成本基本一样；而传统的小推车需要人员来覆盖，伴随着上量带来的是乘务员人数直线增加。

通过在线订餐，铁路升级成餐饮平台，和市面上的外卖平台逻辑基本一样，通过对餐厅进行提成；最最重要的是将铁路自己提供的业务大幅缩减，不用自己采购食物、不用自己微波炉加热、不用自己推车叫卖等一系列繁琐的流程，升华成了轻资产轻服务的平台。

在线订餐铁路收入 = 订单总金额 * 提成比例 – 成本(上面提及的 1 2 3)

订单总金额直线上升，而成本几乎不变，那么收入势必也按照同样的倾角直线上升，这是过去的小推车模式不可能发生的。

3 利弊

利：食物多样化

一谈到火车上的饭，随之而来的是两点「难吃」和「贵」，现在一系列的连锁快餐店接入铁路餐饮，比如老娘舅、麦当劳、肯德基、大娘水饺等；如此看来难吃应该会有很大的改善。

正是这点驱动乘客想要来使用在线订餐。

弊：就餐等待时间长

我的这趟旅途，活生生的饿到下午 1 点半才能吃上饭，正常应该是 12 点。要解决这个问题就需要提供更多站点的预定。

4 适合场景

买绿皮车坐票的会在线订餐吗？肯定不会，还是一盒泡面来得实在，还是自己带上火车的，不是小推车上买的。在线订餐还是有一些台阶的：

1. 能并且会手机上网
2. 有一定消费能力（一个人用餐 35 – 50 元）
3. 用餐时间不在半夜 (半夜餐厅不营业)

如此看来，还是高铁和动车适合，它们半夜不开车，能承担 500 票价应该能接受 40 左右的餐费支出；Z、T、K 应该不适合；同时，小推车还是有存在的必要的。

• 排版消耗的时间太多
• 边排版边撰写打乱我的写作思绪

看到「可能吧的文章是如何排版的？」之后感到神奇：居然还可以这样，果然是极客。

于是乎就开始着手自己的一套自动化排版式样。

排版最终达到的效果就是，在 Markdown 编辑器里 Ctrl + C，然后到微信编辑器里 Ctrl + V 就搞定，请见示例文章：：
http://mp.weixin.qq.com/s/oaDuGq4oaNUlWb3oYYbZyw

>

本文的排版方法应该比可能吧的更加简单些。

一、操作

下载工具

我们首先要下载 Mac 平台下的一个 Markdown App 「MacDown」：

http://macdown.uranusjr.com/

由于我只有 Mac 电脑，也就只在 Mac 上要试验和验证过，Windows 的童鞋请先看明白思路，再结合 Windows 平台下的 Markdown 工具来举一反三。

在 MacDown 中设置样式

1、下载样式文件
https://github.com/vincent4j/paiban/blob/master/hrule.css

2、在 MacDown 中设置样式

把刚才的「hrule.css」文件拷贝到 MacDown 的样式目录中去，最后在「CSS」下拉列表中选择 hrule。

在 MacDown 预览中复制

1. Ctrl + A
2. Ctrl + C

粘贴到公众号编辑器中

打开微信公众号的编辑器，「Ctrl + V」就搞定了。

二、总结

这种排版由于是基于 Markdown 语法，所以只有符合 Markdown 基本语法的文字效果才能排版出来。

例如，「一段话里部分文字标红（就是文字着色）」无法实现。

我们回过头来想想：排版的目的是什么？

在节省时间的前提下达到视觉美，那 Markdown 都不支持的语法不能实现就不能实现吧，谁叫我是 Markdown 的死忠呢。

一、效果展示

1、Material Design 中文版（有侧边栏菜单）

• 页面效果：http://zitiao.org/material-design/
• 文档仓库：https://github.com/zitiaocn/material-design

2、GitBook Help Center（无侧边栏菜单）

• 页面效果：https://help.gitbook.com/
• 文档仓库：https://github.com/GitbookIO/help.gitbook.com

二、功能特性

1、页面美观

主要体现在两个方面：其一，页面的外观，请回头看看上面的效果图。其二，链接的格式，如下：

• GitBook 链接示例：http://zitiao.org/material-design/usability/accessibility.html
• MDwiki 链接示例：http://dynalon.github.io/mdwiki/#!layout.md （我个人见不得 #、! 之类的字符）

2、多人协作 & 版本控制

文档内容托管于 GitHub 之上，GitHub 本身就具备 多人协作 和 版本控制 的功能。当然所有的 Git 托管平台都可以，比如说国外的 GitLab、Bitbucket，或者国内的 git.oschina.net、coding.net 都行。

如果希望仓库私有，国外产品推荐 Bitbucket，因为他私有仓库免费，而 GitHub 私有仓库收费。国内的好像私有仓库都免费，在安全性和稳定性方面可能不如 Bitbucket。

3、Markdown 写作

文档内容托管于 GitHub 之上，GitHub 本身就具备 Markdown 写作 的功能。

4、代码高亮

通过 GitBook 的插件能很容易支持代码高亮（这就是站在巨人的肩膀上的好处）。

5、实时更新

通过给 GitHub 仓库配置 webhook 进行 push 时的消息推送，能触发服务器实时更新（服务器上需要些代码）。

6、一键部署

只需要简单的几行命令就部署完毕。

三、所需资源

唯一的一个条件就是，一台支持 Node.js 的服务器（公网和内网服务器都行）。

四、操作手册

详细的操作手册见：http://zitiao.org/deploy/

累计来了 100 个新线索，那具体每个渠道来了多少呢？因为会分渠道合算投放成本，比如说百度 SEM 来了 10 个线索，最终付款 1 人；站内轮播图来了 8 个线索，最终付款 2 人，那个渠道优质？当然是站内轮播图。那上面的 4 个数字分别怎么来的呢？具体的实现细节我们在该系列的接下来的篇章里进行剖析，主要是通过「UTM」进行渠道投放。

这篇文章会教会大家具体如何能做到，开始之前首先要普及下 UTM 的概念。

UTM 是什么

UTM 是 Urchin Tracking Modules 的英文缩写，不太好做中文翻译，一般都直接读成 U T M。UTM 由下面 5 个参数组成：

示例

http://www.example.com/?utm_campaign=spring&utm_medium=referral&utm_source=exampleblog

http://www.example.com/?utm_campaign=spring&utm_medium=email&utm_source=newsletter1

http://www.example.com/?utm_campaign=spring&utm_medium=email&utm_source=newsletter1&utm_content=toplink

UTM 实战

规范

• 推荐使用「下划线 _」，不推荐「减号 -」；
• 可以使用中文（尽量不用），但需要通过「构建工具」进行转码；
• utm_source，utm_medium，utm_campaign 三个参数必须；utm_term 和 utm_content 可选；
• utm_term 是 SEM 的关键词（非 SEM 时留空）；
• 投放 URL 中 Path 包含的信息不用在 UTM 中重复（比如说投放 /train/web，在 UTM 不用再包含 jiuye 和 web 信息，因为 URL 的 Path 就已经能看出来了）。

参数枚举

典型场景示例

1、Baidu SEM
_URL_?utm_source=baidu&utm_medium=cpc&utm_campaign={{推广计划}}&utm_content={{推广单元}}&utm_term={{付费关键词}}

2、SM SEM (神马)
_URL_?utm_source=sm&utm_medium=cpc&utm_campaign={{推广计划}}&utm_content={{推广单元}}&utm_term={{付费关键词}}

3、QQ 群
_URL_?utm_source=qq&utm_medium=qun&utm_campaign={{推广主题，比如 teacherday}}&utm_content={{群号或群名称，非必填}}

4、微信群
_URL_?utm_source=weixin&utm_medium=qun&utm_campaign={{推广主题，比如 teacherday}}&utm_content={{群名称或投放日期，非必填}}

5、微信公众号文章
_URL_?utm_source=weixin&utm_medium=article&utm_campaign={{推广主题，比如 teacherday}}&utm_content={{公众号名称或投放日期，非必填}}

6、微博
_URL_?utm_source=weibo&utm_medium=article&utm_campaign={{推广主题，比如 teacherday}}&utm_content={{微博名称或投放日期，非必填}}

7、今日头条（文章）
_URL_?utm_source=toutiao&utm_medium=article&utm_campaign={{推广主题，比如 teacherday}}&utm_content={{公众号名称或明细，非必填，比如投放日期}}

参考资料

自定义广告系列 – Google Analytics（分析）帮助
Google 官方提供的 UTM 构建工具
Google Analytics Campaign Tracking Pt. 0: An Overview
Google Analytics Campaign Tracking Pt. 1: Link Tagging
Google Analytics Campaign Tracking Pt. 2: The EpikOne Link Tagging Tool
Google Analytics Campaign Tracking Pt. 3: Reports and Analysis

劈天盖地的各种数据需求飞来，没有一个像样的系统该如何是好？这时候 CRM 就运用而生了，以上就是 CRM 存在的意义。

CRM 能解决的核心问题

1、销售各个环节数据清晰化； 2、将销售人员的工作流程化； 3、反向指导前端的渠道投放； 4、生成各个纬度的数据报表。

CRM 中的流程环节

一个完整的、高 ARPPU 值的电销行业中，完成的流程大致分成如下：

渠道投放

这是流程中最前端的环节，所有销售线索的入口，所以也是重中之重，市面上常见投放有下面几种： a）百度 SEM 投放； b）站内的首页轮播图； c）通过 QQ 群分享； d）通过微信群、微信朋友圈和微信公众号文章分享。

那么问题来了，累计来了 100 个新线索，那具体每个渠道来了多少呢？因为会分渠道合算投放成本，比如说百度 SEM 来了 10 个线索，最终付款 1 人；站内轮播图来了 8 个线索，最终付款 2 人，那个渠道优质？当然是站内轮播图。那上面的 4 个数字分别怎么来的呢？具体的实现细节我们在该系列的接下来的篇章里进行剖析，主要是通过「UTM」进行渠道投放。

访问落地页

在百度 SEM 看到广告，点击进去：

打开的落地页，浏览器地址栏显示的完整链接形如（下面链接并不是上图对应的链接）：

http://j.jikexueyuan.com/train/web?utm_source=baidu&utm_medium=cpc&utm_campaign=web%2B%E5%9F%B9%E8%AE%AD&utm_term=web%E5%89%8D%E7%AB%AF%E5%9F%B9%E8%AE%AD&utm_content=%E5%89%8D%E7%AB%AF%E5%9F%B9%E8%AE%AD

怎么会这么复杂的链接呢？其实上面的链接和「 http://j.jikexueyuan.com/train/web 」展示的页面是一模一样，后面的长串是渠道来源的跟踪之用。这样就完成了从渠道投放环节进入到「访问落地页」环节了。

在该环节会记录以下数据： a）访问落地页的完整 URL，做跟踪之用； b）页面的 PV、UV

创建线索

访问落地页之后用户的走向如何呢？一般高 ARPPU 值自主下单的概率基本为 0，需要客服进行人工干涉，最主要的走向就是将进入的用户导向「在线咨询」，一般有几种处理方式： a）进入落地页之后立刻或十几秒之后弹出在线咨询框； b）在页面的显著的位置摆放触发按钮，用户点击之后弹出在线咨询框。其中，第一种咱绝大多数。

在咨询的过程中客服最核心的工作就是「获取客户手机号」，所有的交流都是围绕这个目的展开的。

下面以在线咨询软件「乐语」为例，在乐语上创建名片之后，点击「同步到 CRM」，会将名片信息写入到商户自己的 CRM 之中，并且会将「访问落地页」中那一长串的 URL 作为线索原始来源存入进去，后面会具体写篇文章来说明「如何通过乐语同步名片到 CRM」。

电话回访

线索进入 CRM 之后，按照销售部门的内部规定进行线索的分配，比如说所有百度 SEM 来的线索平均分配给销售 A 组的人。销售拿到线索之后按照自己的优先级进行呼出，一般一次呼出就能成单的概率不大，需要反复的进行电话沟通和回访。

下单付款

电话沟通到客户有购买意向之后，客户会在线下单付款，也就是说当前客户被转化成功，对应的费用会被记入这个客户归属人的业绩之中。

CRM 中各式各样的数据报表

1、各个渠道线索的新增情况和费用支出情况（营销部门和老板相关）； 2、各个渠道线索的消化情况（销售部门相关）； 3、每个销售人员的工作量统计（销售部门相关）； 4、签约统计（销售部门相关）； 5、每个渠道的获客成本（营销部门和老板相关）。

具体的数据报表数据的来源就不在此展开了，后面有时间在慢慢写。

总结

这篇文章的目的是理清 CRM 的各个环节，并且每个环节需要关注的事情，每个环节具体的展开后面文章会陆续更新。

按照接收群体的数量可以分为两类，单播和组播。

单播

发给单个的人，使用场景形如：张三购买一个商品，在付款的时刻微信通知他「付款成功」。这类场景产品实现起来相对比较简单，只需要通过账户的用户名找到绑定的微信号，场景触发之时发送消息即可，就不做过多地阐述。

组播

批量发给多个人，使用场景形如：问答区新增一个问题，微信通知给所有的老师。组播的流程相对于单播要复杂很多，需要解决如下几个问题：
1）如何新增订阅者；
2）如何只给指定组发消息。

上面的流程图是订阅者的生命周期，主要分成如下几步：

第一步：生成带参数的二维码

生成微信二维码的时候加入一个参数「渠道来源」，官方文档如下：
https://mp.weixin.qq.com/wiki?t=resource/res_main&id=mp1443433542

第二步：扫描带参数的二维码

用户扫码二维码，回调的时候程序做如下处理：给该用户打上指定的标签，比如「老师」。

第三步：给组发消息

当场景被触发时，给「老师」组群发消息。

-> 微信公众号原文地址

Vincent 4J，真名张庆普（个人主页：http://4jplus.com）。eoe上海同城会组委，《Android开发入门与实践（第二版）》作者之一，两年Android开发经验，技术负责人，负责各大银行Android客户端的研发工作。4J是一个典型的IT男，喜欢参加各种行业聚会，并且有自己独特的“喜好”：背包旅行。随着《Android开发入门与实践（第二版）》的上市，eoe也专门对他进行了独家专访，为大家揭秘一名Android小白如何在eoe社区成长为大牛并参与写书的全过程。以下为专访正文：

eoe：4J，你好，谢谢你抽空来接受eoe的专访，简单向大家介绍下自己和目前的工作吧。

4J：先说说我的从业经历：我是09年毕业，出来首先做了2年J2EE；从2010年6月正式从事Android开发，一直持续到现在；对Android还是有很深的情怀。

也是由先前的Android菜鸟一步步摸爬滚打着过来，一步步的成长起来；现在所在公司主要为银行服务，我负责各大银行的Android客户端的研发工作，并担任Android小组负责人的角色。

其次在说说我的生活：Google重度使用者，微博控；热衷线下活动，喜欢折腾，酷爱背包旅行；喜欢且唯一喜欢的体育运动为乒乓球，一直惦记着eoe大本营的乒乓球台。

eoe：当初是怎样接触Android的，为什么没有选择iOS或黑莓等平台？会不会考虑WP8、BB10或最新的Tizen平台呢？

4J：机缘巧合，主要受我同学的影响；在他的洗脑和帮助下由J2EE转向Android。还有一个重要原因就是，Android开发使用Java语言，从J2EE过度还算平滑。

不会去考虑WP8、BB10和Tizen平台，倒是对iOS平台有很大兴趣。

eoe：你之前有一份Android开发工作是服务日本企业。在服务日本企业的过程中与本土企业有哪些不同？需求沟通上是否存在理解上的差异？给大家分享一下服务日企的优势和不足吧，咱们eoe好多开发者还没服务过外企呢。

4J：在日企最能学到的就是软件开发的流程：需求分析、类图设计、时序图设计、编码、测试、Team Leader Review，按照一整套的开发流程执行。而本土企业过于强调速成，忽略掉一些开发细节，为后期项目维护带来些许困难。

日企分工明确，有专门的需求人员与总公司进行沟通，开发人员一般不会涉及。

就如我前面所述，最大的优势就是完全遵守软件开发流程，一个阶段一个阶段地执行；同时也会因为分工明确带来的不足，个人所能涉及到的知识点有些狭窄。

eoe：你现在已经是名副其实的大牛了，光是工作上的积累是远远不够的。你平时通过哪些渠道和方式不断学习，积累技术和经验促使自己成长的？这当中有什么诀窍吗？

4J：先说说技术方面，主要2点：

其一：多动手，只有在实际编码中一堆疑难问题才能显现；随后寻找解决方案，并通过Evernote或GitHub记录总结。

其二，通过阅读书籍，系统的深入学习Android知识；例如，面向初级开发者，eoe社区出版的《Android开发入门与实践（第二版）》；中级开发者，罗升阳著的《Android系统源代码情景分析》就是不错的选择。

再说说非技术方面，要想丰富个人的视角，最直接的来源依旧还是阅读，我的阅读获取途径主要有以下几种：Google Reader、《彭博商业周刊》、《第一财经杂志》、微信朋友圈，并将好的文章通过IFTTT自动收藏到Tumblr。

eoe：eoe上海同城会是最活跃的同城会组织，至今已经举办了六届。你身为eoe上海同城会的组委，觉得做组委组织活动与做技术有什么区别和联系？做组委的过程中有没有收获？给大家分享分享吧。

4J：技术自我专研即可，活动是得大家一起参与进来；组织活动会涉及到一系列需要关注的事：活动推广、邀请嘉宾、确定话题、场地交涉、会场气氛、会后总结；细节到观察每个人的表情，进而得知是否对嘉宾的演讲感兴趣，下一届选何主题能更吸引人等等。

期间，收获颇多；最重要一点就是能通过eoe同城会这个平台认识更多的线下朋友；同时，也能增加自己的曝光率，被更多的人所认识。

eoe：《Android开发入门与实践（第二版）》新书已经上市，你写了环境搭建、Android SDK介绍、Hello eoe和图书信息查询这四个章节。当初是怎样参与进来的？

4J：自己当初Android入门时，就是以该书为蓝本；该书逐步深入，从环境安装、SDK介绍、架构分析、四大组件，以及应用实例；系统的对Android基础知识进行讲述，并以实例进行知识点汇总。不管是从章节布局、还是从内容深度方面来说，该书都是Android入门者的不二选择。

当IceskYsl 在eoeAndroid 发作者召集帖时，仔细阅读需知；在自身条件完全符合的情况下，抱着激动的心情、毫不犹豫的邮件报名。在经过层层筛选之后，最终有幸成为其中一员；在此，谢谢 IceskYsl 能给我这次机会，谢谢 IceskYsl 的信任。

eoe：在写作《Android开发入门与实践（第二版）》相关章节的过程中，遇到过哪些问题，又都是怎样解决的呢？

4J：在理论知识方面的问题到不是太多，因为毕竟该书面向的是初级入门者。但由于作者团队位于不同城市，在远程协作方面到碰到不少问题，例如：格式统一、资源共享、文章审核等等。好就好在 IceskYsl 在这方面有丰富的经验，给出各种近乎完美的解决方案。

借此机会爆料，GitHub用于书籍撰写的远程协作是个完美的解决方案，我们的下一本书籍正在它之上秘密进行着。

eoe：eoe其实有很多活动，但是不少对社区不熟悉的开发者还不能快速发现自己感兴趣的活动。你身为资深eoer，给大家分享一下如何在eoe找到感兴趣的活动并参与。如果是Android初学者又应该从哪些方面来关注？

4J：eoe目前线下活动主要有 eoe同城会、eoe移动开放日、eoe移动开发者大会；其中同城会为每月组织一次，上海、北京、深圳、杭州、武汉等5个城市先后成立，其中上海起着同城会旗舰之作用。

如果想第一时间了解eoe动向，请大家关注 eoe官方微博，如果想关注当地 eoe 最新动向，请关注当地同城会官方博客和官方微博。

eoe：看到你的个人介绍上说自己是“背包客”，身为一个程序员背包客，在旅行的途中有着怎样独特的感悟？

4J：背包追求的是心境——放下生活的琐事，独自一人背包在路上；离开城市的喧嚣，张开双臂大声咆哮，接受大自然的洗礼，展现最真实的自我；没有职场的勾心斗角，没有现实的生活压力，完完全全地自我释放。没错，这就是“背包”带给我的快乐；我深爱着她，情人般的爱恋。

一、前序

在「个人中心」需要有一个设置是否接收消息的设置项，用户主动接收消息。

二、架构

三、流程

我们当前的流程有些取巧，原本应该是消费者发消息之前就去请求「用户消息设置」，用户设置成接收，才去产生消息的。而我们现在的流程中消费者不去关注用户设置，把所有消息都往「队列」里塞，让主流程去做过滤处理，这样各个生产者就不用每个都去单独处理，同时也少了一次网络交互。

四、后台

需求

我们在这次改版中的需求其实很简单，针对「首页」进行 A/B：
1、对终端用户来说，首页 URL 得唯一：www.jikexueyuan.com；
2、随机分配 A 或 B。

实现方案

实现细节中最难的就是同一用户不同设备访问，我们最终选择了 UID 优先的方案。

1、未登录
第一次访问，会随机出方案 A 或 B，然后将值存入「cookies」；
下次再来，只要 cookies 里有值，就直接显示原来的方案 A 或 B。

2、登录
登录之后，将 UID 和方案绑定，以后无论在那个终端上登录之后都是对应方案。

总结

现在想想，我们这次好像不是理论意义上的 A/B，因为 A/B 需要将变量控制在单一元素，进一步通过数据表现出好与不好，最终选定方案，下线不好的方案；而我们这次的首页完完全全就是两个单独的页面，没有一点类似的元素。

1、优势
a）不用服务器端存储，节省很多的开发成本；
b）用户无感。

2、弊端
a）不同终端未登录时分配的方案可能不一样；
b）登录之后与未登录可能分配的方案不一样。

A 方案

B 方案