为了统计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流量没了，玩半小时手机，几百兆流量没了，爽！
恶心用户并不难，思路比结论重要。
近期阅读：
《“三大分离”架构设计准则？（5000字长文）》
《程序员的薪酬大揭秘（全球调研）》
《REST之父，搞了一个HATEOAS架构？（只聊技术）》
调研：
贵司是怎么恶心用户的？
画外音：重复埋点？随意埋点？实时上报？
