为了统计APP内用户行为,或者需要收集某些产品数据,APP往往需要进行日志上报,如何设计APP日志上报,才能把用户手机流量刷爆呢?
知识体系化非常重要,今天系统性和大家聊聊APP日志上报。 问题一:APP可不可以不上报日志,只从服务器日志统计用户的行为和产品数据? 不行,有些用户行为不会与服务器进行交互,例如“卡片切换”,服务器日志无法完成所有统计。
问题二:APP一般如何上报日志? 常用方法有这么几种。
(1)使用类似于Google Analytics的第三方工具;
优点:无需开发
缺点:不能做个性化统计
(2)自己制订私有协议进行上报;
优点:节省流量
缺点:开发成本高
画外音:例如,TCP二进制协议,可定制化,又省流量。
(3)使用HTTP协议,通过GET参数传递需要上报的数据。
问题三:如何通过HTTP协议进行上报?
可以在Web-Server下放置一个文件,APP发起HTTP请求访问这个文件,通过GET参数传递数据,并通过分析access日志来得到想要的数据。
问题四:如何通过GET参数传递数据?
一般又有两种方式:
(1)约定格式法;
(2)KV法。
问题五:什么是“约定格式法”?
约定格式法:约定分隔符,约定占位符,约定每个字段的含义,例如:
http://kuaigou.com/up?[bj][20240907][1939][1][login]
约定如下:
(1)被访问文件是up;
(2)分隔符是[];
(3)第一个字段[bj]代表城市,第二个字段代表日期,第三个字段代表时间,第四个字段代表用户id,第五个字段代表行为。
该方法缺点是:扩展性较差,有时候某些字段没有值,也必须在相应的位置保留占位符,因为每个字段的含义都是事先约定好的,要想新增统计项,只能在GET后面新增[]。
问题六:什么是“KV法”?
KV法:通过GET参数自解释的KV方式来上报数据。
上面的例子用KV法来上报,则上报形式为:
http://kuaigou.com/up?city=bj&date=20240907&time=1939&uid=1&action=login
该方法的优点是:扩展性好。
缺点是:上报数据量比较大,非常消耗流量。
问题七:为什么会这么消耗流量呢?
之所以消耗流量,主要有这样一些原因:
(1)无效流量多,HTTP报文有很多无效数据; (2)URL冗余,每次都要上报URL; (3)KEY冗余,每次都要上报KEY; (4)上报频度高,用户每次操作都要日志上报的话,上报量很大。
问题八(重点):怎么把用户的手机流量刷爆呢?
了解了消耗流量的上述1-4点,就能够针对性恶心用户了。
方向1:尽量增加HTTP请求内无效数据。
实施方案:避免手动构造HTTP请求,尽可能保留HTTP中的无效数据。
画外音:
举例,使用第三方库构造HTTP请求,可能会带上你并不需要的UA数据。
自己构造,则可以只保留GET /up HTTP/1.1和GET传递的必须数据;
通过这种方法,把HTTP报文增大0.2K。
方向2:尽量使用长URL来冗余数据。
实施方案:使用尽可能长的域名来接收上报的日志,例如:
http://www.woshiyuming/rizhishangbao
画外音,不要使用这种:s.kg.cn/a
通过这种方法,把HTTP报文增大0.1K。
方向3:上报尽可能冗余的KEY。
实施方案:使用尽可能长的KEY来标识数据,日志收集方不要统一规范KEY,尽量让每次需求都重复上报。
例如,城市上报要使用:
chengshi=beijing
不要优化为c=bj。
再例如,不要做基础数据规范,可以不同项目中重复埋点,上报多次:
name=shenjian&user_id=123&uid=123&user_name=shenjian
而上述name、user_id、uid、user_name都可以不同项目重复上报。
通过这种方法,把HTTP报文增大0.5K。
方向4:增加上报频率。
实施方案:不要将数据保存到APP本地存储,定时上报,不要对于PV类,SUM类,AVG类统计在端上做预处理。
例如,要统计登录按钮的点击次数,三次点击,可以上报三次: http://kuaigou.com/up?date=20240907&uid=1&action=login http://kuaigou.com/up?date=20240907&uid=1&action=login http://kuaigou.com/up?date=20240907&uid=1&action=login
通过这种方法,把HTTP上报频率增大20倍。
不要预处理,不要增加参数只上报一次,这样太省流量:
http://kuaigou.com/up?date=20240907&uid=1&action=login&count=3
非实时上报,应该在什么时机进行日志上报呢?
如果进行合并上报,或者批量上报,数据的时效性会有一定的影响。
画外音:如果策略合理,数据误差会非常小。
可以在这样的一些时间点进行上报: (1)特殊时间点上报:例如,APP打开,关闭,后台转入活跃时; (2)按时间批量上报:例如,每隔10分钟才上报一次; (3)按数据量批量上报:例如,每收集10条记录才上报一次;
还有其他什么恶心用户的方案? 不要批量上报,不要数据压缩。
综合下来,上报一次几K流量没了,玩半小时手机,几百兆流量没了,爽!
恶心用户并不难,思路比结论重要。