一、缘起
一天，一个同事跑过来问我说，使用GA API取到的唯一身份事件数（Unique Events）和GA 报表显示的不一样，问是咋回事。我按照他说的重现了一下，发现确实不一样。API（以下使用Query Explorer 来展现GA API读取到的数据）和报表的查到的数据分别如下所示：
可以看到报表中的Unique Events为68，而API取到的Unique Events为38.
因为对GA API不熟，而且印象中2016年下半年记得GA Unique Events的定义记得有发生过变化。因此，当时我怀疑，应该是报表和API计算Unique Events的逻辑不同导致的数据不一致。
二、探究
后来仔细翻了下Unique Events的帮助文档和GA Reporting API的change log，并亲自动手实践了一下使用Python读取GA 数据，确定是两处计算逻辑不同导致的数据差异。
简单地说就是，目前GA 报表计算Unique Events时会同时考虑Events有关的所有维度，即事件类别、事件操作和事件标签，而目前GA Reporting API中计算Unique Events可能只会考虑Events有关的部分维度，具体与查询中的条件有关。
举个例子，假设有2个用户A、B，分别有1个session，A在session中触发的事件（格式为事件类别-事件操作-事件标签）为：
video-play-video1和video-play-video2
B在session中触发的事件（事件格式同上）为：
video-play-video1
要计算事件类别为video且事件操作为play的Unique Events
根据目前报表中Unique Events的计算逻辑为2+1=3个，而根据目前GA API的计算逻辑Unique Events为1+1=2个
可以看到，报表算出的Unique Events比API算出的要大。
三、解决和建议
那么，如果要从GA API中也读取到和报表中Unique Events计算逻辑一样的数据，该怎么查呢？答案是使用ga:uniqueEventsTemporary来查。仍旧以第一部分提到的数据为例，使用GA Reporting API的Python版本查询得到结果如下：
之所以没有使用上边Query Explorer演示API查询的结果，是因为ga:uniqueEventsTemporary这个字段是private metric，Query Explorer中没法使用该指标查询。
就像这个指标名称中所表明的那样，这只是一个临时使用的，预计2017年3月之后API 中Unique Events的计算逻辑也会更新为最新的，和报表保持一致，到时候自然就不会出现报表和API中同时查询Unique Events返回数据却不一样的问题了。
另外还有一个值得一提的是，Unique Events表明的并不是Unique 的Users，说是Unique 的Sessions更为接近。如果要看某个Event有多少用户触发了，直接配置一个自定义报告使用用户数（Users）作为指标就可以了。