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