关于用户积分体系

自工作以来有意无意地也做了几个大大小小的和积分相关的项目/产品。做个简单的总结。
先说本质,积分的本质是用来通过一个类似货币的东西来刺激用户活跃,或者说激活(activate)用户。比如虽然现在微信支付正在侵蚀支付宝的领地,但是由于微信支付没有相应的用户体系,所以在这一块算是遇到了短板,下一步再想“侵占”支付宝就很难了。
从定义的角度来说,我觉得英文里的两种说法可以方便区分积分的两个“变种”:
points – 积分点,比如bonus point、loyalty point,最接近货币的概念,所以一般情况下,这个积分点是可以进入账户支付体系的。用户获取成本一般较低,因为对用户的身份和信用度和消费力不是特别关注。
credit – 信用点,更强调用户在系统中的信用度,这个credit可能会和某些特权关联,但通常这种积分不会进入账户支付体系,而是通过独立的兑换中心来完成。用户的获取成本相对比较高,比如必须有下单才能获得。
目前,大多数的积分可能更偏向于后一种,因为直接和支付体系关联会产生财务核算、成本、对账等等一系列操作。但不可否认从用户角度来说“积分当钱花”还是很诱人的一件事。
还有一个问题是,如果积分和货币直接挂钩,相当于创造了一个经济体系,有积分消费、积分产生、通货膨胀、供需决定价格等一系列更大的坑。很多时候,我们会直接锚定一个积分价值,比如对应到1分钱 = 1积分。但如果积分不能很好流通和消费的话,用户可能会更加反感。
我个人偏向credit,并且将积分简化为只能在“兑换中心”或者“礼品中心”使用,同时不锚定积分价值,运营人员可以根据实际情况灵活掌握兑换“汇率”,通过限制兑换数量、周期而获得更多的运营空间。相对主动一些,而不是像前者那样需要不停地监控经济体系的健康状况,每天看着发那么多钱而提心吊胆。如果实在想要实现积分抵现金,可以通过让用户兑换代金券然后来“曲线救国”,当然效果肯定不如“积分抵现”直接,但只要用户对你的抵用券有兴趣或者抵用券确实有价值,而且这种做法的最大好处还是“相对可控的” — 用户兑换多少券、使用多少券都可以进行运营上的限制。
 
再说说数据指标,既然是针对activation,就主要看:积分的获取情况、使用情况,以及积分使用用户的订单转化情况、付费用户比例。
 
但是无论是哪种方式,积分都是一个运营占主导的工具,在体系框架完成后,需要不断进行运营上的优化。

你「构建」的啥?

工程师眼里,所有事情都是工程。也是为什么会有 social engineer、social hack……

工程师的主要工作是:应用科学+构建可用之物。

依照这个前提,所有人无非是三个级别的工程师 – 构建的对象不同:

1. 物

最常见的工程师,也就是一般意义上的工程师,越牛的工程师能够构建的物品越复杂。比如软件系统、汽车、建筑。

2. 人

比较常见的就是老师了,但其实大多数的领导者,只要团队超过1个人,就算。领导的人越多越牛,当然前提是能够产出。

3. 想象

也就是真正意义上的大师、哲学家,提出一整套的体系,至于是不是由他来构建,不重要。有时候,没构建出来反而更受大家追捧。

瞎扯~

选择基于用户(user-based)还是基于物品(item-based)的过滤?

“推荐”的本质是 – 为a推荐b,a是主体(或者在一个协同过滤系统中叫user),b是客体(在协同过滤系统中叫item)
而学习的来源是已有数据中 user对item的选择(协同过滤)
user-based和item-based只是两个方向,简单来说:
user-based是“人以群分”,item-based是“物以类聚”。
如果某几个user经常选择相似的item,或者说某几个user对某个item的评价(“品味”)是相似的。那么当另一个user表现出相似的品味时,推荐给他那些根据品味聚集起来的其他user所选择的item。也就是所谓的“人以群分”,这是user-based。
优点:比较容易实现,适合规模较小但变化频繁的数据集,比如音乐推荐和分享类网站。这样网站的用户更愿意了解和自己”臭味相投“的人。
如果预先算出item之间的相似度,然后根据user对其中一个的选择来推荐其他的相似item给他,就是item-based。也就是”物以类聚“
优点:不需要随时计算,可以预先或者通过后台增量去计算。关键在于物品间的比较不会像”用户选择“的比较那么频繁变化。(比如购物网站,或者item非常多)
在实践中,无论是user-based还是item-based都在于搞清楚哪个是user哪个是item。
那么举个例子,如果是”发掘潜在的付费用户“这个主题,到底是user-based还是item-based呢?
(以下只是分析,未必是标准答案)
首先,这个表达不是很明确,潜在的付费用户是如何定义的?
是购买相似产品的用户?
是购买过产品的用户?
是第一次购买吗?如果用户有第二次购买行为需要发掘吗?
个人觉得“发掘潜在的购买行为”更准确一些。
还有一个因素要考虑,产品的种类有多少,如果像淘宝/amazon那样有数以十万计的商品,显然应该是item-based。但是如果是很少部分(比如1%)的用户购买几个产品。反倒是user-based也比较合适(甚至人工介入)。
但是注意,“您购买了a我推荐您购买b”。此时a和b应该避免是同一个类别,当然,如果推荐结果里出现过多的“同类推荐”,说明算法有问题。用户已经购买了,貌似已经不是”发掘潜在”了。
其实这里还是应该使用“item-based” – 先把所有的用户进行聚类,然后发掘和付费用户相似的的用户。发掘潜在的付费行为也就有了着落。此时最大的问题是聚类属性的选择。
所以,无论是user-based还是item-based,都要看问题的本质是什么,如果没有正确理解问题本质,要么逻辑很复杂,要么效果差。

关于用户账户、授权和密码管理的12个最佳实践

翻译:zhangv
在处理用户账户、授权和密码管理时,有时情况会非常复杂。对很多开发者来说,账户管理时一个经常被忽视的问题。对产品经理和用户来说,结果常常是始料未及的。
幸运的是,Google云平台(GCP)包括了一些工具来帮助你安全地创建、处理用户账户。无论你负责的是架设在Google Kubernetes Engine上的网站,基于Apigee的API服务,使用Firebase的app,还是其他需要验证用户的服务,本文将展示给你一个安全、可扩展、可用的账户验证系统的一些最佳实践。
1 . 密码不要明文存储
我认为账户管理最重要的一条法则是:安全地存储敏感用户信息,包括密码。对待这些数据一定要慎重而合理。
在任何情况下都不要以明文来存储密码。你的服务应该存储足够强的密码不可逆加密摘要 — 使用类似PBKDF2,Argon2,Scrypt或Bcrypt来创建。摘要时还需要加入随机字符串(盐)。不要使用已经废弃的摘要算法,如MD5,SHA1,并且在任何情况下都不要使用可逆加密算法或者自己发明摘要算法。
在设计系统之初就要考虑到系统被黑的情况。问自己“如果今天数据库泄漏,用户是否会收到影响?我们可以做哪些补救措施?”
另一个问题:如果在用户提供给你密码后,你可以获得铭文的密码,那么你的实现方案就是有问题的。
2 .支持第三方的身份授权
第三方身份授权可以让你依赖外部的可靠服务来验证用户身份。Google, Facebook和Twitter是最常用的身份授权提供方。
你可以使用诸如 Firebase Auth的服务来帮助你整合外部身份认证授权。优点是:包括简单的管理界面,更不容易被攻击,多平台SDK。我们在下面会介绍更多特性。
3 . 分清楚用户身份和用户账户的区别
你的用户不是邮件地址,也不是电话号码,更不是OAuth服务返回的唯一标识。你的用户是他们在你的应用服务中的一系列个人数据和体验的累积。优秀的用户管理系统体现在用户个人数据各个部分设计上的低耦合和高内聚上。
用户账户和隐私信息的分离可以让你简化实现第三方身份授权的难度,并且可以允许用户修改用户名,将多个身份授权和同一个账户关联。实际操作中,每个用户拥有一个全局的身份标识,然后其他关联信息通过这个全局标识进行关联,而不是把这些所有的信息放到同一个数据记录上。
4 . 多个授权标识关联到一个账户
这个星期用户通过用户名和密码登录了你的服务,可能下星期会用Google的授权进行登录。这可能造成重复账户的问题。同理,用户可能会使用多个邮箱地址来使用你的服务。如果你将用户标识和认证分开,也就是可以更容易地链接多个标识到同一用户。
后端实现需要处理用户在注册过程中意识到他的第三方授权没有关联到他们已有的账户,这时就需要让用户提供一个共用的识别标识,比如邮箱地址、电话号码或者用户名。如果系统已经存在这些标识,那么就允许用户使用第三方授权认证,并将这个新的ID关联到已有账户。
5 . 不要阻止用户使用长或复杂的密码
NIST最近更新了关于密码复杂度和强度的建议。只要你使用了比较强的加密摘要算法,那么很多问题其实都不存在。无论输入长度是多少,摘要算法总是可以产生固定长度的输出,所以用户也就可以想用多长的密码都可以。如果一定要一个确定的密码长度,只要看一下服务器允许的最大POST请求的设置。通常是1MB。别慌。
你的密码摘要只包含一小部分已知的ASCII字符。如果不是,你可以将二进制的摘要进行Base64编码。因此,理论上,你可以允许用户在密码中使用任何字符。如果有人想使用克林贡语、Emoji或者控制字符,技术上也是允许的。
6 .不要制定不合理的用户名规则
网站或者服务通常会设置一些不合理的用户名规则,比如要求用户名应该至少两个或三个字符,不允许使用隐藏字符,不允许在用户名的前后使用空格。更有甚者,会要求用户名至少是八个字符,或者很粗暴的禁止任何非7位的ASCII字符集的字母和数字。
虽然严格的用户名限制可以让开发人员轻松一些,但是这些是以用户体验为代价的,设置可能驱使用户离开。
有些情况,最好的方法是分配用户名。如果你的服务适合这种情况,那就尽量让用户名尽量简单易记,方便沟通。字母数字ID可以避免视觉上的混淆,比如“Il100”。你也可以扫描字典来确保你的密码中不含有歧义。这个规则也适用于自动生成的密码。
7 .允许用户修改用户名
很多遗留系统和任何提供邮箱账号的平台不允许用户修改用户名。虽然有很好理由禁止被释放的用户名重新使用,但是长期用户还是会想要换个用户名而不需要创建一个新的账户。
你可以允许用户使用别名,然后让用户自行选择使用哪个别名,从而可以满足用户修改用户名的需要。你可以设置一些规则,比如有些机构仅允许每年修改一次用户名,或者只显示用户的主用户名。邮箱提供方需要确保用户在取消关联某个用户名时被告知了,或者禁止完全取消关联旧的用户名。
使用恰当的规则,但要确保允许用户后续可以修改。
8 .允许用户删除他们的账户
大量的服务没有自助的方法让用户删除他们的账户和相关数据。当然,谁也不想。这些考虑需要配合你的系统安全需求,但很多受限环境会提供具体的数据留存方法。通用的解决方案是让用户设定自动删除账户的时间。
某些环境下,你可能需要依法遵循用户的要求来定期地删除他们的数据。你也可以避免在数据泄漏事件中将那些已经“关闭”的账户信息泄漏。
9 .理性决定会话长度
安全和认证的会话长度通常被过度重视了。Google花了很大的力气去确保用户是他自己,并且会依据某些事件和行为来再次确认。用户可能需要多个步骤来提升账户的安全性。
你的服务的会话可能会因为某个非关键性的分析目的而一直处于打开状态,但是需要需要设置一个阈值,当达到这个阈值时需要输入密码、第二步认证或其他认证方式。
考虑经过多长时间来再次对用户进行认证。如果用户重置了密码,需要重新验证用户。如果用户修改某些核心账户信息或者进行敏感操作时,要求用户验证或者多重认证。考虑是否允许用户可以通过多个设备和地点同时登录。
当用户的会话过期或在要求用户重新验证时,尽量不要打断用户正在进行的操作,并且保留用户未保存的数据。让人沮丧的一种情况是:用户填写完一个很长的表单并提交后,才发现他们需要重新登录 – 并且所有填写的数据都丢失了。
10 .使用2步验证
如果选择2步认证(2重授权或 2FA),需要考虑当用户账户被窃取时的实际影响。短信2FA因为很多原因,已经被NIST废弃掉了,但是仍然是一个大多数用户乐于接受的选择。尽量提供安全的2FA方案。使用第三方授权服务,并借助他们的2FA是一个省钱省力的方法。
11 .用户ID大小写不敏感
你的用户可能不在意或不记得用户名的大小写。用户名应该完全大小写不敏感。常见的做法是保存用户名和邮箱地址时转化为小写字母,检查时也都转换为小写字母。
智能电话意味着不断增长的用户设备数量。很多都支持自动纠错和自动开头字母大写。在UI级别就阻止这种行为,而且你的服务需要能够处理这种未注意到的自动大写。
12 . 构建一个安全的认证系统
如果你在使用Firebase Auth,很多的安全问题都已经自动帮你处理了。但是你的服务还是需要优化以防止被滥用。一些核心的考量包括:使用密码重置而不是密码找回,详细的账户操作记录,登录尝试频率限制,如果账户被过多次尝试登录则锁定账户,在陌生设备上首次登录时或长时间未登录的账户使用2FA。还有很多其他的方面,可以参考下面的链接。
进一步阅读:

关于孩子的”非线性“阅读

前天随机地看了一个TED,里面有一段:

As a society, we’re creating reading experiences for children that are the equivalent of telling bar jokes in a church. And then we wonder why so many children don’t read. Educator and philosopher Paulo Freire believed that teaching and learning should be two-way. Students shouldn’t be viewed as empty buckets to be filled with facts but as cocreators of knowledge.
有点启发和触动。这句话大意是:我们给孩子提供的阅读体验实际上近乎“对牛弹琴”或“强迫”的单向体验,或者说是“被动”体验,而应该让孩子也成为知识创造者,或者说让孩子体会到创造的乐趣。说起来我今天中午还在给儿子读《老人与海》,完完全全是这种体验,我也很累,儿子也没有任何互动的反馈,像是在完成任务。
如何让阅读变得有互动、有反馈,就像游戏一样?
在阅读《老人与海》时候其实有考虑一种模式,所谓“非线性”阅读,比如在阅读过程中会有很多新奇的东西或者地名,如果我们直接“跳走”去看对应的条目或者扩展,会怎么样?孩子原本被我胁迫的阅读体验会打断或无效吗?我倒觉得,反正也是无效,倒不如干脆“跳走”,让孩子来决定阅读体验。也许这种非线性的阅读更适合人类。
鱼叉是什么样子?怎么用的?帆是什么样子的?为什么要用帆?哈瓦那是哪里?什么样子?我们什么时候可以去?……男孩是老人的什么人?为什么他看起来很喜欢老人?……
继续问下去,你还怕孩子问不出你回答不出的问题吗?
阅读体验能否变成“随机行走”?应该可以。

区块链到底做了什么?

区块链不亚于人类历史上任何一个发明。

如果说互联网通过信息的可复制性打破了沟通的障碍,那么区块链则是通过算法打破了信任的障碍(或者说,某些不可复制信息的传输问题)。

二者都是利用了计算机和网络技术。

互联网之前,信息存储在每个城市的图书馆、大学里,有了互联网,再没有一个图书馆可以抗衡这个信息源,而且它只会扩张。

区块链之前,信任都在各个国家的政府、银行里,有了区块链,没有一个国家或银行能够抗衡这种信任源,而且每个人只会让区块链更强壮。

最牛逼的地方是,他们基本没有给你“倒退”的可能性,互联网我们已经可以看得出来,要么与世隔绝,要么开放,信息时代没有人敢这么做。

互联网和区块链是信息时代最强大的两个发明:

互联网重新分配信息,区块链重新分配财富。

很棒的一个TED:https://www.ted.com/talks/don_tapscott_how_the_blockchain_is_changing_money_and_business

OKR介绍:目标和关键结果

原文:https://www.leadingagile.com/2018/01/an-introduction-to-okr-objectives-and-key-results/

OKR是一个流行的评估流程,用来在组织中设定、沟通、跟踪目标和结果,通常每个季度依次。OKR的旨在将组织、团队和个人的目标连接起来,从而得到一个可衡量的结果或产出,将精力集中于可衡量的事情上。

为什么OKR重要

在一项哈佛商业评论的调查中,只有55%的中层管理人员能说的出所在公司的前五个主要目标中的其中之一。当这些管理人员被要求将公司的企业目标解释给下属时,将近一半的人连一个都做不到。这种现象并不新鲜。Andrew Grove最初时在他的书(High Output Management)中描述了目标与关键结果(OKR)这个概念,并且指出“一个成功的MBO系统只需要回答两个问题:我们想去哪里?在这个过程中应该如何调整自己?

Grove在他书中所说的MBO(Management By Objectives)实际上是指OKR。也就是说,“想去哪里”决定了目标。“如何调整自己”决定了里程碑,或关键结果。

之后,Franklin Covey提出了类似的策略 – 执行四原则。

目标的特性

  • 雄心
  • 定性
  • 可操作
  • 时间限制

关键结果的特性

  • 可衡量和可量化
  • 让结果可达
  • 时间限制

一个初创公司OKR例子

公司目标1

完成融资以支持六个月的增长[47%完成]

关键结果1-4

1. 邮件和电话100家风险投资和种子基金(已联络65家VCs)[65%]

2. 获取至少30个进一步会议或电话会议(15个会议已完成)[50%]

3. 获得至少3个满足我们最低条件的投资条款协议(已获得1个)[33%]

4. 在本轮融资中至少做到1000万美金的估值(已融资400万)[40%]

关键结果1的个人目标

目标是邮件或电话100家风险投资和种子资金。会分配到多个个人,然后每人都拥有一个关键结果。

个人关键结果

注意这些低级别的关键结果完成情况会归结到高级别关键结果。

1. Bob Smith调研并确认100个VC和种子资金(已确认100个VC和种子资金)[100%]

2. John Doe每周邮件或电话联系4个VC或种子资金(本周已联系3个VC)[75%]

3. Bob Smith调研并确认50个天使投资人(已确认25个天使投资人)[50%]

 

如何实现OKR

1. 每个级别(公司、项目组、个人)列出3个需要努力才能达到的目标。

2. 每个目标列出3到4个关键结果。(高级别的关键结果成为低级别的目标)

3. 和公司的每个人沟通目标和关键结果。

4. 制定衡量指标(通过GQM)来跟踪完成进度。

5. 更新每个结果,预先设定0-100%的完成范围。

6. 考虑当结果完成度达到70-80%时,认为目标完成。

7. 定期评估OKR并更新。

 

关于深度工作

最近看了《深度工作》这本书,其实这本书听说很久了,但对于这类“机场畅销书”的态度是:“先放放”。半年一年以后如果还能听到别人提起,那么就看。

说实话,刚看完这本书还是有点“打鸡血”的感觉,时不时发现:嗯~和我想的一样。类似感觉的书还有《rework》和《remote》。

觉得全书最主要的一个观点是:制造不受干扰(包括自身和外界)的工作环境。

说起来简单,但是做起来并不容易。外界干扰比较好理解,一些日常不得不处理的琐事,经常打断思路的环境等等。但是我觉得大多数人其实是自身干扰的“奴隶”。比如,经常不自觉地刷朋友圈,或者facebook,一刷就停不下来;或者总是倾向于处理那些简单而不产生深远影响的无足轻重的事情(当然,有些琐事还是要处理的);还有就是缺乏长远的计划/规划 – 这也是“倾向于做琐事”的原因之一。

工作中的“熵”

熵,是信息论中对消息中包含信息的平均值,简单的说就是:一件事的不确定性的大小。

增熵,代表信息量增大,即一件事的不确定性变大;相应地,减熵,代表信息量减小,事情的不确定性变小。

在团队中,我们经历的很多事情不外乎三件事:

1. 增熵

2. 减熵

3. 不增熵也不减熵

增熵,通常是提出一个新的方向或者思路,常见于所谓领导者给出一个问题。比较有代表性的就是愿景(vision),是需要去执行的。

而执行的过程,就是减熵,将方向细化为方案/项目/任务/时间截点几个维度。

第三种,熵没有变化,常见如开会中,某人说了一个大家都知道的观点,或者仅仅是转述。“大家都知道” 这个几个字很重要,如果受众中有某些人还不知道,那么从应该知道的受众维度来说,也是“减熵”的。

从信息论角度来思考,我们可以试着解释一些事例。

  1. 某些人热衷开会,说一些无关痛痒,或者干脆一言不发,只会夸夸其他,说些常识。或者将一些常识换个名词反复提出。那么这种人就是对团队无益的。
  2. 通常情况下,上级提出问题,下级解决。如果你发现,你给下级提出一个问题后,他会提出另一个问题来问你。那么就是下级在领导你。
  3. 我们日常工作中,一般情况下来说,除了最顶级的老板和从事最基础工作的人,大多数的人都是既做增熵的事,又做减熵的事。比例的不同,决定了你是否适合这个团队。
  4. 如果团队里大多数人的大多数时间都在减熵(比如外包公司),而你期望做增熵的事,那么就不适合在这个团队。如果团队里大多数人都在做增熵(比如广告公司,设计公司),而你在做减熵的事情,那么你在这个团队里就不是那么重要的。
  5. 最怕的就是增熵和减熵能力都弱的人,也就是既无法落地,又缺乏思路的人。

Packagist版本不同步更新的问题

git commit -a -m ‘xxx’

git tag v1.0.0

git push origin v1.0.0