Google Analysis 使用：Too many hits sent too quickly 解决

场景：产品定了很多埋点，埋点会有场景在短时间内触发很多次上报动作，比如视频列表的滑动，需要统计用户看过多少个视频卡片、哪些卡片自动播放、播放时长、播放比例。这些都是一个单独的埋点事件上报，很容易触发GA令牌机制的上限。

问题：GA对android、ios的sdk有个令牌机制，初始赋予60个令牌，上传一次埋点会消耗一个令牌，同时会以两秒一个令牌的机制补充令牌数量，但是令牌池最多是60个。如果短时间内消耗掉了所有令牌，埋点上传的频率高于令牌补充的频率，可能会造成丢失。

解决思路：埋点进行拆分重要性和时效性，根据权重优先重要性和时效性高的埋点进行优先上报，其他埋点缓存下来延后上报。

先查下GA还有啥具体限制，根据限制再考虑下细节，只关注AndroidSDK的限制：点击打开链接

https://developers.google.com/analytics/devguides/collection/analyticsjs/limits-quotas

公共的限制：

1. 每个Tracking ID每个月10million的hit；（产品现在的体量暂时不考虑）
   
2. 每个用户每天20万的hit；（不存在的）
3. 每个session 500个hit；（这个session怎么定义？怎么给一个用户多个session？我们的场景是有可能触发这个限制）

SDK的频率限制：

1. 对于一台设备上的每一个tracker，每个app初始化60个hit令牌，同时以2秒一个的频率进行补充，但是最多到60个。这个规则适用于除了电子商务外的所有hit；（我们产品埋点的频率会很轻易超过补充的频率，导致埋点丢失，这个已经验证过）

这个就是对“令牌桶算法”(中文链)的理解，ga允许你突发上传大量埋点同时又限制太频繁的上传。所以我们延迟上报的是可行的，等到令牌补充差不多了再把优先级不高的埋点进行上传。所以看完GA的文档之后，我们需要照顾到的地方有两个：

1，每个session 500个hit；

2，令牌桶的机制；

［未完待续］