Google Analytics 事件跟踪 - 事件之间的最小间隔

发布于 2024-10-29 11:10:26 字数 1439 浏览 1 评论 0原文

我想使用 GA _trackEvent 方法跨多个域跟踪多个事件。

由于我想要生成的报告的性质,我必须执行以下操作:

for (var i=0; var < books.length; i++)
{
   //showing values for current books[i]
   _gaq.push(['_trackEvent', 'Books Displayed', 'Fantasy', 'Lord of The Rings']);
}

因此,当填充我的图书列表时,我想要发送适当的 GA 事件。重要的是,我要单独发送每个项目,这样我就可以在事件仪表板上深入预览“幻想”类别等中的所有项目。

请注意,书籍列表永远不会超过 10 种左右。

我目前遇到的问题是,Google 代码无缘无故地忽略了我的一些请求。 Google 事件跟踪的工作方式是,每次调用 _trackEvent 时,Google 都会在页面上放置 gif:

http://www.google-analytics.com/__utm.gif

该页面包含大量参数,其中之一 - utme包含我的数据:

__utm.gif?utmt=event&utme=5(Books%20Displayed*Fantasy*Lord%20of%20The%20Rings)

使用 Fiddler(或 Firebug Net 选项卡)我可以检查此请求是否确实来自浏览器。

不幸的是,似乎每次我的大约一半请求都被谷歌完全忽略,并且 _trackEvent 没有转换为 __utm.gif 调用。

我感觉这与 _trackEvent 调用的频率有关。因为我在 for 循环中使用它们,所以所有事件都会以最小的间隔生成。谷歌似乎不喜欢它,并且忽略了我的电话。

我测试了一下,每次通话之间增加了 2 秒的间隔,结果成功了。但这个解决方案是不可接受的 - 我不能让用户等待 20 秒来发送所有事件。

不幸的是,这个缺陷使得 GA 事件跟踪完全无用 - 我不能只是“希望”GA 代码能够正确记录我的事件,因为报告不准确。最糟糕的是,Google 上没有适当的文档说明每秒允许的最大请求数是多少(它们仅 声明 每个会话的最大请求是 500,这比我生成的要多得多)。

我的问题是 - 您之前是否遇到过类似的 Google 事件跟踪问题?您是如何解决的?或者这是否意味着我必须完全放弃 GA 跟踪,因为它永远不够精确?

I want to track multiple events using GA _trackEvent method across multiple domains.

Because of the nature of the report I want to generate, I must do something like this:

for (var i=0; var < books.length; i++)
{
   //showing values for current books[i]
   _gaq.push(['_trackEvent', 'Books Displayed', 'Fantasy', 'Lord of The Rings']);
}

So, when my books list is populated I want to send appropriate GA event. It is important that I send each item separately so I can drill-down on Event Dashboard to preview all items in 'Fantasy' category and so on.

Note, books list is never longer than about 10 items.

The problem I'm experiencing at the moment is that for no good reason Google code is ignoring some of my requests. The way how Google event tracking works, is that with every call to _trackEvent, Google is dropping gif on the page:

http://www.google-analytics.com/__utm.gif

that has loads of parameters, and one of them - utme contains my data:

__utm.gif?utmt=event&utme=5(Books%20Displayed*Fantasy*Lord%20of%20The%20Rings)

Using Fiddler (or Firebug Net tab) I can check if this request is really coming out from the browser.

Unfortunately, it seems like every time about half of my requests are completely ignored by google and _trackEvent is not translated to __utm.gif call.

I have a feeling it has something to do with the frequency of the _trackEvent call. Because I am using them inside a for loop, all events are spawned with minimal interval between. It seems like Google doesn't like it, and ignores my calls.

I did test it, adding 2 seconds interval between each call and it worked. But this solution is unacceptable - I can't make user wait for 20 seconds to send all events.

Unfortunately this flaw makes GA Event Tracking completely useless - I can't just "hope" GA code will correctly record my event because the report won't be precise. The worst thing about it is that there is no proper documentation on Google saying what is the maximum allowed number of requests per second (they only state that max request per session is 500 what is a lot more than what I generate anyway).

My question is - did you experience similar problems with Google Event tracking before and how did you manage to fix it? Or does it mean I must completely abandon GA Tracking because it will never be precise enough?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

遮云壑 2024-11-05 11:10:26

首先,我想指出,每个会话 500 次的限制适用于向 Google 发出的所有请求,而不仅仅是事件。因此,这包括您正在执行的任何其他自定义跟踪,也包括正常的页面浏览点击量。

对我来说,这听起来更像是一般的 js 问题,而不是 GA 问题。类似于你推动 GA 处理代码的速度超过了它的处理速度,所以有些代码被遗漏了。我不认为你真的可以做任何事情,除了像你所做的那样延迟每次推送......尽管我认为你可能可以将该间隔从 2 秒降低到低至 500 毫秒......但是,那最多会让你等待 5 秒,在我看来,这比 20 秒要好得多,但仍然太长了。

一种可能有效的解决方案是跳过使用 _gaq.push() 并直接为每个图像输出带有 URL 和参数的图像标记。这与异步版本之前出现的“传统”GA 代码的原理有些相同,并且是当今大多数其他分析工具仍在执行的操作。

如果你想听我诚实的意见……根据我在网络分析方面的经验,我认为最有可能的是你需要重新评估你首先跟踪的内容。

根据你的价值观的背景来判断(这只是一个猜测),在我看来,你有一个页面,用户可以在其中看到书籍列表,例如搜索结果页面或可能是一般的“特色书籍”页面或类似的内容,并且您想要跟踪用户在该页面上看到的所有书籍。

根据我在网络分析方面的经验,您对收集的数据过于精细。我给您的建议是坐下来问自己“这些数据的可操作性如何?”毕竟,这就是网络分析的重点 - 帮助做出可操作的决策。

我一整天都看到客户陷入了一个陷阱,他们想知道事情的每一个细节,因为他们认为这会帮助他们回答某些问题或做出某种决定,但 99% 的情况下,事实并非如此。跟踪个人预订用户视图的事件是一回事,例如个人产品详细信息页面,您可以在其中跟踪单个事件。

或者对于搜索结果页面...将其跟踪为“搜索”事件,弹出诸如搜索的术语是什么、给出的结果数量等内容。但不提供有关实际返回内容的详细信息。

我想如果我知道有关您网站的更多详细信息以及此跟踪的用途,我也许可以给您提供更可靠的建议:/

First off, I want to point out that the 500 limit per session is for all requests to Google, not just for events. So that includes any other custom tracking you are doing, and that also includes normal page view hits.

This to me sounds more like a general js issue than a GA issue. Something along the lines of you pushing code for GA to process faster than it can process so some are falling through the cracks. I don't think there really is anything you can do about that except for delay each push as you have done...though I think you could probably lower that interval from 2s to maybe as low as 500ms...but still, that would at best drop you down to a 5 second wait, which IMO is a lot better than 20s but still too long.

One solution that might work would be for you to skip using _gaq.push() and output an image tag with the URL and params directly for each one. This is sort of the same principle as the "traditional" GA code that came before the async version, and is what most other analytics tools still do today.

If you want my honest opinion though...in my experience with web analytics, I think the most likely thing here is that you need to re-evaluate what you are tracking in the first place.

Judging by the context of your values, (and this is just a guess) it looks to me like you have for instance a page where a user can see a list of books, like a search results page or maybe a general "featured books" page or something similar, and you are wanting to track all the books a user sees on that page.

Based on my experience with web analytics, you are being way too granular about the data you collect. My advice to you is to sit down and ask yourself "How actionable is this data?" That is, after all, the point of web analytics - to help make actionable decisions.

All day long I see clients fall into the trap of wanting to know absolutely every minute detail about stuff because they think it will help them answer something or make some kind of decision, and 99% of the time, it doesn't. It is one thing to track as an event individual books a user views, like an individual product details page, where you'd be tracking a single event.

Or for search results page...track it as a "search" event, popping stuff like what the term searched was, how many results given, etc.. but not details about what was actually returned.

I guess if I knew more details about your site and what this tracking is for, I could maybe give you more solid advice :/

初见终念 2024-11-05 11:10:26

这可能是由于每秒 1 个事件限制

“每个会话的事件数限制”

除了一般收集限制和配额之外,以下限制还适用于 ga.js 中的事件跟踪:

发送到 Google Analytics(分析)的前 10 个事件点击会立即进行跟踪,此后跟踪速率限制为每秒命中一个事件。
当会话中的事件数量接近收集限制时,可能无法跟踪其他事件。因此,您应该:

避免编写视频脚本来为播放的每一秒发送一个事件以及其他高度重复的事件触发器
避免过多的鼠标移动跟踪
避免产生大量事件计数的延时机制

(来自 https://developers.google .com/analytics/devguides/collection/gajs/eventTrackerGuide

这就是为什么你的 2 秒延迟有效。理论上你可以将其减少一半,尽管安全因素可能会减少这一减少。

This is probably due to the 1 event per second limit

"Events Per Session Limit

In addition to general collection limits and quotas, the following limit applies to event tracking in ga.js:

The first 10 event hits sent to Google Analytics are tracked immediately, thereafter tracking is rate limited to one event hit per second.
As the number of events in a session approaches the collection limit, additional events might not be tracked. For this reason, you should:

avoid scripting a video to send an event for every second played and other highly repetitive event triggers
avoid excessive mouse movement tracking
avoid time-lapse mechanisms that generate high event counts

(from https://developers.google.com/analytics/devguides/collection/gajs/eventTrackerGuide)

That is why your 2 seconds delay works. You can theoretically cut that in half, though a factor of safety would probably reduce that cut.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文