理解一下题主场景,是指“当运营设置某标签条件后,程序进行条件检测,用户满足条件后信息实时显示在后台中,并且会使用标签功能进行用户筛选,进行消息发送”。
如果没理解错的话我继续说,理解错了烦请题主告知我删答案(捂脸)
涉及到3个功能点,1——自动打标签;2——后台信息显示;3——群发消息;
1——自动打标签:
首先,程序自动打标签就是一个触发器机制,放在不同的地方,每当用户触发,进行条件判断即可;
举例,题主列举两种触发器“会员天数”和“评论数”,前者可以在用户每天首次登录时进行判断(这种方法,一个用户在300天时未登录,310天时登录,那么他会在310天时打上标签,如果只是群发消息并不影响,看题主需求自行判断),后者可以在用户评论完成后进行判断;
当满足条件后,用户被打上标签,信息储存在服务器中,可能是用户信息表,也可能是单独的数据结构。
友好的建议:自动打标签的条件拆分为“触发类型”和“触发数值”,更便于后续拓展和发开:)
2——后台信息显示:
首先在首次打开后台时肯定会刷新,之后有如下4种信息刷新方式:
A——打开页面刷新:每次打开页面都会进行刷新,后退再打开也会刷新;
B——手动请求刷新:手动F5/下拉进行刷新;
C——时间颗粒刷新:间隔某固定的时间颗粒进行一次刷新,当颗粒小到一定程度即可理解为实时刷新;要注意颗粒太小服务器压力大,颗粒太大这种刷新方式无意义;一般用于实时变化的信息并且用户需要实时知道的,例如汇率,股市;
D——服务器触发刷新:满足某特定条件后服务器直接给客户端提供新的消息,一般用 于多端信息需要实时同步的,例如聊天;
AB两种算是手动刷新,CD算是自动刷新,如果是单纯的显示页面还好,但要是有输入操作的话,自动刷新就要考虑到操作保存/清空等问题。
3——群发消息:
鉴于题主没有描述群发消息的操作场景,做两种猜测:
A——选标签、填信息、群发:此场景下,“运营查看标签信息”和“选择标签群发消息”是完全独立的功能。即当运营查看后台时,服务器会将信息发送至客户端;而当运营进行群发时,服务器也会单独查找/筛选/遍历该标签下的所有用户并进行群发;
那么“后台刷新用户标签信息”这一需求只是一个查看需求,手动刷新即可满足,完全没有实时刷新的必要;
B——用户列表、按标签筛选、全选群发:此场景下,“运营查看标签信息”和“选择标签群发消息”是关联的功能,即服务器不会对标签用户进行判断或操作,而是单纯的对运营选择的用户进行发消息;
此场景下,手动刷新也可以满足需求,只是要求运营在每次群发前需要手动刷新一次信息……不过,如果没有其他针对标签用户进行批量增删改查的需求,完全不建议这种做法,操作麻烦,容错性低……
当然,如果我猜测的场景和题主需求有误差的话,还是要考虑到真实需求:为什么要实时刷新——是否真的有必要——是否将多个需求融合在一起了——能否继续细致拆分;
既然是后台工具,功能性清晰的优先级要高于体验的;
以上,希望能帮到您。
这不就是数据分析的用户画像么。。。
做个定时任务去刷就好了,有必要实时吗?你用户多少啊?实时的话,对服务器的压力太可怕了。不是所有公司都像BAT似的,服务器随便玩。
而且我建议你的产品基础功还是要多打劳,这种功能各种PUSH工具都具备,何必让开发去做?我记得信鸽就有类似功能。
PS:我也设计过类似的产品,比你的需求复杂多的多,都是每天定时跑脚本,有时得跑一整天,用户量在500万的样子。
你可以看看你的用户条件是否有实时刷新的价值在,如果都是提供给运营人员用的或自动触发,完全可以让后台开发者设置成为定时事件,每天资源空闲时定时进行即可,而且完全可以不使用实时线上数据,采用定期备份下来的数据,以节省服务器资源的调用。
如果时时去刷新这样的分类数据代价会非常的大,如果后端服务器能承受这种代价当然皆大欢喜,但是如果要省下服务器成本的话,可以选择手动刷新,即你要用到这个数据的时候,手动点击某个按钮请求系统给你刷新一下当前的数据,这个是可行的。不过同步的时候可能会有些缓慢,但基本应该在承受范围内。