一、缘起
一天,一个同事跑过来问我说,使用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)作为指标就可以了。