=Start=
缘由:
简单记录一下工作中遇到的一些问题和思考,方便以后参考。
正文:
参考解答:
在新的竞争环境下,各app都少不了对外分享的功能,结合运营上的各种活动,用于达到拉新促活裂变等业务目标。而底层分享行为的日志记录和分析就为运营人员提供了数据支撑和方向指引。这里简单记录一下常规分享行为日志的字段设计,如果业务上有特殊需求,可以按需调整。
一个完整有效的分享,一般包括以下3部分:
- 原始用户发起分享
- 其它用户打开分享
- 其他用户通过分享打开app
在发起分享的日志中一般有几个核心字段:
share_id #分享ID(保证唯一即可,很多使用MySQL表的自增字段)
share_timestamp #分享时间
user_id #用户ID
device_id #设备ID
global_id #全局设备ID(集团内跨app唯一)
share_biz_code #业务线
share_url #分享URL
share_channel #分享通道
share_channel_type #分享通道类型
share_method #分享方式
share_form #分享形式
network_type #网络类型
isp #网络运营商
ipv4
ipv6
latitude
longitude
...
在打开分享日志中的几个核心字段:
open_user_id #打开分享的用户ID
open_timestamp #打开分享的时间
open_type #H5页面/小程序
share_biz_code #业务线
share_url #分享URL(通常是短链接)
real_web_url #真实URL(通常是一长串带着各个参数的长链接)
real_web_query_params #真实URL中的各个参数
share_id #分享ID(可以和发起分享表中的记录做关联)
share_timestamp #分享时间
share_user_id #进行分享的用户ID
network_type #网络类型
isp #网络运营商
ipv4
ipv6
latitude
longitude
...
常见的几个分析场景:
- 对某个活动,是哪个用户先对外做的分享?分享形式是什么样的(QQ/微信/朋友圈/站内私信/……)?
- 分享效果怎么样?哪些分享被外部的人打开了?外部人员看到了什么信息?
- 通过分享链路,可以看到哪些用户可能是有关系的(一度分享、二度分享)?
对外分享功能对内部敏感活动的一些影响和提醒:
- 重大活动一般会先在内部进行灰度测试之后没什么问题了才会对外开放,灰度测试期间要想尽量避免信息泄露,需要做好参与用户白名单、保密协议签署、网络隔离、日志埋点、外发审查等安全措施;
- 大型活动一般会分多期进行运营,不同的活动页面/资源需要进行区分,不要直接进行覆盖,如果需要保证最终收口,要么多加一次跳转,要么做好变更信息记录,方便后面回溯的时候能有个区分;
- 运营和PR等同学要做好预备方案,同时做好舆情和数据监控,以便在出现泄漏问题时能第一时间感知和应对。
参考链接:
审计日志通用格式
https://ixyzero.com/blog/archives/3683.html
=END=