消息通知的几种形式
消息通知，通常来说包括以下几种形式：
形式一：系统 PUSH，极高的曝光率&极低的打开率
IM 消息提醒、评论互动、运营通常采用这一方式。IM 消息提醒如微信、QQ、钉钉的聊天消息，对及时性的要求极高。互动评论常见于社交类应用，比如微博。
用户对这两者的容忍度相对较高，且 IM 消息 > 评论互动。
系统 PUSH 的优点在于它的到达率和曝光率，只要没有被关闭通知权限，几乎能够 100% 让用户看见。
这样的后果是打开率极低，并且一旦频繁推送，就面临着被用户关闭通知权限、甚至直接被卸载的后果。
形式二：应用内弹窗，重要的版本更新提示通常采用这种方式
京东的版本更新提示，饿了么每天首次打开时的红包，Uber 的活动推广……都会采用应用内弹窗。应用内弹窗的曝光率极高，但破坏性也极强，因为它打断了用户的正常使用流程，并且必须按关闭/确认才能关掉弹窗（更优雅的交互方式是点击屏幕空白处）。
方式三：站内信通知，取决产品本身的架构，通常由官方账号发出
站内信通知，是更为普遍的一种活动运营方式。
而 app 的日常运营，也是靠该账号推送内容，比如网易云音乐的小秘书、知乎的知乎团队/知乎 Live 团队。
方式四：小红点+浅灰色文字，通常标记在入口处
在功能入口上加小红点，在列表式的功能入口上加小红点/右侧浅灰色文字，是更常见的一种方式，比如微信默认朋友后有更新时会在发现栏上出现红点提示，以及微信读书的版本更新会在相应的入口处都添加小红点。
其他：手机短信通知、邮件订阅
这两种方式不再赘述。
本文重点阐述站内信的前后端设计逻辑。
什么是站内信
“站内信”不同于电子邮件，电子邮件通过专门的邮件服务器发送、保存，而“站内信”是系统内的消息，其实就是通过数据库插入记录来实现的。“站内信”有两个基本功能：
- 点到点的消息传送。用户给用户发送站内信，管理员给用户发送站内信。
- 点到面的消息传送。管理员给用户（指定满足某一条件的用户群）群发消息。
站内信怎么设计
1. 站内信
关于用户的资产信息，商品物流等动态更新通知。
如交易、物流、收发货等通知，一方面用户能及时知晓商品的第一动向，另外也能在一定程度上较少企业的短信成本;
如积分变动、优惠券到期前通知，凸显用户资产信息重要性的同时，又唤醒沉默用户进行消费优惠券，从而促进订单转化。
- 一般用户只有阅读和删除权限；
- 发送是由系统设置的触发条件或者运营人员在用户营销时手动发送；
- 只能用户自己看到；
- 在WEB端在个人中心一般为“站内信”形式；移动端个人中心页面的消息图标并附带未读的条数；
- 站内信内容不多，点击标题下拉收缩展开。
2. 公告
应用场景较广，便捷性较强，当企业存在公告类内容，可及时进行全量或定量推送，让平台内的用户知悉。
- 一般放在网站首页顶部区域，
- 游客模式下也可看；
- 只有网站管理员才可编辑删除；
- 内容较多，点击跳转新页面。
3. 设计思路
我们希望用户收到个性化的营销信息，唤醒沉默用户，而有的信息我们希望有游客也可以看到，便于未注册用户的注册转化。
笔者在互金公司做产品狗时，平台的运营活动较多，每个月有一固定大活动，两三个小活动，并针对这些活动发布站内活动通告，针对待收少于**的用户做单独的活动推送，可否将两者的通知渠道整合一下，优化下空间资源。
之前在首页右侧有公告图标，点击打开是公告列表，在个人中心页面右侧有个人消息，点击为个人的信息变动情况。
笔者在改版过程中，将公告通知模块与站内信模块设计在一起。
