-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
597 lines (325 loc) · 31.5 KB
/
index.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
<!DOCTYPE HTML>
<html>
<head>
<meta charset="utf-8">
<title>rguo</title>
<meta name="author" content="郭若斌">
<meta name="description" content="郭若斌关于产品经理、数据分析的思考。">
<meta name="keywords" content="产品经理,产品设计,数据分析">
<meta name="viewport" content="width=device-width, initial-scale=1, maximum-scale=1">
<link href="/atom.xml" rel="alternate" title="rguo" type="application/atom+xml">
<link rel="canonical" href="">
<link href="/favicon.png" rel="shortcut icon">
<link href="/stylesheets/screen.css" media="screen, projection" rel="stylesheet" type="text/css">
<!--[if lt IE 9]><script src="//html5shiv.googlecode.com/svn/trunk/html5.js"></script><![endif]-->
<script async="true" src="//ajax.googleapis.com/ajax/libs/jquery/1.7.2/jquery.min.js"></script>
</head>
<body>
<header id="header" class="inner"><h1><a href="/">rguo</a></h1>
<nav id="main-nav"><ul class="main">
<li><a href="/">Home</a></li>
<li><a href="/blog/archives">Archives</a></li>
</ul>
</nav>
<nav id="mobile-nav">
<div class="alignleft menu">
<a class="button">Menu</a>
<div class="container"><ul class="main">
<li><a href="/">Home</a></li>
<li><a href="/blog/archives">Archives</a></li>
</ul>
</div>
</div>
<!-- <div class="alignright search">
<a class="button"></a>
<div class="container">
<form action="https://blog.guorob.in" method="get">
<input type="text" name="q" results="0">
<input type="hidden" name="q" value="site:blog.guorob.in">
</form>
</div>
</div> -->
</nav>
<nav id="sub-nav" class="alignright">
<div class="social">
<a class="rss" href="/atom.xml" title="RSS">RSS</a>
</div>
<!-- <form class="search" action="https://blog.guorob.in" method="get">
<input class="alignright" type="text" name="q" results="0">
<input type="hidden" name="q" value="site:blog.guorob.in">
</form>
--></nav>
</header>
<div id="content" class="inner">
<article class="post">
<h2 class="title">
<a href="/blog/2014/09/15/du-can-yu-gan/">
读《参与感》</a>
</h2>
<div class="entry-content">
<p>由于身边的同事在读以及多看书城上的持续推荐，终于还是买了并且读了《参与感》这本书。这本已开始并不抱太高希望的“小米口碑营销内部手册”读完之后竟让我感到了一点点惊喜。这里不涉及书中太多的内容，主要谈谈我自己的思考。</p>
<h2>小米是怎么成功的</h2>
<p>在阅读过程中，第一个让我感到好奇的问题是小米是如何成为一家现象级的公司的。窃以为如下。</p>
<h3>第一，在恰当的时机进入一个恰当的领域</h3>
<p>就像雷军自己说的，台风来的时候，站在风口的猪也会飞。在小米成立的2010年，移动互联网方兴未艾。我相信，当时很少有人能够准确地预测移动互联网在随后几年的发展速度，并且找到适合于移动的应用场景和商业模式。今天，我们看到了微信成长为移动端的超级应用，以滴滴打车为代表的实时交易撮合应用，移动的应用场景对于以美团为代表的本地生活应用的促进，阿里和腾讯争夺的移动支付领域这些具有极强移动属性的例子。但回到2010年，无论如何，进入移动操作系统和移动终端领域在应该是不会错的一着棋，此后MIUI和小米手机的成功证明了这一点。</p>
<h3>第二，钱</h3>
<p>《参与感》书中也提到，小米创办之初就拿到了很多很多的钱。看看小米的融资记录吧：2010年底，小米完成4100万美元的融资，估值2.5亿美元；2011年底，小米完成9000万美元融资，估值10亿美元；2012年6月底，小米再次完成2.16亿美元融资，估值达到40亿美元。2013年还有一笔估值为100亿美元的融资。同样是做手机的锤子，A轮7000万人民币，B轮1.8亿人民币，差距可见一斑。</p>
<h3>第三，执行</h3>
<p>其实我原本只想到前两条，战略方向正确，手里又有钱，事情怎么着也应该八九不离十了吧。但脑子里突然蹦出一个反例——凡客诚品。凡客有互联网快时尚的定位，也融到了大笔的钱，但红极一时之后，现在也是江河日下。由此推导出，除了做对的事情和有钱之外，执行力是成功的第三要素且小米的执行力是出众的。而《参与感》这本书简直是小米在产品、设计、服务、营销各个执行层面的“操作手册”。也许这本书不如张小龙的PPT有深度，也许书里总结的一些概念让人觉得假大空，但无论如何，这是一本带着成功经验的书。从这个角度看，他的价值是不应该被低估的。</p>
<h2>互联网思维</h2>
<p>这是个最近特别火的词。我理解的互联网思维中一个组成部分是企业与用户之间的关系。对于传统企业而言，企业与用户（确切地说是消费者）之间的关系是基本是单向的，企业生产产品或者提供服务，并且通过广告把品牌灌输进消费者的心智，信息主要是企业向用户这个方向传递，反向的信息传递主要是用户的购买，少量的退货或者投诉。而互联网企业与用户之间的关系更注重用户向企业的信息传递，以及用户之间的信息传递。比如：用户爱看什么样的新闻，用户更多地搜索哪些关键词，用户与好友之间的交互。</p>
<p>举个例子，一个前阿里产品经理“刘百万”在海尔创业平台上做了个智能烤箱的项目。其中有一个点是“菜谱可复制”，主要解决的是买了烤箱的用户不会烤这个问题。或许在这个烤箱配套的App上有个大厨排行榜，里面有大厨们分享的菜谱。其他的用户则可以使用这些菜谱，也可以对菜谱点赞。厂商或许还能设置点奖品时不时地搞些厨艺大赛之类的。更疯狂点，可以把它变成一个游戏，里头一堆烤各种食物的任务，勋章，等级等等。总而言之，我认为这是一台包含互联网思维的烤箱，而不仅仅是一台具备烘烤功能的设备。</p>
<p>最终，互联网企业获得的是用户黏性，也许翻译成传统语汇，就是忠诚度吧。随着信息地愈发的膨胀，注意力的逐渐稀缺，特别在移动互联网时代，用户使用场景的碎片化，用户黏性变得越来越重要。在PC互联网时代的流量分发模式中，也许能够获取一定的流量也能造就一家不错的企业。那么在移动互联网时代，只有真正能与用户进行沟通的企业才能获得成功。小米就是这样的企业，产品设计、营销活动、线下的体验店，处处都强调用户的参与感。我觉得这其实是小米在执行层面的成功的一个侧面体现。</p>
<h2>正确的废话</h2>
<p>一开始，我对于这本书的判断是一本充满了“正确的废话”的书，以前我对这种书都不太感冒的。确实这本书里多是一些案例，可能所谓的干货并不是特别多。但是读完之后，发现书里的内容还是能够激发思考的，这不禁让我改变了对这一类书的看法。毕竟，真的抛出一堆干货在你面前，也未必能领悟。正确的废话也好，干货也罢，读出多少自己的东西才是最重要的。</p>
</div>
<div class="meta">
<div class="date">
<time datetime="2014-09-15T22:18:20+08:00" pubdate data-updated="true">Sep 15<span>th</span>, 2014</time></div>
<div class="tags">
</div>
<div class="comments"><a href="/blog/2014/09/15/du-can-yu-gan/#comments">Comments</a></div>
</div>
</article>
<article class="post">
<h2 class="title">
<a href="/blog/2014/08/26/ru-he-zuo-hao-yong-hu-yao-qing/">
如何做好用户邀请</a>
</h2>
<div class="entry-content">
</div>
<div class="meta">
<div class="date">
<time datetime="2014-08-26T19:49:58+08:00" pubdate data-updated="true">Aug 26<span>th</span>, 2014</time></div>
<div class="tags">
</div>
<div class="comments"><a href="/blog/2014/08/26/ru-he-zuo-hao-yong-hu-yao-qing/#comments">Comments</a></div>
</div>
</article>
<article class="post">
<h2 class="title">
<a href="/blog/2014/08/08/guan-yu-mei-tuan-jiu-dian-fang-tai-yu-yue/">
关于美团酒店房态预约</a>
</h2>
<div class="entry-content">
<h3>数据监控</h3>
<ul>
<li><strong>转化率对比</strong>
<ul>
<li>目的：了解房态预约对转化率的影响，虽然这个功能提高转化率的概率很高，但是仍然值得AB测试，作为经验积累下来。</li>
</ul>
</li>
<li><strong>酒店端数据</strong>
<ul>
<li>目的：
<ul>
<li>关注房态预约业务推进的情况，结合酒店团购和酒店快订的整体数据，了解房态预约对于整体业务的影响</li>
<li>监控酒店使用上的一些特征，发现酒店使用中的问题</li>
<li>监控服务质量</li>
<li>衡量房态预约功能对于酒店的好处</li>
</ul>
</li>
<li>主要指标：
<ul>
<li>开通房态预约的酒店数量及占所有酒店的比例</li>
<li>维护房态的酒店数量及占开通房态预约的酒店的比例</li>
<li>维护不同天数房态的酒店占比以及房态更新频率</li>
<li>维护房态的酒店的关房率</li>
<li>在线预约的响应比例</li>
<li>在线预约的处理时长</li>
<li>在线预约的成功率</li>
<li>有房态预约酒店与所有酒店的销量增长率对比</li>
<li>有房态预约酒店与所有酒店的退款率对比</li>
</ul>
</li>
</ul>
</li>
<li><strong>用户端数据</strong>
<ul>
<li>目的：
<ul>
<li>了解用户对此功能的感知</li>
<li>衡量房态预约功能对于用户决策的影响</li>
<li>了解用户的实际体验情况</li>
</ul>
</li>
<li>主要指标：
<ul>
<li>Web端筛选“可看房态”的用户比例及转化率</li>
<li>可在线预约的订单中实际发生在线预约的比例</li>
<li>取消预约的比例</li>
<li>到店无房的比例</li>
<li>从点评和微博中看用户关于房态预约的问题</li>
</ul>
</li>
</ul>
</li>
</ul>
<p>具体分析的时候可能需要结合各个纬度来细分，比如城市、Booking Window等等。</p>
<h3>发展方向</h3>
<p>从OTA的视角来看，酒店团购特征是降低服务质量（客人直接打电话给酒店预约，OTA不投入人力进行运营性的工作）以及降低价格（由于降低了运营成本，可以收取酒店更低的佣金）。从酒店的角度来看，团购是一个有限制的渠道（有有效期的限制，并且在入住率高的时候可以不接待团购客人），通过低价可以提高入住率。问题是对于客人的而言虽然享受了低价，但体验上有缺陷。</p>
<p>房态预约功能的目的是提升客人的体验，形态上是介于传统意义上的酒店团购和预付酒店的一种中间形态。实际上用户从用户开始预约之后，这个团购订单已经和OTA模式的预付订单没有差异，只不过客人的心理预期上仍然停留在团购的层面而已。所以，房态预约对于客人而言，体验上会优于传统团购，但由于美团并没有投入运营力量来确保服务质量，其服务质量未必能达到OTA的预付模式。</p>
<p>到此得出的结论是如果试图找到最优解，那么必然涉及到OTA模式的所有问题（因为其实本质上就是把团购变成了预付）。这个对美团而言的最优解目前看来是酒店采用直连的方式接入，短期内这个最优解很难实现。</p>
<p>寻求次优解的约束条件是美团不需要投入运营成本，目标是提高酒店的服务质量。可能的办法有：</p>
<ol>
<li>通过给予酒店更多的曝光来刺激酒店开通房态预约服务。方式包括但不限于排序，所有能提供曝光的方式都可以考虑，比如客户端的每日推荐，在Web端运营一些促销位等等。</li>
<li>将酒店的服务质量数据化的提供给客人，作为决策依据来促使提高服务质量。比如，预约确认时长，预约成功率，投诉等指标，同时这些指标也可以运用到排序。</li>
<li>使用预约成功率的数据对酒店的房态信息做补充说明。例如，某一天的某个产品，5人预约成功，1人预约失败，这个信息也可以提供给客人做决策依据。</li>
<li>在酒店端促进酒店更好的维护房态信息。比如，考虑增加库存的概念，增加符合条件下即使确认的功能等。</li>
</ol>
<p>其他的细节上的优化不赘述，比如：18:00之后到店的特殊需求，突出“可看房态”等页面上的交互优化等。</p>
<p>谨此。</p>
</div>
<div class="meta">
<div class="date">
<time datetime="2014-08-08T11:05:23+08:00" pubdate data-updated="true">Aug 8<span>th</span>, 2014</time></div>
<div class="tags">
</div>
<div class="comments"><a href="/blog/2014/08/08/guan-yu-mei-tuan-jiu-dian-fang-tai-yu-yue/#comments">Comments</a></div>
</div>
</article>
<article class="post">
<h2 class="title">
<a href="/blog/2014/08/04/wei-bo-sou-suo/">
关于微博搜索</a>
</h2>
<div class="entry-content">
<p>新浪微博搜素的根本优势还是来源于微博这个平台，在新浪微博上，每时每刻都有大量的内容产生，在移动互联网时代，其中大量的信息是<strong>实时的</strong>以及<strong>地理位置相关的</strong>。此外，大量的第三方应用都有分享到微博的功能，加之微博本身的传播特性，微博某种程度上改变了传统互联网上信息的流动方式。举个例子：5年前，我写了一篇博客，除了直接访问的流量之外，主要的流量来源可能是SEO，也就是说信息主要通过通用搜索引擎得到整理和传播。而今天，我同样写了一篇博客，可以把博客的链接分享到微博上，也许更多的人是通过微博看到我的博客的。</p>
<p>所以，微博搜索的主要优点有以下几点：</p>
<ol>
<li><strong>实时搜索</strong>。这个可以有很多应用场景，我个人亲身经历，印象最深刻的一次经历是2009年F1车手马萨在比赛中被赛道上的杂物击中头盔，身受重伤。当时不停地在twitter（好吧。。。印象中那个时候还没有新浪微博）上搜索关于马萨的消息。此外，出游时查询查询路况，查询机场飞机延误情况等等也是我自己经常使用的场景。实时性在我看来是微博搜索最大的优势，就不在赘述了。</li>
<li><strong>全面性</strong>。目前微博UGC内容的搜索已经比较全面了，这些内容传统搜索引擎并不能很好地满足，也催生出搜八卦、人肉搜索、PM搜索用户反馈等等用户场景。而用户从其他站点分享越多的内容到微博上，也会使得微博搜素能够搜索到越多内容。</li>
<li><strong>社会化</strong>。微博上大量的内容使用户产生的，用户分享的内容是经过用户选择的，点赞、评论和转发是用户对于信息的反馈。微博上的人关注的对象，粉丝数量，又代表着这个人的“社会价值”。以上这些人的因素，在微博搜索中直接的体现是对结果排序的影响。</li>
</ol>
<p>我个人觉得，微博搜索目前主要的问题是去重和排序。可能的做法有以下几点：</p>
<ol>
<li><p><strong>降噪</strong>。这个噪音有多种情况，包括：重复的微博（直接copy别的微博来自己发的），转发但是没有什么营养的微博（转发的时候没有自己的内容，或者“呵呵”的），其他应用分享的微博（快来下载xxx App之类的）。</p></li>
<li><p>形成一个科学的<strong>微博质量评估</strong>体系。简单点的例子，一条字数很少的微博（比如<10个字）和一条100个字的微博，是不是可能100个字的微博的质量更高一些。也许不一定，但是这里应该有一个评估的机制。另一个的例子，带短链的微博的质量如何评估，是不是应该抓取链接中的正文内容来评估呢（其实召回也是一个问题，是不是应该把在链接指向的内容中包含Query关键词时也召回呢）。当然，还有长微博，和短链同样的问题。此外，可能还涉及反作弊机制，比如恶意添加热门标签的情况。</p></li>
<li><p>持续提升<strong>相关度</strong>。对于微博而言，个性化的引入可能比通用搜索引擎更加具备条件。比如，我做竞品分析的时候搜索“去哪儿 酒店”时，其实不想看爸爸去哪儿这个节目的微博，而只是想看关于去哪儿网酒店的微博。这个从我个人的描述，我关注的人，关注我的人，以及我前几次的搜索中也许是可以推断出来的。</p></li>
</ol>
<p>这些是单纯从搜索系统本身的角度出发所做的考虑，纯属主观臆断，考虑的也仅仅是微博的内容搜索。以上。</p>
</div>
<div class="meta">
<div class="date">
<time datetime="2014-08-04T01:17:37+08:00" pubdate data-updated="true">Aug 4<span>th</span>, 2014</time></div>
<div class="tags">
</div>
<div class="comments"><a href="/blog/2014/08/04/wei-bo-sou-suo/#comments">Comments</a></div>
</div>
</article>
<article class="post">
<h2 class="title">
<a href="/blog/2014/07/28/er-shou-xian-zhi-wang-shang-mai/">
二手闲置网上卖</a>
</h2>
<div class="entry-content">
<p>最近看到淘宝二手交易改名“闲鱼”，并且重磅推出了新版移动客户端。好奇心使然，我自己简单地对目前网上二手交易作了一点了解。</p>
<p>先谈谈这个市场。我的感觉是，往大里说，人类社会的发展，“可持续”是很重要的。全球每年产生以亿吨计的电子垃圾，中国大概一年会产生几千亿件待清理的服装库存。。。凡此种种。我不懂经济学，只是觉得浪费无论如何也是件可耻的事情吧，资源总是能够更合理的配置的。我们能的选择并不只是如今天的商品社会鼓励人们不停够买，另一边却大量生产出来人们并不真正需要的产品。今天，互联网正在创造另一种充裕，信息的充裕理应使得“共享”更多的成为可能，使大家实际上更加富有。二手闲置的交易理应是一个很大的市场。</p>
<p>再来看<a href="http://www.zhihu.com/question/24423133/answer/28063880" target="_blank">知乎上的这个回答</a>，内容是“闲鱼”产品经理阿鬼的文章，虽然“淘宝”、“宝贝”这些字眼的内涵和“淘宝用户交易的是故事和心情”这种情怀我还是不太懂的，但是看得出来在这个产品的设计上也是煞费了一番苦心的。</p>
<p>起初，我认为二手交易的痛点主要是信任关系的建立，卖家怎么能够确定买到的二手宝贝是靠谱的呢，对于一些非标准化的产品，价格是另一个大问题，买完了之后发现花的钱其实可以买全新的是多么令人郁闷的事情。利用朋友之间的关系进行二手闲置交易似乎是一个顺理成章的想法，但是如阿鬼文末提到的人们可能不太愿意买熟人的衣服，因为“很难穿出来”。其实，问题的关键不在于一件衣服是不是能穿出来，某些东西很自然地不适合在朋友间交易（比如你送给朋友的生日礼物），但我觉得这种情况只在少数。真正的问题是，朋友间而是仅仅以朋友作为潜在的买家，受众太少，交易可能很难完成。所以，在利用好友关系解决基础信任问题以及促成交易之间要达到平衡或者说和谐。另一个闲置交易平台“有闲”的做法让卖家激励自己朋友转发闲置物品信息，使得更多的交易在卖家和他的朋友的朋友关系中完成。看起来是个有意思的想法，实际上，卖家的朋友成了第三方担保，似乎是信任和交易范围的平衡。类似的，58同城也可以通过导入微信的关系链，让你看到一个物品是朋友或者朋友的朋友发布的，来增强信任（发现58同城已经有了微信注册，两边的用户打通应该只是时间问题吧）。况且，闲鱼上的卖家也可以把发布的宝贝分享到微信在好友间传播（虽然微信仍然会屏蔽掉分享过去宝贝链接，这点，还真是挺佩服闲鱼的产品经理的）。</p>
<p>进一步思考，除了信任之外，卖家如何快速发布信息（闲鱼的一键转卖），如何做供求关系的匹配（阿鬼文中提到，也许是某型形态的C2B？），物流的问题（有闲在尝试线下寄存代售模式），交易流程安全的问题（闲鱼可以通过支付宝支付，流程和淘宝几乎是一样的；也许58同城将来微信支付也能实现类似的效果?）也是诸多痛点。问题很多，无法深入，到此为止吧。</p>
<p>最后，似乎还有没有考虑二手回收商在这个环境中的位置呢，呵呵。</p>
</div>
<div class="meta">
<div class="date">
<time datetime="2014-07-28T22:44:54+08:00" pubdate data-updated="true">Jul 28<span>th</span>, 2014</time></div>
<div class="tags">
</div>
<div class="comments"><a href="/blog/2014/07/28/er-shou-xian-zhi-wang-shang-mai/#comments">Comments</a></div>
</div>
</article>
<article class="post">
<h2 class="title">
<a href="/blog/2014/07/21/chan-pin-jing-li-de-shu-ju-fen-xi-neng-li/">
产品经理的数据分析能力</a>
</h2>
<div class="entry-content">
<p>刚做完给新入职的产品新人关于数据分析的培训，培训的内容主要是一些分析工具的使用上，目的是为了让这些新人能够尽快的开始看一些产品相关的数据。</p>
<p>回忆起这些年自己的工作经历，始终在数据路线上游走。第一份工作是Business Objects的产品研发，Business Objects是一款BI前端分析工具。作为BI分析工具的研发人员，其实是不需要懂得什么BI应用方面的东西的。接着，做了Business Objects的实施顾问，这个逐渐开始接触到一些用户实际的数据需求，但仍然是停留在工具如何使用的层面给与客户支持。再后来，进入互联网企业的BI部门，密集地接触各种需求，也实际地融入了业务场景，可依然是隔靴搔痒。直到近两年，开始自己作为业务人员和产品经理分析自己的数据。可以说，是完整地走完了整个从技术到业务的进化历程。经历了这个过程，现在的感觉是工具的使用虽然是必不可少的“硬技能”，但是其他的一些“软技能”显得更为重要。</p>
<p>以我现在所处的互联网产品经理的角度来看，下面这些点就是所谓的这些“软技能”。</p>
<h3>要有数据驱动的意识</h3>
<p>没有数据驱动的意识，就是拍脑袋。脑袋可以拍，有时必须拍，但是万事拍脑袋，显然不靠谱。在我看来，产品的工作可以分为两类，一类是基于数据分析的结果进行的产品优化，这一类自然是数据驱动的。比如搜索产品，从日志中发现bad case，不断地优化搜索逻辑就是一个例子。另一类是基于产品经理直觉和洞察发现的产品机会，这些产品创意虽然不是来源于数据，但是还是得用量化的方法来衡量其成功与否。</p>
<p>所以作为产品经理，必须有看数据的习惯，并且对数据有起码的敏感度。这样，日常看数据的过程可能就能发现一些优化点，之后从数据的变化上来评估优化的效果。另一方面，在出现没有过往数据支撑的新想法的时候，要明确产品的目标和量化的衡量方法。这样即使拍脑袋，也是有章法的。</p>
<h3>明确数据分析的目的和量化标准</h3>
<p>在分析数据之前，首先非常清楚分析的目的和确定量化的标准。举两个工作中很普通的例子。</p>
<p>作为数据分析师，有产品经理对我说想看看“酒店周末订单的Booking Window（预定日和入住日相差的天数）分布”。先看这句话，似乎已经描述得很清楚了，但是实际操作的时候发现，这个“周末”指的是下单日的周末还是入住日的周末，还是离店日的周末，并没有明确。可见自然语言的表述充满了歧义，平时我们对话中看似已经足够明确的表达在翻译成数据语言的时候就显得含糊不清了。在深入下去想，产品经理为什么想要知道这个“周末订单的Booking Window分布”呢？进一步沟通发现，产品经理是想通过数据来决定一个促销周末入住产品的促销活动应该放在周中哪几天做。这样看来，是不是应该看入住日周末的订单按下单日的Day of Week分布更靠谱点呢？</p>
<p>另一个我自己做产品的例子。有个表单，想去掉其中的一个输入框，因为直觉上，大家都觉得这个用户输入这个框的概率比较低，放在哪儿反而容易引起用户的困惑和错误输入。当时没有数据支持，老大就问，如果看这个数据，输入那个框的用户的比例高于多少，你会决定不去掉这个框。当时我们就拍了一个10%的比例。这个例子想说明的是，在看数据之前，应该事先考虑一个量化的标准，通常是当数据不完全验证直觉时，要确定过了哪条线就应该放弃原来的想法。</p>
<h3>注意统计口径</h3>
<p>作为网站产品经理，经常会看访问量、订单量之类的数据。任何统计指标，都有各种各样的口径。访问量，是PV、visits还是UV，甚至是entry。订单量，是按下单日期看，还是入住日期，只看有效订单还是所有订单，要不要区分订单类型，要不要限制营销渠道。口径上的一点差别，往往会差之毫厘，谬以千里。说起来，这些都是细节，但实际工作中，设置完条件后数据往往需要“跑”一段时间才能出来，口径上的问题导致数据反复重跑，浪费大量的时间，让人心情沮丧。所以在“跑”数之前，要仔细检查设置的口径是否正确，磨刀不误砍柴工。</p>
<h3>验证数据的正确性</h3>
<p>再仔细的检查也难免失误，如果不能及时发现数据里的问题，错误的数据可能导致错误的决策。这个损失就不是产品经理的一点时间和工作效率的问题了。</p>
<p>根据以往的经验就可以大概判断一个数据有没有问题。比如一个营销渠道的订单量，以往每天都占25%左右，某天突然升高到40%，是不是很值得怀疑呢？通常不是这个营销渠道的投放策略有变化就是数据有问题。另外，数据之间往往是有关系的，发现流量和转化率都提升了，而订单量在下降，那一定其中至少一个数据有问题嘛。</p>
<p>看数据的时候，要时刻保持怀疑的态度。一旦对数据有疑问，要立即检查取数的过程有没有问题，是否有外部因素导致数据和经验值有较大差异，各个不同的数据之间的逻辑关系是否通。</p>
<p>以上，大概是我理解的产品经理需要具备的一些数据分析能力。数据分析并不能说是产品经理的核心工作，产品经理的大部分精力还是应该集中在产品的方向、规划、设计以及项目的推进上。保持一定的数据敏感度，有明确的分析目的，再加上一些方法保证较高的效率，对于产品经理而言就足够了。</p>
</div>
<div class="meta">
<div class="date">
<time datetime="2014-07-21T21:33:05+08:00" pubdate data-updated="true">Jul 21<span>st</span>, 2014</time></div>
<div class="tags">
</div>
<div class="comments"><a href="/blog/2014/07/21/chan-pin-jing-li-de-shu-ju-fen-xi-neng-li/#comments">Comments</a></div>
</div>
</article>
<article class="post">
<h2 class="title">
<a href="/blog/2014/07/11/wwdc-2014/">
WWDC 2014</a>
</h2>
<div class="entry-content">
<p>作为一个曾经的iOS如今的Android用户，看了WWDC 2014的Keynote之后居然又兴奋地想入手一台iPhone了。</p>
<p>我虽然一直不认为自己是果粉，但是购买过的苹果设备也不可谓不多了。之前也有半夜看苹果新产品发布会和跑去排队买首发新品的经验，但这次WWDC 2014的Keynote给我留下的影响极其深刻。也许以前更多的是作为普通用户，对新硬件、新软件、新服务看个新鲜。而现在，多少会从产品的设计、规划、策略角度考虑这些新事物。对此，略感欣慰。</p>
<p>Continuity自然是前半部分让人惊艳的主题。从此，Mac和iOS设备之间获得了跨平台的一致性体验。在Mac上打电话，在Mac上创建WiFi热点，在iOS设备上完成Mac尚未完成的操作（邮件、iWork、浏览器），虽说其他的服务或者第三方的工具也能实现，但是感觉苹果又把这件事情做到了极致。</p>
<p>iCloud Drive的策略是我一直很欣赏的。在开山鼻祖Dropbox获得了口碑和众多应用集成，Google Drive依靠自己的Docs的基础以及价格优势发力，以及各种各样的网盘应用铺天盖地的时候。iCloud的思路清晰可见，首先基于iOS平台解决用户痛点（主要是通讯录同步），然后扩展第三方应用的集成（也包括Mac和iOS系统的Keychain），最后才提供自由的文件同步功能。</p>
<p>Swift，HomeKit，HealthKit，CloudKit每一个都可以说是重量级的。其中HomeKit打通了智能家和iOS平台的连接，HealthKit意在获取更多个人的数据，CloudKit是苹果的云计算平台（感觉和iCloud的策略如出一辙，依靠自身的平台逐步拓展）。</p>
<p>当然，苹果的战略是否成功的关键还是iOS平台。这一点，要看今年秋天iPhone 6的了。</p>
</div>
<div class="meta">
<div class="date">
<time datetime="2014-07-11T17:58:10+08:00" pubdate data-updated="true">Jul 11<span>th</span>, 2014</time></div>
<div class="tags">
</div>
<div class="comments"><a href="/blog/2014/07/11/wwdc-2014/#comments">Comments</a></div>
</div>
</article>
<nav id="pagenavi">
<div class="center"><a href="/blog/archives">Blog Archives</a></div>
</nav>
</div>
<footer id="footer" class="inner">Copyright © 2014
郭若斌
<div style="display:none">
<script type="text/javascript">
var _bdhmProtocol = (("https:" == document.location.protocol) ? " https://" : " http://");
document.write(unescape("%3Cscript src='" + _bdhmProtocol + "hm.baidu.com/h.js%3Fa9c8b17c3f55dd0b07e13422c2e11202' type='text/javascript'%3E%3C/script%3E"));
</script>
</div>
</footer>
<script src="/javascripts/slash.js"></script>
<!-- <script src="/javascripts/jquery.fancybox.pack.js"></script>
<script type="text/javascript">
(function($){
$('.fancybox').fancybox();
})(jQuery);
</script> -->
<!-- Delete or comment this line to disable Fancybox -->
<!-- <script type="text/javascript">
var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-24797743-3']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;
ga.src = ('https:' == document.location.protocol ? 'https://ssl' : 'http://www') + '.google-analytics.com/ga.js';
var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(ga, s);
})();
</script>
-->
<script>
(function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
(i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
})(window,document,'script','//www.google-analytics.com/analytics.js','ga');
ga('create', 'UA-24797743-3', 'auto');
ga('send', 'pageview');
</script>
</body>
</html>