Tag Archives: analytics

Diary of a bug in an iOS app

Posted on
4

Last week we released version 2.9.2 of WordPress for iOS, and it had a terrible bug which killed the ability to paste text from other apps, which is probably a critical feature for a blogging app.

We should have done a better job at testing it, but somehow the bug escaped our tests and it got released. Most of the feedback on the forums was perfect: users concerned that they can’t use the app properly, but understanding that it can’t be fixed overnight.

But then this happened:

It is unacceptable that I STILL can not use the iphone app. It’s been DAYS! Fix the PASTE issue!!!

Well, it’s definitely unfortunate, but here’s how it goes:

  • Dec 5: 2.9.2 released on the app store
  • Dec 6, 6AM: first report on the forums
  • Dec 6, 11AM: after some testing, it’s confirmed that 2.9.2 broke copy/paste and it’s not an isolated problem.
  • Dec 6, 1PM: Went through the list of changes for this version and the only thing that made sense was an update to the Flurry library (used for stats/analytics). Emailed Flurry support to ask if they had similar reports or know how to fix it.
  • Dec 7: no reply from Flurry yet, we decide to remove the Flurry library from the app.
  • Dec 8: still no reply. Removed library, prepare a new build and test it.
  • Dec 9: submitted 2.9.3 to the App Store
  • Dec 11: Apple approves 2.9.3. That’s new, I didn’t know they work on Sundays, but I won’t complain :)
  • Dec 12: released 2.9.3 on the App Store

Looking at that timeline, there’s always room for improvement, and we could have just skipped waiting for Flurry to reply (no word from them yet), and remove the library from the app directly. But even then, I’d say 2 hours from noticing a bug until we know what’s wrong and how to fix it is not that bad. Most of the times the bugs are way more obscure and hard to find.

If you’re lucky, 2 business days is the usual wait time for a bug fix release to be reviewed and accepted: I was expecting it to be published on Tuesday (Dec 13).

Goodbye Flurry

I don’t think we’re going back to Flurry after this. It’s enough trouble debugging against a proprietary framework (iOS SDK) to add another binary library to the app.

The problem here was that we had to update the Flurry library, since the old one was getting the app rejected by Apple. And the new one first broke our build server: it needs the 4.3 base SDK and we were using 4.2. And then this.

Plus, I think it collects way more data than we’re interested in. In the end, we want to know how many people is using the app, and what features are more interesting to people. Also, at some point, which kind of devices/versions users have, to know when we can drop support for older platforms.

How we track outbound links with Google Analytics Events API

Posted on
4

eBox Platform homepage

Since the redesign of eBox platform, our bounce rate increased dramatically. After a short investigation, it made sense: our new website was just the homepage and news, and the rest of the content was on different domains (trac, eBox Technologies, …).

So our bounces were either real bounces, or people visiting our other sites (which I wouldn’t count as bounces).

My solution: track outgoing links.

I searched for a solution and found this article, but it wasn’t exactly what I wanted.

It’s a good first approach, but tracking external links as pageviews makes the analytics reports more confusing. Events Tracking API to the rescue! This API was conceived to track actions that don’t match a page view, like video plays and other application interactions.

So, with events we could track our exits separately, get the information we need, and get a more accurate Bounce rate.

The extra code:

The original article used rel="external" to mark the links to track. There is an easiest way: searching for absolute URLS in the href attribute. Also, I’m using the action parameter to differentiate between internal (our other websites) and external (facebook, twitter,…) links.

What we are tracking, and will be able to see on the Analytics reports is:

  • Category: Exits. Could have been called ‘outbound links’, or any other variation
  • Action: external or internal
  • Label: the destination URL
  • Value: not using it. This could be useful for other kind of events, like tracking video load times

Warning: your bounce rate will probably drop by tracking events. For us, it reflects our visits more accurately, but that might not be your case.

This is what google has to say on bounce rate impact:

In general, a “bounce” is described as a single-page visit to your site. In Analytics, a bounce is calculated specifically as a session that triggers only a single GIF request, such as when a user comes to a single page on your website and then exits without causing any other request to the Analytics server for that session. However, if you implement Event Tracking for your site, you might notice a change in bounce rate metrics for those pages where Event Tracking is present. This is because Event Tracking, like page tracking is classified as an interaction request.

For example, suppose you have a page with a video player where the bounce rate is historically high, and you have not implemented Event Tracking for the page. If you subsequently set up Event Tracking for the player, you might notice a decrease in the bounce rate for that page, because Analytics will record user interaction with the player and send that interaction to the server as an additional GIF request. Thus, even though the same percentage of visitors to the page might still exit without viewing any other page on your site, their interaction with the video player triggers Event Tracking calls, which disqualifies their visit as a bounce.

In this way, “bounces” for your event-enabled pages means something slightly different: a single-page visit that includes no user interaction on tracked events.