运营后台系统的简单介绍

本文目录一览：

• 1、手机营运商各营业厅的工作人员是用什么方法查询各个手机号码的卡里的余额的?
• 2、如何更有效的优化后台
• 3、后台系统资源/数据权限系统设计
• 4、电商平台运营管理系统有哪些？
• 5、会员体系：会员系统在后台系统中的四大模块

手机营运商各营业厅的工作人员是用什么方法查询各个手机号码的卡里的余额的?

用运营商后台系统查询。运营商工作人员他们的后台系统是可以直接查看到用户的消费情况和话费余额。

如何更有效的优化后台

刚到公司的时候为了追求快，所以后台系统的设计跟性能是一塌糊涂。后来反思了一下准备推翻重新写运营后台系统！

1、确定框架

因为之前一直在用cake，因为运营后台系统我自己喜欢使用新鲜的东西，所以选用了3.0，但是不得不吐槽中文文档是真的少，所以权衡利弊最红还是选择的了thinkphp5.0，最起码有完整的中文文档，并且也是中国人开发的。

2、解耦模块

把所有的数据层、控制器层完全分离出来

3、分析性能差的原因

后台系统一共分为 商品中心、订单中心、运营中心、用户中心、销售中心。

公司的性质为电商平台，平时主要数据为订单数据、商品数据。而后台慢的原因主要是以下原因：

①列表页无分页

②大部分使用异步

③数据过大

④服务器配置过低(公司规模不是很大以技术层面不动服务器的东西)

4、解决

①添加列表分页

②把百分之90的异步换成了form表单提交，这样代码简洁、不易错、效率快

③对于查询数据量过大的运营后台系统我要着重讲一下：

后台系统的用户中心、销售中心是查询数据量最大的程序，因为查询的都是整年的销售、用户分析数据，基本上数据百万条(自我吐槽一下每次查询时间长一点都得用将近1分钟)。

我首先做的尝试优化程序，把所有的程序多于的逻辑进行删减，最大的程度减少foreach去循环数据，去用SQL直接可以处理。经过这样的处理程序的执行时间从1分钟到20秒左右。

但是感觉20秒还不是极限，又静下来想了想办法，最终决定把每天的统计数据用定时程序去统计，然后程序只需要查询统计完的数据结果，经过这个修改完，销售重新从之前的 20秒快到 1秒！！！！

接下啦就是用户中心，用户中心的核心处理办法和销售中心是一样的，但是感觉速度依旧不理想，后来发现用户中心的数据实在是太咋了，所以把不同功能的模块都分离，放到不同的页面，速度也提升到了1-3秒。

后台系统资源/数据权限系统设计

鉴于后台的权限，数据分级越来越细化，越来越错综复杂，我对现有的项目后台进行了一个初步的升级。参照传统的CRM管理系统改造了权限系统。

在一套后台管理系统中，系统通常会有多种需求的用户登陆。例如系统维护人员、运营分析人员、文案编辑人员、部门管理人员等等，而系统维护人员登陆要看到日志界面和服务器监控界面，文案编辑人员要看到文章界面等等，不同的用户登陆到后台还需要展示不同的菜单和界面，

单单运营分析人员，在系统中可以可能有A分公司运营助理、B分公司运营主管、C部门运营经理、华东大区运营总监等等类型，A分公司的运营助理只能看A公司的运营数据，C部门运营经理只能看到C部门的运营数据，大区运营总监应该要看到属于华东大区的所有公司以及部门的数据，不同人员能够查看的数据范围应该是不同的

其次，上述提到的的文案编辑人员，还会区分出总编辑，和文案撰稿人，虽然同样能看到文章管理界面，但总编辑拥有添加、编辑、删除、审核、发布等功能，普通文案只有有添加、修改的权限。

本文将对上述提到的场景提出一种基础的解决方案。

【 角色】： 系统运维、运营分析、部门职员这类拥有不同权限功能的标签，我们称之为“ 角色” 。

【 组织部门】： A分公司、C部门、华东大区、无论大小我们统称为“ 组织部门” 。

【岗位】： 运营助理、运营主管、运营经理、运营总监我们统称为“ 岗位” 。

【 数据权限】： 大区运营和部门运营所能看到的数据范围不同，我们称之为“ 数据权限”。

【 资源权限】： 文章管理撰稿人比总编辑少了审核、发布的功能，这些功能我们称之为“ 资源权限” 。

有了角色，部门组织，岗位，数据权限，资源权限这5个概念的结合就可以结合出满足一般使用场景的权限设计。

      我们将数据权限、资源权限接关联在一个角色上，然后将关联好的角色与用户绑定，这样就完成了权限对用户的分配。另外，我们也可以将角色关联在某个部门的岗位上，然后用户只要填写所属部门和岗位即可获得权限。

     比如文案总编辑、撰稿人、审稿人、编辑助理这类有特定的功能职能的用户群体，我们能就可以创建成角色。但要注意的是，角色一般是可以多个同时并存的。比如创建一个新文案负责人，组织允许他既可以自己撰稿，也可以帮助别人审稿，这时候往往不会在当独为他设计一个撰稿审稿人角色，而是同时为他分配撰稿人+审稿人两个角色。这样，该用户的权限就变成了他所有角色关联的权限之和。从而减少因为权限的交叉带来的冗余角色。

    岗位和角色的概念其实是挺相似的，一个岗位一定程度上代表了他在组织中的角色。然而同样的岗位在不同的组织部很可能是不同的：   例如A部门的采购主管和B部门的采购主管。同样是主管的岗位，但A采购公司规定可以查看整个部门数据、不允许查看订单，而B采购可以查看订单数据、但不允许查看部门其他采购主管的数据，从而造成了同岗不同权。

    这时，我们可以单独为这些部门各自创建岗位，并将角色组直接关联在各自的岗位上。例如在A分公司中分配一个岗位叫做采购主管， 然后我们为这个岗位预设好 “采购数据分析员”，“采购数据录入员”，“订单审核人员”的角色。 这样以来，当A公司来了一位新的采购主管，我们只要为他创建好账号，然后为他设置这个岗位就可以实现权限的绑定。

    撰稿人可以编写文章，审稿人只能查看和标记审核结果，区分两者权限不同，依靠的就是资源权限的不同。我们可以在撰稿人角色上绑定“文章:编辑、文章:查看、文章:添加”这三个资源权限，为审稿人角色绑定“文章:查看、文章:审核”两个资源权限，然后在系统中判断用户的权限来控制相应的入口显示。例如判断用户的权限中不包括“文章:审核”权限，页面就隐藏掉审核的开关按钮。

    数据权限我们目前只分三种，“仅自己数据”，“部门数据”，“全部数据”。如字面含义一样，“仅自己数据”只能查看与自己直接关联的数据，比如自己的销售额，自己的考勤记录。“部门数据”允许用户看到整个部门乃至下级部门的所有成员的数据，比如整个部门的销售额，部门中某个用户的考勤记录。“全部数据”属于最高级别的数据权限，一般是平台的总公司总经理、或者某个系统的总负责人可以使用的到。需要注意的是，数据权限需要结合“资源权限“以及下面将提到的“组织部门“一起组合使用才能发挥效果。

   组织部门可以区分用户在系统中的不同组织、不同等级关系。比如一个平台往往可以接入众多的公司，如图

组织与组织之间有明显的层级架构关系，结合数据权限、资源权限、角色、岗位、就可以灵活配置出例如图中销售部门A的销售经理权限，以及销售团队1的队长权限等等。

上述的结构只是一种方案，当然方案不可能是万能的，具体的实现还需要结合实际项目需求进行设计开发。

电商平台运营管理系统有哪些？

要说比较恰当的就是8manageO2O电商管理系统了，主要是根据电商运营者的需要开发的线上线下管理系统，功能齐全，适合电商运营者使用

会员体系：会员系统在后台系统中的四大模块

现在各行各业都在做会员制，零售，电商，影音娱乐，无不会员。会员制的目的其实与私域流量有很大关系，商家们想把会员即粉丝锁定在自己的体系内，同时会员制也是商家的一种盈利模式。为商品的销售，品牌的宣传推广打下基础，同时也能节省更多的资源，达到事半功倍的效果。

会员体系这一系列主要是将工作中针对会员部分的设计及理解总结下，方便后续学习应用。

会员体系并不是将系统设计完就可以了，系统设计只是基础，最核心的部分是如何进行会员的运营。运营的前提就是将基础打好，实际运营时灵活运用，基于AARRR模型，高效运营会员。

会员系统在整个体系中主要分为几大模块呢？如何进行会员的运营呢？

本次主要讲解会员体系的搭建，至于会员运营需要结合促销，优惠券玩法等相关营销方式进行会员的拉新促活转化留存收入等。

在我们经常使用的app中也能看得出，会员主要分等级，权益，积分，余额。后台针对这几点主要划分为会员等级，会员资产，会员基本信息(画像)，会员标签。

会员等级在会员运营中起着重要作用，不同的会员类型升降级规则会所有不同，如付费会员，注册即会员，充值会员。

等级基本设置可以定义为等级类型，类型我们上面也降到主要分为付费会员，免费会员，储值会员几类，常见的就是付费会员及免费会员。

付费会员： 付费会员可设置为按月/季度/年会员，充值金额不同，会员有效期不同，会员有效期主要是为了享受会员权益的一个时间。如山姆会员店，需要花260元成为会员才能有资格进店消费。

为何要做付费会员，付费会员首先会员费为商户营收的一部分，其次成为付费会员可以享受的权益一般是高于注册会员及充值会员的，比如京东plus会员，plus会员可以享受的权益与其他普通会员的权益就不同，同时plus会员还有会员专享价。商户做付费会员除了基本的收入外主要还是为了沉淀会员，将会员留存在自己的体系内，形成不断的消费，稳定流量，从而在提升新品及促销时才能提升更好的效果。

充值会员： 有些零售商在运营时会按充值计算为会员，累计充值一定金额即可享受会员权益。做充值会员的一般是零售商，比如物美永辉等零售商超，核心目的就是沉淀资金，保证资金流，用于经营。其次就是沉淀会员，像我一般去物美都是购买美通卡，他们一般会有活动。充值一次消费不完就回进行二次消费。以此来培养会员消费习惯，一般购物也会到自己比较常去的店。

注册会员： 这一类会员最常见，注册即可成为会员，享受会员权益，不同的会员类型享受的权益也可能不相同，在设计会员等级升级规则时单独设置即可。注册会员一般商户会对会员进行拉新营销活动，如注册会员赠送优惠券，大家熟知的如瑞幸咖啡，新注册会员赠送一张免费券，可以免费喝一杯咖啡。通过注册会员后续结合会员标签在做针对性运营，保证用户留存。

会员等级管理中，比较特殊的是付费会员。针对这一类会员可以做升降级设计，但是一般不需要，只要设计有效期及会员权益即可，所以可以暂时不考虑。

其他会员的升降级规则就需要进行设计了，一般零售商有升级规则没有降级规则。

会员等级管理中主要分为等级基本信息，会员升级礼包设置，升级规则，降级规则，会员权益。降级规则需要根据实际业务情况考虑是否设计，设计降级规则的目的是为了活跃会员，让会员形成持续消费。

升级规则： 这里的设计我们可以定义按积分，储值，消费，实际应用根据商户实际的成本考虑采用哪一种升级方式。这里升级也需要设定固定周期内，不建议设置长期，长期对于商户运营无法起到积极的作用，建议缩短这个周期。

会员权益： 不同会员等级享受不同权益，等级越高权益越高。享受的折扣，优惠越大。这里结合会员等级设置，目的引导会员升级，升级后对会员享受了权益，对商户留存了会员，提升了销售额。

升级礼包： 这里升级礼包是针对会员升级到当前等级的奖励，提升用户体验及留存。

会员资产一般我们将余额，积分，优惠券等划分为会员资产，会员可以通过前台看到自己的资产，后台商户可以查看每个会员的资产情况。会员在一个商户里所持有的余额，积分，优惠券等，包含余额，累计充值，消费等情况。积分，累计积分及消费积分，赠送积分等。这些都是一方便会员查看自己的消费情况，其次对于商户来说这字段可以用于商户定义会员标签，用于会员的精准营销。

会员基本信息主要包含基础信息及会员资料两部分，基本信息可以通过后台或前台填写。涉及到的注册来源，会员级别等信息需要根据后台设置的等级规则及注册路径来校验返回。这里基本信息在会员画像的部分就比较重要，为后续做会员运营也做来准备。

针对某一个会员我们进行该会员的具体画像定义，这个就要依赖我们强大的后台系统，需要整合当前会员所有的属性特征进行汇总。

会员的画像我们可以划分为基本属性，会员资料，会员标签，会员资产，消费行为以及购偏好。这些信息都是为会员标签的定义提供的基础信息，方便商户对会员进行精准运营提供标签数据。

现在比较常见的是给会员打标签，也算是总结会员画像最重要的一部分，分为自动打标签及手动打标签。

自动打标签：给增量及存量会员打标签，基于实际运营需求制定标签。我们常用的会员属性，消费能力，消费偏好，消费频率，购物渠道等进行自定义。

自动打标签我们可以根据会员的基础属性如性别，年龄，等级。交易属性，消费时间，金额，频次，客单价，这些信息可以分析出会员的消费能力，针对不同商品做不同促销提供有效的数据。购物偏好，偏好信息主要包含品牌，品类，商品，分析会员经常消费的一些品类等。用于后续新品推广或特价促销等活动按标签做精准营销。

手动打标签：另外一部分就是手动给会员打标签，主动打标签就是在一些特殊情况下对特别的会员进行单独标签定义。

这里我们举个例子，如商家新推一款A品牌奶粉，是用12-36月龄，价格在300左右，结合会员标签定义将存量用户打标签，针对当前这一类我们定义为M，做赠送优惠券，或促销短信推广。通过这种方式进行精准化运营。

以上内容可以为会员精准营销提供依据，降低商户的运营推广成本。达到事办功倍的效果。

以上是针对会员体系中的基本属性设置，下一章将会对会员的营销进行梳理。基于AARRR模型进行汇总整理。

欢迎留言指导～～～～好好学习，天天向上