Posts for: #Startup

一段时间以来，我们在憋一个「大招」：知识星球的小程序第三方平台。

我们希望做到：知识星球的每一位星主，都可以有自己的专属小程序。比如 Fenng 的「小道消息和他的朋友们」，可以有一个专属小程序，没有星球列表，没有「知识星球」，就是纯粹的小道消息和他的朋友们。

做到最后，我们发现犯了个乌龙：

• 因为每个星主必须自己申请小程序，因此他的小程序的主体（不管公司还是个人）和知识星球的主体不一致；
• 不同主体，就得使用不同的 union id——也就导致虽然同样都是微信登录，但用户体系无法打通。

2017-07-28，caoz 在他的网课产品「易灵微课」里，做了一堂《产品经理入门 - 如何有效沟通》讲座，作为 caoz 的朋友兼三脚猫产品经理，自然去学习了。但最近「知识星球」自己遇到一堆事（直到现在 iOS 版都还没恢复上架），心境其实是乱的，没有认真学和整理。

这几天打算静下来，继续高效率地学习和工作，就从这里开始吧。

以下为 caoz 的讲课内容，我只做些许整理、润色。

—

很多公司对产品经理定义不同的，共性最大的两部分职责是：

1. 产品需求设计；
2. 研发沟通协调。

有争议的工作范畴主要是：

1. 产品需求之前的市场调研分析；
2. 产品上线后，后续的运营决策支持及反馈。

这个讲座只涉及研发的沟通协调，想解决的问题是：

1. 我提出了需求，研发也表示知道了，但做出来的东西为什么和我提出的不一样？
2. 我提出的是个很简单的需求，为什么研发说要做很长时间，甚至说不能做？
3. 我提出了需求，研发也做出来了，也顺利上线了，但运营中常存在奇怪的问题，经常出故障，或者想做一些运营调整，特别难。

我没有最终的解决方案，只是分享在这方面我的思考、尝试，以及我所遇到的一些典型问题的原因分析，希望对各位有兴趣从事产品经理职业的同学有帮助。列举的场景都是小公司、创业公司、新人产品经理所容易犯的错误，不一定适合大公司或者比较有经验的产品经理。

今天分五个话题

第一个话题是目标一致性原则。 第二个话题是产品文档规范。 第三个话题是测试与反馈。 第四个话题是需求边界。 第五个话题是产品人员需要了解的一些技术常识。

目标一致性原则

目标一致性是指：要确保研发和你对产品的理解（至少包括产品定义、用户目标、运营目标）有相对一致的认识。

有个隐含的前提是：你要确保你自己的认识和你的老板一致。

你可能知道，这个产品要做成什么样子，要有什么功能，要有什么角色，用户怎么用，但应该追问：这个产品真正的核心目标和产品价值是怎么定义的？如果你是跟随产品总监，或老板定义的项目，这个问题一定要事先搞清楚，否则很可能你把东西做出来，但在老板眼里，其实你完全不在状况。

搞清楚之后，要让研发也知道。初阶产品经理与研发沟通最容易犯的错误就是：我以为我知道的背景常识你也知道。

背景常识包括但不限于：这个产品的意义和价值是什么？这个产品的核心用户群是谁？这个产品的目标市场是什么？这个产品的运营特点是什么？这个产品的涵盖范围是什么？

研发如果了解不足，可能会产生的问题有：

1. 如果文档不规范，研发自由发挥余地很大，可能做出来的东西跟你想要的完全不是一回事；
2. 就算文档很规范，研发也都按文档实现了，存在一些认知问题，也可能导致：
   • 会基于自己对产品运营，产品目标的理解，做结构上或性能上的准备，比如说，大量时间用于无用功，这种事情特别特别特别常见。很多时候，你们发现研发效率很低，不是研发不干活，是把活干拧巴了。
   • 仅仅满足于功能实现，可能该做的准备没有做，导致性能考虑不足，运营支持度考虑不足。这也是特别特别特别常见的问题！怎么强调都不过分。

所以，在功能诉求之前，要让技术理解产品的真实目的、目标用户群、业务诉求、运营途径、推广途径等。对产品涵盖范围要有清晰的认识和了解。

在目标一致性的原则下，适当允许和鼓励技术参与产品讨论和功能规划。

因为今天我们强调的一个目标是什么呢，是研发效率，通过有效沟通提升研发效率，那么，在目标一致性的原则下，研发可能有更有效率的实现方式和解决途径，这时候，鼓励他们参与讨论，是非常有意义的。当然，最终决策权还在产品经理的手中。

此外，从沟通技巧来说，要求研发对产品目标进行确认。要求研发在一段时间内，一起回述目标，发现问题点。

回述目标是一个很有效的沟通方法，让对方按他的理解重述一下这个项目的背景和目标。这样就很容易发现双方理解上的歧义。我发现，很多情况下，对方表示完全明白了，但回述的时候，明显和自己的目标是有偏差的，或者对关键的一些要素明显疏漏了。

在目标确认和目标沟通的过程中，几个常见的误区如下

1. 过多考虑变通性和适应性，技术准备过剩。
2. 上面问题的反面，失去变通性和适应性，导致技术准备不足。
3. 未考虑运营手段需求。
4. 对数据规模，请求频次无准备，无概念。

特别强调运营手段（比如说分享邀请好友等活动，比如说做市场渠道跟踪的活动，或者比如说代理策略等，都是运营诉求），举两个例子：

1. 游戏行业，有人问我这个问题，感觉很多小团队，小公司都可以做出好游戏，而且分服机制下，性能的问题一般不太凸显，那么技术在游戏领域的价值在哪里。我的答复是，好的技术架构，让游戏的运营更简单，更灵活，你有什么运营诉求，直接可以简单配置实现；坏的技术架构，就各种不支持，或者需要长时间二次开发才能支持。
2. 电商领域，有个业绩不错的淘品牌，要出淘，做官网，营销能力也很强，老板把自己都搞成微博网红了，很拼的；但自己官网运营活动，一搞秒杀就崩溃。后来我帮他们去看了代码结构，缓存的架构设计问题，积重难返。

产品文档规范

一些大公司对产品文档有非常严格的规定，从我的角度讲，我不是那种特别强调流程规范性和复杂性的人，其实我认为产品文档并不需要特别复杂，核心在于把东西说清楚，让研发能理解透。

但很多小公司的产品文档，往往过于简陋，仅仅表达了某种产品的期望，而一些非常需要明确的地方都十分模糊，所以，这里强调一下，简单不等于简陋，不需要长篇大论或者说非常繁冗的格式，但一些核心要素不可或缺。

产品文档首先应该列出总纲，也就是上文提出的，整体目标的定义，描述清楚产品需求定义，用户目标及产品目标定义，相关边界定义。

描述产品构成，功能视图的清单，基本操作流程，角色构成，主要数据构成。最好能用流程图，或大纲图，让研发首先对产品有一个完整的认识，切忌不要一上来就是视图1、功能1、视图2、功能2。

强调一下，关于目标一致性原则，文档要体现，但不能只用文档体现，必须当面交流沟通清楚，文档只是一个确认和重复的过程，不是说我文档提到了就可以不沟通的，有些研发真不看背景信息的，直接咔嚓咔嚓编码，最后发现很多问题的时候，说你没写清楚。

总纲之后，就是根据角色，根据功能项的视图描述页了。

一个产品，使用者可能存在多个角色，比如网课，有讲师端，有学员端，还有系统管理端，至少三个角色，后面还会细分，比如系统管理又有客服，数据分析，以及Boss不同角色。除了角色呢，还有不同的终端，以前简单，说互联网产品都是pc端，而绝大部分都是网页端体现，现在是pc和移动终端，所以，每个功能视图，都要说明是哪个角色，在哪个终端的体现。

视图最核心的，是页面布局，不论是手机终端，还是pc终端，不论是app，网页，还是客户端，都是页面布局，哪里放什么，哪里有什么，那么，很多缺乏经验的产品经理，或者一些创业团队，把这个做完，觉得，大功告成了，程序员一看不就明白了么？这就是很多问题所在了。

页面上的元素，通常主要包括图片，图标，文案（固定的内容），信息和数据（与请求相关的交互内容），交互操作项（比如搜索，排序或点击等）。

常见的问题是，只提供了页面基本元素，却没有给予后面的一些逻辑，程序员只能脑补其中的逻辑。

1. 数据逻辑

比如说，我们在游戏页，看到一个推荐相关游戏，在商品页，看到一个推荐相关商品。这是一个信息数据的展示，但背后的逻辑是什么？

• 有时候产品经理有明确的逻辑，比如说，最新新闻，基于时间逆序显示多少条；比如说，最热新闻，可能是基于最近几天的点击率逆序显示多少条。这个是明确的数据逻辑，但产品经理也要写出来，也许你不写，研发自己发挥，可能最热新闻这里，就把系统所有历史新闻基于点击率逆序，那么可能最热新闻就十年不变的挂着陈冠希艳照门，这就不好了。
• 有时候产品经理没有明确的逻辑，但有明确的目标，比如说，这里有一个相关游戏推荐，但这个相关游戏的目标是什么？是点击率，好，这是目标，如何产生高点击率的相关推荐，产品经理可能不知道算法策略，需要程序员思考，但至少要让他知道目标是什么。
  • 你要把目标说出来，可能是点击率，也可能是别，比如综合收入或其他。
  • 要跟程序员过一遍这里的逻辑，要确认这个逻辑是可行的，效果是可以持续跟踪和优化的。

你不说，技术人员脑补，优秀的技术人员也许会做的很好，但如果技术人员也缺乏行业经验和目标认知，也许就会做出很不靠谱的设计。

数据逻辑中还包括一个重要的原则，需求边界，后面单独展开。

2. 交互操作逻辑

鼠标停留有什么效果，点击有什么效果，哪里可以点击，哪里不可以点击，滑动是什么效果，这些都是操作。

哪些页面元素是可以操作的，是如何操作的，操作后的反馈是什么，操作后是否进入新的视图或链接到其他视图，这些都是要标注清楚的。

产品设计者如果觉得，我把页面元素都摆出来了，你难道不知道这个地方可以点击么？你难道不知道这个点击链接的是之前的某个视图么？运气好，研发知道；运气不好，真的不知道。

3. 异常和容错性的一些说明

用户输入错，用户输入异常，用户搜索无结果，相关信息不存在的时候，页面应该如何提示，反馈，如果产品不提供任何说明，可能研发就会自行其是，如果研发有一定产品意识，这个地方是可以处理好的，但这样的研发可遇不可求。

这个标注，让研发可以理解即可，比如你简单的做个页面布局的范例，分A,B,C,D四个区块，其中B是一个猜你喜欢的功能，然后文档描述一下，说猜你喜欢这个功能的目标是什么，测试标准是什么。

然后说明这里的每个内容展现格式，链接到哪里，也许是前面另一个视图。

比如，我这个页面显示附近的信息，如果附近没有信息，会提示什么。 比如，我这里需要输入账号密码，如果用户输入错误需要提示什么。 以此类推。

这里多说一句，容错在很多时候也是产品竞争力，比如典型如搜索引擎，google和百度其实都有很强的搜索容错能力，但这个话题技术性太强，就不展开了。

回顾一下，文档的规范，需要：

1. 有总纲。有整体流程、产品目标、角色构成、运营策略，以及不同视图之间的关联关系。要让研发对系统有一个完整性的认识。
2. 总纲之下，是基于不同角色、不同终端的视图，具体的产品描述基于视图。视图首先要明确是什么角色，在什么终端的体现。视图应包括如下信息：
   • 页面元素和布局；
   • 数据逻辑（含需求边界）；
   • 交互操作逻辑；
   • 异常、容错和错误提示；

再次强调：文档不能替代沟通。

测试与反馈

大公司会有独立的测试部门，小公司，创业公司往往没有这部分的人力资源。测试与反馈也是非常重要的产品与研发沟通的范畴。

测试本身是一个专门的很深入的领域，但我们说，产品经理，并不是说要成为测试领域的专才，但是：一要参与测试；二要能就测试给出研发合理的反馈。这样才可以更好的进一步协调和确保产品质量和进度。

1. 要有单元测试的概念。每个模块，每个独立的功能特性，理论上应该是可以测试的。

单元测试的目的是在研发早期发现问题，尽早纠正问题，但由于产品研发早期，相关视图和功能不完整，所以很多产品人员不知道怎么做单元测试，或者认为这是一个纯粹的技术工作。

的确，单元测试更多是技术原型，技术可行性的测试，但产品人员如果有参与，有意识的去了解，对产品的质量和研发周期把握会更有效果。更何况，很多初级的技术人员根本没这个意识。

早期问题发现不了，那么后期的弥补成本，就会远大于早期。

那么，如何开展单元测试？

单元测试，不要求全责备，因为产品不具备完整性，所以首先要确认测试目标，这是和研发一起确认的，产品经理不能认为研发是一个功能，一个功能按次序完成的，很可能有相当的时间用于基础架构，然后快速的实现所有功能。

但一些基础功能特性，是可以优先测试的。而测试的时候，交互界面可能很不友好，或者只是一些临时的显示，但你要明确，你的测试目标是什么。

比如说，基于已有的数据，我只测试一下相关推荐的逻辑对不对，或者只测试某个关键业务流程的操作是否和预期一致。

明确测试目标，测试角色，测试流程，以及测试用例，这是做好测试的前提。

但这里强调，产品必须和研发协调进行单元测试，单元测试的目的是有效保障研发效率，以及尽早发现和确认研发中的问题，如果为了测试，而打乱了正常的开发节奏，延误了正常的开发周期，是得不偿失的。

最怕的是什么呢，开发周期很长，而中间没有任何测试，什么时候去问，都说正在研发中，结果导致产品失控，出来后发现很多问题已经不好修改了。

2. 整体测试，又分线上环境测试和测试环境测试。

一般企业研发会分测试环境和线上环境，正常情况下线上环境跟测试环境应该是完全一致的，但也出现过一些不一致的情况。

案例：我们以前也遇到过测试环境压力测试完全没问题的系统，线上出现了数据库崩溃，后来分析发现两个环境的数据库版本不一致，对同一条SQL的解析，默认用到的索引不一样，改用强制索引后问题解除。当然这是一个技术问题，但类似的情况很多知名公司也遇到过。经常有这样的场景，测试环境一切正常的系统，半夜趁用户少的时候更新发布，然后团队睡觉休息去，结果早上起来发现重大运营事故。所以线上环境测试这个步骤，真的是有必要的。

测试环境测试是可以做破坏性测试的，而线上环境测试一定要谨慎的多，那么测试的时候一定要区分环境和目标。

所谓破坏性测试，比如发大量的垃圾数据，做各种可能导致系统崩溃或数据库损坏的尝试，以及做一些删除和不可逆转的批量更新操作等等。

我知道这么说很low，很多人可能觉得这太小儿科了，但稍微不注意的话，这样的教训是血淋淋的。

3. 关于测试用例

第一：正常流程测试，这是基本都知道的，就是我按照所预期的正常用户的操作流程，操作方式进行测试，看产品功能的完成度，以及可用性。

第二：限制性测试，我输入超长内容，输入带特殊符号的内容，我查询一些错误或者混淆的关键词，我频繁输入错误的账号和密码，我看看系统对这种限制性内容的设计，对错误性信息的提示，对容错性的设计，是否符合预期，是否符合产品目标。是否会出现不应该的提示，或者是否会出现一些系统错误或可能导致信息泄露的技术错误提示。是否会出现一些可能导致安全问题的输入验证不全。这都是限制性测试的目的，但这块后面需要一点技术理解力。我第五个话题会再展开。

第三：反流程测试，用户是否会如愿按照你所期待的流程操作产品呢？这个真不一定。你希望用户是a,b,c,d这样操作，用户有没有可能 a,c,b,d呢。 现实中有这样的案例，就好比我们网课系统的问题，用户从官方公众号进入，选择课程，点击付费，这是一个标准流程，但如果用户从别人分享进入课程，点击付费，怎么就出问题了，类似这样的问题其实还有很多。 刚才讨论区里提到的一些问题也属于这类问题，说明我们自己的测试也是不达标的。

第四：数据规模及并发压力测试，你一个应用刚开始，只有几百条信息，你觉得所有操作响应都很快，你很欣慰，但数据到了几百万条的时候，是不是还可以这样。数据规模和并发压力往往伴生而来，以前我说过，当年山寨icq的，除了腾讯QQ（当时叫oicq），还有好几家，大家起步都差不多，当时的产品特点也基本没区别，为什么今天QQ是一个几千亿美元的公司，其他几家怎么消失了？其实原因特别简单，到100万活跃用户的时候，只有QQ还能继续发展，其他的统统不行了。

我做CNZZ的时候，我当时从开始设计数据结构的时候，就开始做压力测试，功能和视图还都没有去写，就开始对核心特性做压力测试，看看是不是能撑得住数据量，能不能撑得住并发请求，有信心了，才开始去完成代码和功能。

同样的功能，同样的诉求，1万条记录，100万条记录，1亿条记录，100亿条记录，这个处理方法和系统架构是完全不同的，当然，我们创业初期没必要考虑过于长远，淘宝刚开始还用开源软件做了一年呢，开始不用过度考虑，但我建议至少你要做第一步的准备。说到底还是个度的问题，过度考虑性能和并发会太浪费技术资源，但完全不考虑你业务发展起来的时候真就欲哭无泪。

第五：安全性测试，技术话题，暂不展开。

4. 关于测试反馈

你测试的结果，如何反馈给研发。一股脑的把问题发给研发，这很容易给对方带来困扰。

你要先做好问题的分类，哪些是可用性的问题，哪些是操作体验的问题，哪些是运营支持上的问题，哪些可能算不上问题，只是一些建议和想法。

列好分类后，列好严重程度，以及优先级。

有些公司会有一些 bug 管理工具，这是最好的，如果没有，用 excel 也不是不可以，但是这些要列出来。有些问题可能很严重，但未必紧急，可能这部分业务暂时不开展，或者相关市场资源还没准备就绪。所以要把优先级，严重程度分开标记。

那么测试反馈出来后，也需要跟进研发的解决，如果有可能，还是建议搞一套bug跟踪系统。这个具体我现在有点落伍，也不知道哪个更好，网上搜一下有很多，不要找特别复杂，所谓功能特别强大的，没必要，找大家都容易理解的，容易实施的就好。

总结：

• 测试是贯穿研发周期的事情，不要所有问题都到那边说，做完了，你们看看吧，才发现，各种不对劲。这样解决成本太高了，要跟研发沟通，不同阶段需要有不同的模块，单元测试，这样进度才是可控的。但测试目标一定要跟研发沟通，按照他们的正常研发流程配合进行，切忌为了测试导致打乱研发节奏，这就得不偿失了。
• 测试用例包括正常流程测试，限制性测试，反流程测试，性能压力测试，安全性测试。
• 测试反馈不要一股脑的罗列，要做好分类，严重性和紧急度的标记。
• 跟进测试反馈，建议有一套测试反馈的系统。
• 测试反馈是基于问题的，但反馈后，可以继续和人沟通，有些解决方案，可以听听研发的想法。还是那句话，目标一致性最重要，如果研发和你目标一致，解决问题的方法并非一成不变。

需求边界

什么是需求边界？我们定义一个功能，定义一个数据逻辑，但我们要知道，技术有研发成本，同一个功能，一个数据逻辑，如果我们知道用户诉求的边界在哪里，可能就会减少很多无用功，提升研发效率。

数据量边界

说个自己的例子：

CNZZ 的第一个版本，是我独立开发的，当然后来一些交互页面阿飞有调整的。现在的版本已经没有我的代码了，这个例子我以前公号文章也提过，当时我做这个产品的时候，其实我即是产品，又是研发，所以没有什么沟通成本，这个东西代码量不大，后来很多技术高手看到代码都很鄙夷，觉得技术含量不高，而且问题也蛮多，他们说的也对。

但这个产品，我讲一点，我的研发周期，也就两周，而且不是说从早到晚每天都在写程序，每天可能也就写不到两个小时，真的，两周，业余时间写的，平均每天不到两个小时编码。 发布出来没多久，成为市场第一。

为什么能这么短时间写一个完整的统计系统，不是因为我编码能力强，而是因为我懂得取巧。

这个产品策略问题回头可以慢慢解释，和今天课题无关

产品策略是一个取舍的过程。

这个取巧，就是需求边界，后来我看到有些研发团队做同样的事情，花了很多的时间和精力，其实大部分浪费在做无用功。

有个例子我经常提的，百度，淘宝，google，搜索结果都是不会超过100页的，很少人意识到这一点，为什么？大翻页是个典型的技术问题，不管用商业数据库，还是自己的索引结构，大翻页的效率损失都是很可怕的。

以前很多论坛社区，大家都知道，用户是很少翻几百页的，但搜索引擎的蜘蛛会翻，以前很多论坛社区，因为网页内容很多，白天用户多的时候屁事没有，半夜崩溃了，不知道原因，仔细一查，半夜蜘蛛来爬，把数据库爬死了，为什么蜘蛛会爬死数据库？因为蜘蛛一直在翻页。

回头来说，这里的关键是什么，不论你用百度，用google，用淘宝，你会翻超过100页么？这就是需求边界。如果你把这部分需求屏蔽掉，技术问题就解决了，那你说，我搜不到怎么办，换关键词会不会，换搜索条件会不会，你真的会翻100+页么？

cnzz 里我做的时候，也有类似的策略，比如说，我们说一个网站有 top refer， top page，最多的来路，最多的访问页面，有个做统计的团队，说大网站的这个数据量很大，怎么存？ 我说，我问你一点，你去问站长，去查看这个数据的时候，会翻多少页？长尾页面的访问量会统计在汇总里，但不需要每个长尾页面都统计到，这就是需求边界。而他们技术，花大量时间试图解决这个数据规模的问题，就是无用功。

以前还有一个朋友，做 app 市场数据排名跟踪，跟我说存储量太大，我说你存的什么东西，存每天，每个 app 的排名变化，我就说一点，我说作为 app 的管理者也好，作为竞品分析也好，这个 app 今天第五名，明天第三名，这个变动是有意义的，对吧。这个app今天105名，明天 103 名，这个变动有意义么？

什么意思呢？如果排名低于多少名，并且变动少于一个比例，这个数据不用记录，展现的时候就取前一天的数据，一条直线，这个变动没意义。什么时候变动超过这个比例了，再记录，结果，数据存储规模一下子减少了 2/3 还不止，那每天的系统处理效率也提高了。

精确度的边界

当然，我们希望说数据是完全精准，完全精确的，但有时候，你容忍度宽一点，系统设计的复杂度就低很多。

cnzz 当时是国内第一个号称实时统计的平台，实时统计其实是很有意义的，很多其他统计平台当时要不没意识，要不觉得实现成本太高，其实我也是取巧，是每分钟刷新数据的，并不是完全实时，你刷新页面还需要几秒钟呢，看数据最快还要半分钟呢，我给你提供一分钟的处理间隔，基本可以满足用户对实时数据的这个需求了。全实时有必要么？

数据覆盖率边界

我们都希望数据一条都不要丢，但实际上，cnzz 这种嵌入式代码，本身在网络环境里，自然就会有百分之几的数据损失，这个是所有统计系统无法避免的，包括 google analytics 在内，谁也躲不开，这时候你说你百分百不丢数据，你根本体现不出你的优势来。

cnzz 我做的那个版本，在每分钟做数据处理的时候，有一个日志切割的过程，这个过程，其实是有可能丢失一点点数据的，但比例很低，有没有千分之一不好说，但这个对这种第三方统计系统来说，其实真的没关系，自然损失的比例远高于这个比例。这也是一个需求边界的问题。如果硬要解决这个问题，技术成本可能要提高非常多倍。

关于前些天给赞刷屏的小程序，可以先看看这几篇文章：

http://mp.weixin.qq.com/s/KwPaGg2az7h_3_rMVOuLFw http://mp.weixin.qq.com/s/5oucOA5KmjyUTRtb-N8y9w

我的一些感受是：

创业公司，尤其涉及 UGC，这种能力非常重要，请一定仔细看看想想。

Growth Hacker之防御术

作者：Stoned 来源：纯银的「pmdogs」Slack 社区

一

在犬校里见了不少被攻击的例子，有些我经历过，有些我也对其他人用过。其实很多时候，稍微了解一些，在设计与开发时，略加注意，提前预防，就能避免遭受类似的攻击。（以下内容针对App的攻防）

给大家讲具体的方法之前，需要先对大家普及一下一些基本的概念。

唯一标识（unique identifier）。我们会用一些唯一标识来区分不同的用户，常用的唯一标识有

• UserId，自己产品的用户id
• OpenId, 第三方产品的唯一用户id，比如微信的openid。
• IMEI，每个手机都会有不同的IMEI，所以IMEI可以用来标识设备是否相同。（苹果因为禁止获取IMEI，但仍有办法获得类似的标识）。ps：忽略山寨机，12年左右山寨机比较多，好多imei是相同的，但现在极少有imei相同的手机了。
• 手机号，通过验证的手机号。
• IP，ip不算是唯一标识，因为一个局域网的用户可以使用相同ip进行登录或者操作，但ip仍可作为一个有效的手段来区分是个体用户还是组团用户。
• token，因为http是无状态的，这意味着每个请求都是独立的，所以你不能因为用户的上一个请求通过登录了，下一个请求就不检验这个用户是否合法。因此会用token来代表用户的合法性。
• 签名，我们知道文件下载的时候会检验下载下来的文件签名是否与官方公布的文件签名是否一致，这样就可以避免文件被篡改或者下载不完整。同样的，我们也可以用签名来验证一个客户端api请求的合法性。

攻击（attack）。攻击一般分两种，非法攻击与合理攻击。两者的区别在于是否篡改app设计的功能行为。所以举个例子，合理攻击包括

• 组织1000个人，每人操作10个手机，定点（比如晚上9点）使用app的上传视频功能，结果服务器搞崩了几个小时。
• 通过抓包的方式，发现正常请求一个用户的信息的时候，会泄露这个人的密码等隐私信息（虽然没展现在界面上），所以你通过这个办法获取到了某个重要人物的密码，登录他的账号后，给他传了一些不可描述的视频…
• 人为上传敏感视频或内容…

一般可以进行合理攻击的原因都在于产品/接口设计缺陷，在设计实施时有意识想想这块问题，基本都能避免。所以后面我们主要针对非法攻击这块。

刚才给非法攻击下了一个定义，非法攻击是指篡改了app原本的功能行为的攻击行为，所以，既然与原本的app行为不一致，那很明显，这种攻击是指有人通过代码/工具模拟或篡改app行为，所以这种攻击一般具有以下特征：

• 高频
• 大量请求
• 集中，所有请求通过某一UserId或者某一IP或者某一IMEI发起。

既然我们知道了非法攻击的定义与特征，有什么办法可以避免呢？换言之，有什么办法可以避免别人模拟或篡改app行为呢？其实答案也很简单，那就是

• 不让其他人发现app行为背后的请求与逻辑
• 对每个用户请求采用签名验证，拒绝伪造请求。
• 如果还没办法做到前两项，那么还能根据非法攻击的特征进行预防。

待续…

最近很是刷了一阵 Instagram，觉得它的发现很有价值：

• 简单，不用思考，无脑下翻就可以；
• 反馈，看到好的内容就点赞，这个动作对用户（无论赞或被赞者）和厂商都很有价值（更精准地推荐，对内容及内容提供者的价值有更好的判断），赞也能够给用户心理满足感；
• 沉浸，尽可能不要有花哨的元素来干扰用户的探索；
• 优化，比较「聪明」，可以被优化，赞、关注、发表等动作都会对发现里的内容有调整；
• 丰富，有足够多的内容，因此虽然喜好有倾向，但也总是能有些新鲜事物来刺激眼球；