by Doug

14/08/2013

Google Analytics

Measuring project velocity using Basecamp and Google Analytics (Universal)

Introduction

As an agency that focuses on Conversion Rate Optimisation for clients it makes sense to ‘eat our own dog food’ as much as possible. With this aim in mind we always strive to be as efficient as possible in what we do and how we manage projects for clients.

Of course, any optimisation effort requires measurement – if you don’t measure something, you can’t improve it! (OR at least quantify the improvement).
Like a number of organisations we use Basecamp by 37Signals for collaboration, tracking and project management tasks. We like it a lot but I always wonder how we can get more value from the tools we use…Here’s how the thought process went.
Basecamp has an API. Using the API, project ‘events’ can be requested.
Google Analytics (GA) has an API…Universal Analytics!

We have a Raspberry Pi.  If you’ve been in a cave for the last year read about this super piece of tech here – http://www.raspberrypi.org/

We wanted show just how universal Universal Analytics (UA) is as well as have some fun with our new Raspberry Pi so I decided to learn a bit of Python and write a script that polls the Basecamp API and then squirts the event data into GA using UA on the little server.

How hard can it be?

Not very.  And the results are pretty neat.

Brief Technical Bit

Setting up the Pi is a no-brainer.  Running Raspian, Python is already there so that made the scripting language choice easy.  We use requests to connect to the Basecamp API and fire off the UA measurement protocol requests.  The script is fired every 5 minutes by a cron job.

The last event datetime stamp for each project is recalled so the script only gets the latest events.  5 minutes is long enough for ‘Basecamp stuff’ to happen without being too eager, wasteful or lazy and slow.

The project events are recorded as GA UA events.

A virtual pageview is fired every 5 minutes with the value:

Events found [datetime stamp]

or

No events found [datetime stamp].

This should make you think ‘Hmmm – using GA as a log file repo…’ Indeed – no more looking up grep, awk or sed command syntax to analyse a log file….but that’s another story.

We use the project ID from basecamp as the cid (user ID) in the UA request.  Here is the ‘server room’ such as it is:

Business/Analysis Bit

We’ll start with the obvious – how active have we been with projects during August? Using the Top Events report we can see very high level activity data:

Client (project) names have been removed to respect privacy. Already we can see who has been super busy (too busy?) and at the other end of the report (not shown) we can see who needs encouragement and support – why have they not been busy?
Recording the client name as the event category we can drill into the event data and see what actions have been taking place – drill into the event action report:

Action details have been obfuscated but you can get the gist quite easily. The richness of the data is quite easy to change if you only wanted to see the action type.

The questions here are:
What are the common action types?
Is there a lot of talk and not much do?
Is there enough communication on the project?
How are all these metrics changing week on week?

Staying with this client and flipping to the event labels shows us who is busy on this project:

Client resource names have been obfuscated to respect privacy.

So, we start to build a picture of activity (project velocity) across clients, by action, by resource and so on. With GA we can see progress and pace by day, week or month.

If we wrap the events with goals, we can see conversion rates!:

We can apply segments to see specific goal conversion rates by client:

This is getting exciting. Let’s take it to the next level. Set up intelligent alerts to flag when projects go ballistic and when they go cold. Use GA alerts to tell you when the project velocity is changing out of the norm. By not sweating the project velocity details every minute of each day you can use this extra ‘head space’ to operate more strategically and effectively.

Do you notice something potentially very useful in that screen shot that is missing? Yes – value. The next phases on this project are to hook up the time tracking (http://www.tickspot.com/api) and billing system to add economic value to the data set.

Wow. OMG OMG O. M. G. 😉
For now, we’re sharing project specific profiles with clients to give clients the same view of project velocity as we have – it’s a collaborative approach.
This is quite prototypical right now but we’re already seeing how changes in our usage of Basecamp based on data driven decisions are yielding better project management, pace and overall deliverable quality.

Update Sept 5 2013:

So, we’re approaching a month of using Velocibot to gather data on our Basecamp usage and the results are looking pretty interesting. I’ve deliberately not changed anything in the software. Really, I’ve not even touched the Raspberry Pi. And it’s just ticking away doing what it does without fuss or flourish.
Simple really is reliable.

So, the data. The title on this post was ‘Measuring project velocity blah blah blah’. Project velocity (AFAIK) is ideally steady or at least without peaks and troughs. Well planned work across multiple clients leads to consistent use of resource capacity. This is good. This is what we see in the total events report for August:

Nice. Mostly. The recent peak is partly down to the public holiday moving tasks into the next week and we have a project manager on holiday…some slack to take up as well as work from last Monday.

We’re seeing some projects spike with communication bursts but these spikes correlate with the start of client sprints. We can see the benefits of using Basecamp better. We can see throughput on tasks and can demonstrate velocity to clients. For an agency to democratise this kind of data brings a refreshing level of transparency to project work that can only result in better stakeholder participation.

Now, I had a really good question on twitter from @Niroshan_Samuel regarding the use of individual’s names in the data. Does this constitute PII? Fair point but at this moment I would say no although the boundary does get a little grey. My name is in the data. So? There are many Doug Halls on the internet. An arguable point? Just but I would be careful with other data sent to GA. It is a consideration and you do need to be careful with what data you put in GA. Perhaps first name only or initials would be safer?

We’ll see how the PII debate pans out and we’re going to continue running our little Pi based Basecamp/GA mashup prototype.

Comments

Leave a comment

Your email address will not be published. Required fields are marked *