— This post is part of a series of tips on lessons learned & experiences I”ve had as the lead developer (CTO if you want to be fancy) of the online dating startup, at Ignighter.com. Though these tips are focused primary at consumer startups, they ring true elsewhere too. For a full list of these tips, see 10 things I”d wish I”d known as a lead developer at Techstars. —

My 3nd week on the job, I discovered a major bug in our app. One of the main flows was broken. And it wasn”t pretty.

So, what did I do? Simple. I did what any competant developer would do: I fixed the bug.

Though it only took me 15 minutes to fix the bug, it had taken me 3 weeks to figure out it had even existed.

Although the bug had been fixed, I faced a major problem. I couldn”t let this happen again! How could I prevent something like this from happening again on the app? Or, at the very least, how can I make sure I”m aware that it”s happening if it does? That part wasn”t so straightforward. But, over time, I”ve developed a system. First, I capture what”s going right, wrong, or part-right and part-wrong, in the system. Then, I built reporting tools to notify me when things are going badly, and to give my team data to help us lay the foundation for making decisions on what features to build, iterate on, or decommission.

Here”s the solution I devised. I have a method that I can call to log an event anywhere in the system:

MetricLog::LogEvent($EventName,$EventMetaData,$User);

Doesn”t look like a lot of code, does it? It isn”t. It should be stupid simple to track anything in the system.

Though the logging code may be minimalist, the table that I record my events on is anything but. It”s several million rows of data, each with 20 columns of metadata about that event.

At a high level, here is the list of data I track for each event on our system:

– Unix Timestamp
– Event Name
– Event Metadata
– User who performed event
– User metadata (age, sex, location, etc..)
– Group who performed event (We”re a group dating site, remember)
– Group metadata
– Client metadata (IP address, user-agent, physical location, signup source, re-engagement source)
– URL that event was performed on.
– A hash that uniquely identifies the session.
– The split the user was on, if event was performed on an A/B test.

I track everything from 404 errors, to major technical hiccups, to pageviews , to new registrations through this system. Building the reporting system in house allows me to build whatever reports I want on top of the data. Tracking EVERY aspect of each event allows me to split the data in my reporting system. Imagine if you could build reports that could be spliced by age, sex, location, timeframe, visitor location, visitor referral, and user-agent. Another thing this allows me to do is track the exact flow of a user who encountered an error, or evaluate how many users an error has effected. It”s pretty freakin” useful.

After you”ve got the basic system setup, it”s trivial to set up a cron job that emails you if something”s amiss. Our team receives daily, weekly, and monthly reports of all relevant activity on the system.

It”s nice to know what”s going on in your product. It helps you build a data-driven decision process.

Also – I should note that your privacy policy or TOS must state up-front that you”re tracking what happens on your system, that this data will be used to make the app better, and won”t be shared with anyone outside the team. It”s an important disclaimer.

Good luck, and feel free to leave a comment if you have a question.

Note: Any information of proprietary value to my employer has been removed or approved, and this post has been approved by my employer.