Blog

Despite this documentation to the contrary, Event.EXIT_FRAME does not exist in Flash Player 9/AIR 1.0. It was introduced in Flash Player 10/AIR 1.5. If you are writing a SWF that targets Flash Player 9, attempting to use the Event constant will fail, but if you hard-code the “exitFrame” string, it will appear to work—until you start getting complaints from people that still haven’t updated to Flash Player 10 that your events aren’t firing.

I suppose it raises a question about why one would ever choose to use the EXIT_FRAME event. According to Johannes Tacskovics, the EXIT_FRAME event occurs at the end of the lifecycle of constructing the current frame before it is displayed. This seems somewhat counter-intuitive, in that the name implies that the event would occur just before a frame is destroyed.

Either way, since I was looking for an event that would provide me with the ability to perform frame-exact synchronisation to MP4 video, this event was no more useful than ENTER_FRAME. (Adobe, for some reason, decided not to implement onCuepoint for MP4 playback.) Unfortunately, frame events like ENTER_FRAME don’t appear to correspond precisely to when a video frame is rendered, and Flash’s timers are not precise enough either, so the ultimate result was a player with overlays that were sometimes out-of-sync by one frame. Bad, but not disastrous. Still, it would be nice if there was a way to get frame-exact synchronisation with MP4s. Maybe someday…

This article is a follow-up to Testing the Reliability of Google Analytics.

With two months of data analysed, Google Analytics has recorded 0.334% fewer pageviews than StatCounter (600/179650). Discounting two outliers (one day where Google recorded 24% more pageviews, and the next day where Google recorded 6% fewer pageviews), this number increases slightly to 0.6153% (1074/174550).

While not identical, the overall numbers are similar enough that I feel confident that Google Analytics reporting is accurate—or at least, accurate enough to be able to safely draw meaningful conclusions from the data that is collected.

I’ve run a problem multiple times now with Flash Player and animating the alpha property of an object that contains text. For some reason, when using “Anti-alias for readability” or “Custom anti-alias”, there is a noticeable jump in appearance between 0.78515625 (201/256) and 0.7890625 (202/256), as though it is actually changing the method that is used to blend the sub-pixels at that point. It is highly distracting, and makes it impossible to smoothly change the opacity of text fields. Here is an example that shows the abrupt change between these two alpha levels:

One solution is to change the anti-aliasing mode to “Anti-alias for animation”, but then the letterforms get muddy and pretty ugly to view. Another option is to change the layer mode to “lighten” or “darken”, but this only works in cases where the text is black or white.

Has anyone else discovered a real solution to this problem? I haven’t seen it discussed anywhere, but maybe my Google-fu is simply failing me.

I really like Caleb Cannon’s Evaluate dashboard widget. It’s simple, well-designed, and very useful for doing quick calculations. It’s like a widgetised version of SpeedCrunch. Unfortunately, when updating from Tiger to Leopard, it stopped working properly—the body would no longer scroll, and font settings didn’t work. This made it very annoying to use.

A few hours of Dashcode later, I present version 1.1 of Evaluate. It functions properly in Leopard, and adds a new feature: the result of the previous operation is set in a variable named ans, just like in SpeedCrunch, and if you start your next expression using one of the four major operators (+-/*), it will automatically be prepended. I find this to be a huge time-saver, and I hope you do too.

Download Evaluate 1.1

Recently, one of my clients had a scare where they thought that a large amount of traffic was not being tracked by Google Analytics. This led me to run a test using a second third-party tracking system from StatCounter to confirm whether or not the data being reported was accurate.

The data

Below is a subset of the raw data that were captured during the course of this study. The study is actually still in progress, since not enough has been captured yet to determine any useful trends in why the reported numbers differ more on some days and less on others. I will provide an update later on trends if any are present.

* Since I was simply performing a sanity check against Google Analytics, I only used one additional tracker. If there had been serious discrepancies between the two trackers, a third would have been added to determine which of the two was reporting incorrectly.

Initial conclusions

While collection is still ongoing for the foreseeable future, the data seems to indicate that there is no real problem with the pageview data that Google Analytics collects. The discrepancy between the two sets is minimal, and there is no correlation between the number of uncounted visits and the amount of traffic going to the site on a particular day. As a result, for anyone with moderate-to-high levels of site traffic, the difference should be unnoticeable. For sites with low traffic levels, the small loss in precision becomes exaggerated, but should nevertheless not pose a serious problem.

As to why this is happening, I can only hypothesise. Without knowledge of specific instances where a visit was counted by StatCounter but not by Google Analytics, it will be impossible to actually determine what is occurring. That said, here are some of the most plausible explanations I can come up with:

1. Users are more aware of Google Analytics and may choose to block transmission specifically to Google, whereas StatCounter is less well-known and may not be blocked by these individuals.
2. Google receives orders of magnitude more data than StatCounter and may have more periods where requests are rejected due to processing limitations.

What about good old-fashioned server log-based analytics?

For fun, I also looked up the data from our available log-based statistics systems, AWStats and Webalizer. Since they both run against the same logs, their numbers are nearly identical (though, surprisingly, not exactly identical, likely indicating another issue with the way they are instantiated by cPanel). The direct log-based data shows extremely different numbers from Google Analytics and StatCounter—4 times the number of pageviews, in fact. However, it is safe to conclude these log-based numbers are bogus, for several reasons:

1. Visits from bots and content scrapers are included.
   While AWstats tries to avoid lumping robot traffic in with visitor traffic, it does not do a particularly good job. Additionally, certain anti-virus software and spambots often will masquerade as IE6 visitors, even though they are not. (This is a particular sore point for me—given how problematic supporting IE6 is, having fake IE6 traffic makes it harder to determine when it can stop being supported completely.) A JavaScript-based analytics system like Google Analytics or StatCounter will always provide more accurate data on real visitors because, for the most part, only real browsers execute JavaScript. (I know there are some experimental robots that will try to handle JavaScript, but they are not complete enough to trigger an analytics hit as far as I am aware.)
2. AWStats counts anything with an extension not on its “NotPageList” as a pageview.
   By default, the NotPageList is spartan and includes only CSS, JavaScript, and common image file extensions. SWF files, ZIP files, FLVs, and MP4s are all considered by AWStats to be a pageview, even though they are not, which causes artificial inflation such as we are seeing here.
3. Sites with pages that include dynamic content may hit the server multiple times for what should be counted as a single pageview.
   A server log-based analytics tool will count each server request separately, even though they are all from a single page load. A JavaScript-based tool will only count pageviews when you tell it to, with the added benefit of being able to track outgoing links as well as the usage of third-party services on your site.

Overall, Google Analytics continues to be an excellent choice when looking for a free analytics tool. It gives users a huge amount of power to pull all sorts of useful metrics and other interesting information from their visitor data. There are, of course, a plethora of other options out there, and through researching this issue I now have a short list of other products that I will be evaluating in the future. For the time being, though, I don’t see any particular reason to avoid Google Analytics for fear of unreliability.