Photo by Todd Jiang on Unsplash

“ 迈出第一步，就是一种成功。”

对于一个互联网软件而言，立身的基础是自身的功能，而依赖的核心是使用者，即为用户。为了之后可以实现精准的广告投放、数据统计以及更多的运营功能，用来标记用户的账号则是所有的核心与基础。

关于游戏运营发行系列的第二篇，第一篇是个类似目录的结构性说明，感觉没什么分享的价值，就先从整个工作的地基账号系统开始。话不多说，这便启航。

01

—

需求背景，后台与中台

1. 需求背景

在介绍账号系统的设计实践之前，必须要先说明一下需求背景。不论是互联网游戏，亦或是其他的互联网软件产品，都需要靠账号来识别并标记用户，并根据账号来设计相关的用户运营功能。

那么如何提供账号能力，供游戏或产品研发方使用呢？一般来说，如果研发方并未自己设计账号系统，则他们就必须接入其他平台的账号系统，例如常见的QQ微信登录，国外的谷歌、facebook等第三方登录，这是使用第三方的能力创建一个服务于自身产品的账号。此时这个借由其他能力创建的账号，首先属于产品需求方，即研发方。有了账号，我们就可以通过账号ID来区别标记用户，未来还可以把该账号相关的行为数据与账号ID关联起来，进而创建一个用户表，用于用户运营。同时账号ID也是所有的用户行为标记操作者的唯一ID，就好像我们的性命一样。

所以基于区别、标记以及服务于未来运营的需求背景下，我们首先需要设计用户的账号系统。

2. 后台与中台

在介绍需求背景中，目前很多产品在设计了自己的账号系统同时，也会接入第三方的账号系统。这个使用第三方能力的方式，换一句话说就是使用了第三方的后台或中台能力。

后台与中台的定义比较广泛，我也很难给一个明确的定义。为了之后的介绍，这里给一个我的定义。

后台，提供能力的服务方。这里举几个实际的例子，比如数据后台。即提供数据的服务方，用户可以通过数据后台直接了解数据。后台的特点就是直接提供能力，供需求方使用。

中台，汇聚后台能力的中间方。比如数据中台，即获取数据后台的能力，再将能力提供给需求方的，常见的情况比如有用户数据中台。假如你的团队旗下有多款内容产品，包括直播、电商及其他等等，这些产品都需要获取用户标签信息来进行广告投放以及其他运营操作。此时数据中台就可以从数据后台获取用户数据提供一个供多个产品同时使用的统一标签中台，供直播以及电商产品等其他产品来使用。

前台，获取后台或中台能力的需求方。这个就是前文举例中的直播、电商平台产品了。

由以上例子可以看到，如果你的团队负责的是一个多产品的平台类团队，此时就比较适合使用中台的方式来提供能力，对于游戏发行运营工作而言，这个中台能力的体现就是发行SDK了。

除以上情况以外，有些产品发展到较大规模以后，也会把账号、支付等通用功能以及具体的业务功能拆分，将通用功能独立为由中台负责。

对于游戏发行与运营工作而言，主要负责的就是后台以及中台的能力设计与建设了，最终就会体现在SDK功能以及相关的运营后台。

02

—

账号的创建

互联网软件一般分为无需账号以及注册账号使用功能。对于游戏而言，Steam、PS、Xbox这样的主机、电脑游戏平台，则是强制必须注册账号后方体验游戏或是限制体验。对于服务型的网络游戏而言，则会使用无需账号的游客模式以及注册账号后的跨设备数据同步模式。这里就着重介绍服务型网游的账号设计。

注册方式一般分为游戏方自己提供以及使用第三方账号服务两种，例如下图的网易游戏。

1. 官方的注册与登录

如果由游戏方自己提供注册、登录服务，一般使用手机、邮箱作为账号，辅以密码、短信验证、邮箱验证来注册或是登录。

对于注册与登录的功能设计，还需要注重用户体验。在此介绍几个比较重要的体验设计。

（1）账号的格式校验

当用户注册或登录，输入账号时，需要针对手机号、邮箱等常见账号加上输入格式验证以及格式异常提示，以避免用户输入错误不知问题是什么以及如何处理错误。

有些产品除了使用手机号、邮箱作为账号以外，也会使用唯一的用户名、唯一的数字ID等唯一标识作为账号，此时也需要根据这些账号的格式加以校验。

前端处理的是用户输入的校验，同时后端也需要配合前端加以校验，以避免产生违规的数据。

（2）风险控制

常规的账号密码登录需要注意风控，如果出现多次账号密码有误，可以再用短信验证、邮箱验证避免多次请求，以防止暴力破解，同时超过一定次数则不再处理注册或登录请求，加以限制。注册登录的服务封控本身也是一个课题，在此仅作简单介绍。

（3）信息提示

在用户注册或是登录账号时，可以在加上一些提示，例如建议的密码长度、格式，当输入信息错误或异常以后，给与相对应的提示以及解决方案，以帮助用户解决问题。

2. 第三方账号注册与登录

国内常用的QQ微信微博抖音账号，以及国外的谷歌、Facebook、Steam、Discord等都提供了服务，可供开发者接入，使用这些平台的账号同时在开发者的产品内创建账号。所以除了常见的手机、邮箱、平台自定义的用户名等账号以外，第三方平台的账号也是账号之一。

至于如何接入第三方账号，可以参见各家的开放平台和开发者平台，在此不多赘述了。

3. SDK中账号注册的注意点

（1）兼容其他的账号服务

作为游戏发行方，一般都会封装好各家第三方平台的账号功能，但是也会出现需要接入其他平台封装的第三方账号或是游戏研发方自己接入了第三方账号或自己提供了账号功能。此时发行SDK中需要做好非必须接入我方账号的功能，此时游戏研发方未接入发行方的账号系统时，则必须返回必要的用户信息给发行方，此时SDK需要考虑提供接口给开发者返回这些信息。用户信息可以视需求来定义，但是必须包含发行方需要的账号ID。

（2）确保账号的唯一

一个用户的账号的ID必须保持唯一，此时的唯一为一个账号在一个产品中必须是唯一的。

（3）账号类型的关联

不论是使用第一方注册还是第三方注册的方式，都可以在账号生成以后再绑定另一类型的账号。例如使用手机验证注册，还可以绑定邮箱、第三方账号用于之后的登录。

03

—

账号的层级

当用户注册在行号以后，此时便生成了账号的第一个信息，即唯一的账号ID。在说明用户属性的内容设计之前，先介绍一下平台账号层级的设计。

1. 平台账号与产品账号

如果发行方只能在产品维度创建账号，当需要跨产品关联用户时，则会出现无法知悉同一个用户在不同产品中的账号情况。基于这个背景，游戏发行方也可以模仿第三方服务，在创建了账号以后，用户还可以使用之前已创建的账号注册其他的同平台产品。

国内常用的QQ、微信以及网易账号都有类似的设计。例如当用户注册了一个微信号之后，可以用于腾讯内部的各个游戏，通过一个全局的平台ID关联多个账号ID，获知用户在不同产品中的账号。

如果无法提供平台账号，此时当用户注册多个产品账号时，则只能通过用户注册账号的手机、邮箱等信息来关联跨产品的账号，此时就会更加麻烦。

微信开放平台中就使用了类似的思路设计账号系统。对于接入微信开放平台能力的产品，微信给每个账号都创建产品维度唯一的openid。在跨产品时，微信根据每个账号生成全局唯一的unionid，以帮助开发者。

2. 产品账号与角色账号

一般来说，一个账号在一个产品中只需要一个账号ID。但是在服务型的网络游戏中，一个账号可以在不同的区服中创建多个角色，为了了解每个角色在不同区服中的表现，发行方还需要统计每个角色的核心数据表现。

此时就需要再使用类似账号ID的方式，提供角色账号功能。这里也反映了发行过程中发行团队的关注对象非常丰。除了像研发团队一样关注产品维度的用户表现，对于每个用户在不同的区服表现也非常关注，这是是否开新服、是否合服等运营操作的参考数据。这也可以窥见发行团队关注的数据维度之多，有渠道维度，有区服维度，还有不同粒度的时间维度等等。

3.  账号ID的作用

账号ID除了是每个账号的唯一标识之外，也是接下去整个运营系统的基础。用户的行为日志、用户属性等都需要根据账号ID来发展，这将在之后相关的内容中介绍。

04

—

用户的账号属性

（一）概述

当账号创建以后，为了实现更精细化的运营，还需要记录一些用户的行为数据，根据行为数据汇总计算成一些用户属性，例如网游中常见的用户累积充值金额、累积邀请人数等等。

比如在很多网游的宣传初期，会使用邀请好友注册给予奖励的活动。此时发行方可以给游戏方一个接口，告知累积的邀请人数，当达到一定数量以后即可发放奖励。这就是使用用户属性的一个实例。

用户的属性来自用户行为计算，这时就需要发行方记录并上报用户的行为数据，通过行为日志计算出需要的属性数据。关于用户行为上报与日志，待之后相关文章再详细介绍。有了用户属性，运营人员可以随时查询关注的用户数据，进行一些运营操作，例如查询出注册7天内的用户，发送一些营销站内信邮件，此时就可以通过查询用户的账号注册时间来获知。

在此分享我根据以往工作经历设计的一个用户属性与角色属性表的内容列表。在实际的运营过程中，读者朋友们还是需要结合实际的需求进行增删改。

用户表

属性	属性名	类型	说明	更新规则
app_id	用户所属的应用ID	字符串
account_id	账户ID	字符串	用户账号的唯一标识	首次注册时创建，创建后无需更新
distinct_id	访客ID	字符串	未登录访客的唯一标识	首次用游客模式访问时创建，生成后无需更新
active_time	激活时间	字符串时间戳	该用户的第一条数据（含事件和用户属性数据）入库时，该条数据 #time 字段的时间	首次访问时创建，无需更新
register_time	注册时间	字符串	用户注册账号的时间，时间戳
register_type	注册方式	字符串	用户注册的方式，数据来源于平台定义的账号类型枚举
channel_id	来源渠道ID	字符串	用户注册的来源渠道，数据取自渠道管理后台	1. 不论是客户端还是网页，都需要先在渠道管理后台创建渠道包或者渠道链接 2. 用户第一次安装或第一次访问的渠道ID即为来源渠道
father_user	来源用户ID	字符串	若用户通过其他用户分享邀请而来，来源用户即为这个分享者
last_login_time	最近一次登录时间	字符串	时间戳	以最近一条登录的日志为准
last_pay_time	最近一次充值时间	字符串	时间戳	以最近一条充值成功的日志为准
last_ip	最近一次登录的客户端ip	字符串		以最近一条日志IP为准
invite_amount	累计邀请人数	整型数值		根据用户分享行为实时更新
deposit_amount	累计充值金额	浮点型数值	账号累计的充值金额之和	根据用户充值行为实时更新
phone_number	手机号	字符串
email	邮箱	字符串
google_account	谷歌账号	字符串
facebook	脸书账号	字符串
line	line账号	字符串
whatsapp	whatsapp账号	字符串
qq	QQ账号	字符串
wechat	微信账号	字符串
taptap	Taptap账号	字符串
douyin	抖音账号	字符串
role_list	角色列表	对象组	账号内创建的角色ID，可传多服务器角色信息 格式：[id1, id2, id3]	通过角色信息接口上报
exp	拓展属性	对象组	如有自定义属性可用该属性保存，格式：[{对象1:值1},{对象2:值2}]	开发者可通过更新用户数据接口更新

角色表

属性	属性名	类型	说明	更新规则
account_id	角色所属的账户ID	字符串	用户账号的唯一标识
role_id	角色ID	字符串
role_name	角色昵称	字符串
role_serverid	角色区服ID	字符串
role_level	角色等级	字符串
role_vip_level	角色VIP等级	字符串
role_sum_pay	角色累计充值金额	浮点型数值
role_balance_one	角色充值货币数量	浮点型数值
role_balance_two	角色非充值货币数量	浮点型数值

（二）实践总结

1. 注册时间、激活时间想来不用过多介绍，以此来计算用户激活、注册的时长，可以定义新老用户以及活跃程度，进行一些用户分层、用户召回以及新用户激励等操作。

2. 来源渠道ID，即用户归因的来源渠道，以此来分析渠道质量。这里需要配套设计一个渠道管理系统，待到相关内容再详细介绍。

3. 来源用户ID，分享裂变是互联网软件常见的用户增长方式，通过记录来源用户，可以串联起分享链条，并了解用户的分享裂变能力。

4. 最近登录、付费时间，用来记录用户的访问、充值付费的流失情况，可以用来了解用户的沉默时长，以此为基础来做召回以及付费激励。

5. 累积邀请人数，累积付费金额，可以用来做一些个性化的运营功能。这里分享一个笔者实践经历。笔者曾经获取了某款游戏所有用户的累积付费金额，发现充值6元以下的功能占比90%，而6元以上的用户仅10%。基于这个背景，笔者将累积充值6元以下的用户会见到的充值付费礼包弹窗替换为了邀请用户或是观看激励视频广告等其他行为，以此提升了营收。类似也可以用累积邀请人数实现类似的个性化运营行为。

6. 拓展属性，这是一个预留给游戏开发方的字段。从用户属性表的信息来看，记录的都是用于广告投放以及付费、登录访问等通用行为的数据。鉴于每款游戏的玩法不同，需要定义的用户行为属性也不同，此时很难统一、系统的记录这些属性至用户表中。因此预留了这个字段，并定义为对象，可通过SDK开放接口提供给开发者来更新该字段，用于记录一些自定义的非统一信息，以帮助开发者和发行方双方记录、了解用户信息的需求。

7. 需要注意和开发团队讨论好各个字段的更新规则，避免需要获取实时数据时却因为数据更新时间有延迟导致获取过时数据。

05

—

账号的相关能力

有了账号且创建了用户账号属性表以后，还需要考虑如何将这些数据利用起来，在此分享一些发行SDK可以提供的一些关于账号的能力。

1. 获取用户信息

SDK提供一个接口供需求方获取用户信息，帮助需求方即时快速的了解用户数据，以实现一些运营操作。这里前文已有一些举例，在此就不多赘述了。

2. 更新用户信息

这是专门提供给开发者使用的一个接口。在前文介绍用户属性中有一个拓展属性的字段，通过此接口可以提供给开发者来更新拓展属性。除了发行平台方提供并计算的用户属性之外，开发者也可以更新一些自己需要的用户属性。

3. 注册、登录的组件化设计

SDK可以封装注册、登录功能以及用户界面为组件，供开发者接入，提升效率。同时还需要注意提供接口给开发者，让开发者在自身实现了账号生成功能的基础上返回用户的账号ID等必须信息给平台方，以兼容开发者不接入我方账号系统的情况。

4. 账号的封禁

为了风控以及处理一些违规用户，在运营后台中还需要设计封禁的管理后台，例如封禁账号角色登录，封禁某个账号、IP注册登录，这里接下去待介绍到运营后台时再详细说明。

06

—

最后的碎碎念

行文下来，已有数千字。行文至此还是要感叹一下自己的能力不足，总感觉介绍的不够具体和详细。很多时候想要详细介绍说明或是发散，碍于篇幅与重要性又将其浓缩，力求围绕发行与运营这个主题避免废话过多。希望读者多多包涵，如果愿意也可以与我多多交流，互相学习，有所增益。

这是系列的第二篇，说明的是账号系统。账号作为整个软件的核心地基，包含了很多功能，远不是一篇文章的篇幅能够说清楚的。希望接下去的介绍能够详细的说明。

参考资料

微信开放平台、抖音开放平台、谷歌开发者平台等开发者平台

Photo by Todd Jiang on Unsplash

“ 迈出第一步，就是一种成功。”

对于一个互联网软件而言，立身的基础是自身的功能，而依赖的核心是使用者，即为用户。为了之后可以实现精准的广告投放、数据统计以及更多的运营功能，用来标记用户的账号则是所有的核心与基础。

关于游戏运营发行系列的第二篇，第一篇是个类似目录的结构性说明，感觉没什么分享的价值，就先从整个工作的地基账号系统开始。话不多说，这便启航。

01

—

需求背景，后台与中台

1. 需求背景

在介绍账号系统的设计实践之前，必须要先说明一下需求背景。不论是互联网游戏，亦或是其他的互联网软件产品，都需要靠账号来识别并标记用户，并根据账号来设计相关的用户运营功能。

那么如何提供账号能力，供游戏或产品研发方使用呢？一般来说，如果研发方并未自己设计账号系统，则他们就必须接入其他平台的账号系统，例如常见的QQ微信登录，国外的谷歌、facebook等第三方登录，这是使用第三方的能力创建一个服务于自身产品的账号。此时这个借由其他能力创建的账号，首先属于产品需求方，即研发方。有了账号，我们就可以通过账号ID来区别标记用户，未来还可以把该账号相关的行为数据与账号ID关联起来，进而创建一个用户表，用于用户运营。同时账号ID也是所有的用户行为标记操作者的唯一ID，就好像我们的性命一样。

所以基于区别、标记以及服务于未来运营的需求背景下，我们首先需要设计用户的账号系统。

2. 后台与中台

在介绍需求背景中，目前很多产品在设计了自己的账号系统同时，也会接入第三方的账号系统。这个使用第三方能力的方式，换一句话说就是使用了第三方的后台或中台能力。

后台与中台的定义比较广泛，我也很难给一个明确的定义。为了之后的介绍，这里给一个我的定义。

后台，提供能力的服务方。这里举几个实际的例子，比如数据后台。即提供数据的服务方，用户可以通过数据后台直接了解数据。后台的特点就是直接提供能力，供需求方使用。

中台，汇聚后台能力的中间方。比如数据中台，即获取数据后台的能力，再将能力提供给需求方的，常见的情况比如有用户数据中台。假如你的团队旗下有多款内容产品，包括直播、电商及其他等等，这些产品都需要获取用户标签信息来进行广告投放以及其他运营操作。此时数据中台就可以从数据后台获取用户数据提供一个供多个产品同时使用的统一标签中台，供直播以及电商产品等其他产品来使用。

前台，获取后台或中台能力的需求方。这个就是前文举例中的直播、电商平台产品了。

由以上例子可以看到，如果你的团队负责的是一个多产品的平台类团队，此时就比较适合使用中台的方式来提供能力，对于游戏发行运营工作而言，这个中台能力的体现就是发行SDK了。

除以上情况以外，有些产品发展到较大规模以后，也会把账号、支付等通用功能以及具体的业务功能拆分，将通用功能独立为由中台负责。

对于游戏发行与运营工作而言，主要负责的就是后台以及中台的能力设计与建设了，最终就会体现在SDK功能以及相关的运营后台。

02

—

账号的创建

互联网软件一般分为无需账号以及注册账号使用功能。对于游戏而言，Steam、PS、Xbox这样的主机、电脑游戏平台，则是强制必须注册账号后方体验游戏或是限制体验。对于服务型的网络游戏而言，则会使用无需账号的游客模式以及注册账号后的跨设备数据同步模式。这里就着重介绍服务型网游的账号设计。

注册方式一般分为游戏方自己提供以及使用第三方账号服务两种，例如下图的网易游戏。

1. 官方的注册与登录

如果由游戏方自己提供注册、登录服务，一般使用手机、邮箱作为账号，辅以密码、短信验证、邮箱验证来注册或是登录。

对于注册与登录的功能设计，还需要注重用户体验。在此介绍几个比较重要的体验设计。

（1）账号的格式校验

当用户注册或登录，输入账号时，需要针对手机号、邮箱等常见账号加上输入格式验证以及格式异常提示，以避免用户输入错误不知问题是什么以及如何处理错误。

有些产品除了使用手机号、邮箱作为账号以外，也会使用唯一的用户名、唯一的数字ID等唯一标识作为账号，此时也需要根据这些账号的格式加以校验。

前端处理的是用户输入的校验，同时后端也需要配合前端加以校验，以避免产生违规的数据。

（2）风险控制

常规的账号密码登录需要注意风控，如果出现多次账号密码有误，可以再用短信验证、邮箱验证避免多次请求，以防止暴力破解，同时超过一定次数则不再处理注册或登录请求，加以限制。注册登录的服务封控本身也是一个课题，在此仅作简单介绍。

（3）信息提示

在用户注册或是登录账号时，可以在加上一些提示，例如建议的密码长度、格式，当输入信息错误或异常以后，给与相对应的提示以及解决方案，以帮助用户解决问题。

2. 第三方账号注册与登录

国内常用的QQ微信微博抖音账号，以及国外的谷歌、Facebook、Steam、Discord等都提供了服务，可供开发者接入，使用这些平台的账号同时在开发者的产品内创建账号。所以除了常见的手机、邮箱、平台自定义的用户名等账号以外，第三方平台的账号也是账号之一。

至于如何接入第三方账号，可以参见各家的开放平台和开发者平台，在此不多赘述了。

3. SDK中账号注册的注意点

（1）兼容其他的账号服务

作为游戏发行方，一般都会封装好各家第三方平台的账号功能，但是也会出现需要接入其他平台封装的第三方账号或是游戏研发方自己接入了第三方账号或自己提供了账号功能。此时发行SDK中需要做好非必须接入我方账号的功能，此时游戏研发方未接入发行方的账号系统时，则必须返回必要的用户信息给发行方，此时SDK需要考虑提供接口给开发者返回这些信息。用户信息可以视需求来定义，但是必须包含发行方需要的账号ID。

（2）确保账号的唯一

一个用户的账号的ID必须保持唯一，此时的唯一为一个账号在一个产品中必须是唯一的。

（3）账号类型的关联

不论是使用第一方注册还是第三方注册的方式，都可以在账号生成以后再绑定另一类型的账号。例如使用手机验证注册，还可以绑定邮箱、第三方账号用于之后的登录。

03

—

账号的层级

当用户注册在行号以后，此时便生成了账号的第一个信息，即唯一的账号ID。在说明用户属性的内容设计之前，先介绍一下平台账号层级的设计。

1. 平台账号与产品账号

如果发行方只能在产品维度创建账号，当需要跨产品关联用户时，则会出现无法知悉同一个用户在不同产品中的账号情况。基于这个背景，游戏发行方也可以模仿第三方服务，在创建了账号以后，用户还可以使用之前已创建的账号注册其他的同平台产品。

国内常用的QQ、微信以及网易账号都有类似的设计。例如当用户注册了一个微信号之后，可以用于腾讯内部的各个游戏，通过一个全局的平台ID关联多个账号ID，获知用户在不同产品中的账号。

如果无法提供平台账号，此时当用户注册多个产品账号时，则只能通过用户注册账号的手机、邮箱等信息来关联跨产品的账号，此时就会更加麻烦。

微信开放平台中就使用了类似的思路设计账号系统。对于接入微信开放平台能力的产品，微信给每个账号都创建产品维度唯一的openid。在跨产品时，微信根据每个账号生成全局唯一的unionid，以帮助开发者。

2. 产品账号与角色账号

一般来说，一个账号在一个产品中只需要一个账号ID。但是在服务型的网络游戏中，一个账号可以在不同的区服中创建多个角色，为了了解每个角色在不同区服中的表现，发行方还需要统计每个角色的核心数据表现。

此时就需要再使用类似账号ID的方式，提供角色账号功能。这里也反映了发行过程中发行团队的关注对象非常丰。除了像研发团队一样关注产品维度的用户表现，对于每个用户在不同的区服表现也非常关注，这是是否开新服、是否合服等运营操作的参考数据。这也可以窥见发行团队关注的数据维度之多，有渠道维度，有区服维度，还有不同粒度的时间维度等等。

3.  账号ID的作用

账号ID除了是每个账号的唯一标识之外，也是接下去整个运营系统的基础。用户的行为日志、用户属性等都需要根据账号ID来发展，这将在之后相关的内容中介绍。

04

—

用户的账号属性

（一）概述

当账号创建以后，为了实现更精细化的运营，还需要记录一些用户的行为数据，根据行为数据汇总计算成一些用户属性，例如网游中常见的用户累积充值金额、累积邀请人数等等。

比如在很多网游的宣传初期，会使用邀请好友注册给予奖励的活动。此时发行方可以给游戏方一个接口，告知累积的邀请人数，当达到一定数量以后即可发放奖励。这就是使用用户属性的一个实例。

用户的属性来自用户行为计算，这时就需要发行方记录并上报用户的行为数据，通过行为日志计算出需要的属性数据。关于用户行为上报与日志，待之后相关文章再详细介绍。有了用户属性，运营人员可以随时查询关注的用户数据，进行一些运营操作，例如查询出注册7天内的用户，发送一些营销站内信邮件，此时就可以通过查询用户的账号注册时间来获知。

在此分享我根据以往工作经历设计的一个用户属性与角色属性表的内容列表。在实际的运营过程中，读者朋友们还是需要结合实际的需求进行增删改。

用户表

属性	属性名	类型	说明	更新规则
app_id	用户所属的应用ID	字符串
account_id	账户ID	字符串	用户账号的唯一标识	首次注册时创建，创建后无需更新
distinct_id	访客ID	字符串	未登录访客的唯一标识	首次用游客模式访问时创建，生成后无需更新
active_time	激活时间	字符串时间戳	该用户的第一条数据（含事件和用户属性数据）入库时，该条数据 #time 字段的时间	首次访问时创建，无需更新
register_time	注册时间	字符串	用户注册账号的时间，时间戳
register_type	注册方式	字符串	用户注册的方式，数据来源于平台定义的账号类型枚举
channel_id	来源渠道ID	字符串	用户注册的来源渠道，数据取自渠道管理后台	1. 不论是客户端还是网页，都需要先在渠道管理后台创建渠道包或者渠道链接 2. 用户第一次安装或第一次访问的渠道ID即为来源渠道
father_user	来源用户ID	字符串	若用户通过其他用户分享邀请而来，来源用户即为这个分享者
last_login_time	最近一次登录时间	字符串	时间戳	以最近一条登录的日志为准
last_pay_time	最近一次充值时间	字符串	时间戳	以最近一条充值成功的日志为准
last_ip	最近一次登录的客户端ip	字符串		以最近一条日志IP为准
invite_amount	累计邀请人数	整型数值		根据用户分享行为实时更新
deposit_amount	累计充值金额	浮点型数值	账号累计的充值金额之和	根据用户充值行为实时更新
phone_number	手机号	字符串
email	邮箱	字符串
google_account	谷歌账号	字符串
facebook	脸书账号	字符串
line	line账号	字符串
whatsapp	whatsapp账号	字符串
qq	QQ账号	字符串
wechat	微信账号	字符串
taptap	Taptap账号	字符串
douyin	抖音账号	字符串
role_list	角色列表	对象组	账号内创建的角色ID，可传多服务器角色信息 格式：[id1, id2, id3]	通过角色信息接口上报
exp	拓展属性	对象组	如有自定义属性可用该属性保存，格式：[{对象1:值1},{对象2:值2}]	开发者可通过更新用户数据接口更新

角色表

属性	属性名	类型	说明	更新规则
account_id	角色所属的账户ID	字符串	用户账号的唯一标识
role_id	角色ID	字符串
role_name	角色昵称	字符串
role_serverid	角色区服ID	字符串
role_level	角色等级	字符串
role_vip_level	角色VIP等级	字符串
role_sum_pay	角色累计充值金额	浮点型数值
role_balance_one	角色充值货币数量	浮点型数值
role_balance_two	角色非充值货币数量	浮点型数值

（二）实践总结

1. 注册时间、激活时间想来不用过多介绍，以此来计算用户激活、注册的时长，可以定义新老用户以及活跃程度，进行一些用户分层、用户召回以及新用户激励等操作。

2. 来源渠道ID，即用户归因的来源渠道，以此来分析渠道质量。这里需要配套设计一个渠道管理系统，待到相关内容再详细介绍。

3. 来源用户ID，分享裂变是互联网软件常见的用户增长方式，通过记录来源用户，可以串联起分享链条，并了解用户的分享裂变能力。

4. 最近登录、付费时间，用来记录用户的访问、充值付费的流失情况，可以用来了解用户的沉默时长，以此为基础来做召回以及付费激励。

5. 累积邀请人数，累积付费金额，可以用来做一些个性化的运营功能。这里分享一个笔者实践经历。笔者曾经获取了某款游戏所有用户的累积付费金额，发现充值6元以下的功能占比90%，而6元以上的用户仅10%。基于这个背景，笔者将累积充值6元以下的用户会见到的充值付费礼包弹窗替换为了邀请用户或是观看激励视频广告等其他行为，以此提升了营收。类似也可以用累积邀请人数实现类似的个性化运营行为。

6. 拓展属性，这是一个预留给游戏开发方的字段。从用户属性表的信息来看，记录的都是用于广告投放以及付费、登录访问等通用行为的数据。鉴于每款游戏的玩法不同，需要定义的用户行为属性也不同，此时很难统一、系统的记录这些属性至用户表中。因此预留了这个字段，并定义为对象，可通过SDK开放接口提供给开发者来更新该字段，用于记录一些自定义的非统一信息，以帮助开发者和发行方双方记录、了解用户信息的需求。

7. 需要注意和开发团队讨论好各个字段的更新规则，避免需要获取实时数据时却因为数据更新时间有延迟导致获取过时数据。

05

—

账号的相关能力

有了账号且创建了用户账号属性表以后，还需要考虑如何将这些数据利用起来，在此分享一些发行SDK可以提供的一些关于账号的能力。

1. 获取用户信息

SDK提供一个接口供需求方获取用户信息，帮助需求方即时快速的了解用户数据，以实现一些运营操作。这里前文已有一些举例，在此就不多赘述了。

2. 更新用户信息

这是专门提供给开发者使用的一个接口。在前文介绍用户属性中有一个拓展属性的字段，通过此接口可以提供给开发者来更新拓展属性。除了发行平台方提供并计算的用户属性之外，开发者也可以更新一些自己需要的用户属性。

3. 注册、登录的组件化设计

SDK可以封装注册、登录功能以及用户界面为组件，供开发者接入，提升效率。同时还需要注意提供接口给开发者，让开发者在自身实现了账号生成功能的基础上返回用户的账号ID等必须信息给平台方，以兼容开发者不接入我方账号系统的情况。

4. 账号的封禁

为了风控以及处理一些违规用户，在运营后台中还需要设计封禁的管理后台，例如封禁账号角色登录，封禁某个账号、IP注册登录，这里接下去待介绍到运营后台时再详细说明。

06

—

最后的碎碎念

行文下来，已有数千字。行文至此还是要感叹一下自己的能力不足，总感觉介绍的不够具体和详细。很多时候想要详细介绍说明或是发散，碍于篇幅与重要性又将其浓缩，力求围绕发行与运营这个主题避免废话过多。希望读者多多包涵，如果愿意也可以与我多多交流，互相学习，有所增益。

这是系列的第二篇，说明的是账号系统。账号作为整个软件的核心地基，包含了很多功能，远不是一篇文章的篇幅能够说清楚的。希望接下去的介绍能够详细的说明。

参考资料

微信开放平台、抖音开放平台、谷歌开发者平台等开发者平台