event tracking

Mike: In this episode of Startups for the Rest of Us, Rob and I are going to be talking about getting started with event tracking. This is Startups for the Rest of Us Episode 426.

Welcome to Startups for the Rest of Us, the podcast that helps developers, designers and entrepreneurs be awesome at building, launching, and growing software products. Whether you’ve built your first product, or you’re just thinking about it, I’m Mike.

Rob: I’m Rob.

Mike: We’re here to share our experiences to help you avoid the same mistakes we’ve made. How’s it going this week, Rob?

Rob: I always struggle getting back to work after taking time off. I was off for about a week over the Christmas break and then obviously New Years was Monday and Tuesday. Getting up Wednesday and getting back in the email. I certainly checked and responded to email over the break, but you don’t dig in and do a lot of the little stuff. I think my Kryptonite is breaks. As much as I love breaks and as much as they make me feel re-energized, I really struggle to reenter the work mindset. Do you feel the same way?

Mike: Yeah, definitely. I’ve actually had that struggle for the past couple of weeks. December is obviously kind of slow just in general. After about the 15th or so, nothing was really happening. I decided to back off of my schedule a little bit and use the time to recuperate a little bit. I try to do some things here and there but I also realized that it was vacation, I’m not going to work my tail off. I just got to a point where I’m like, “I’m just not getting anything done.” I just said, “The heck with it,” at one point and I’m trying to get back into things at this point. It’s been a progression of about a week or so trying to get back into things.

Rob: Yeah, that’s crazy, and you know that it’s best for you to completely unplug, but I almost feel like when I completely unplug it’s even worse to try to get back into it because you come back and you have 500 emails or something. At least when I came back I only had, I don’t know, maybe 80 or 100 emails to respond to but I had taken care of a bunch of short responses in the meantime. I didn’t spend six or eight hours. I’ve had times when I’ve completely unplugged and I’ll come back and basically spent eight hours just in email because it stacks up so quickly.

Mike: Yeah, I’ve done that too. It’s hard especially that first week or so back because you got this backlog of email that you know you should go through. They’re at least semi important, you’ve got to probably do something with them. But at the same time, you don’t want to spend the entire day doing that because it’s kind of depressing to sit down and do email all day.

Rob: I agree, and there’s that struggle of just sitting in email. Sometimes it’s completely unproductive and sometimes it is really productive. Sometime it does push your business forward if that’s the phase that you’re at where you’re connecting with people and making intros and responding to things is moving things forward. There has been a chunk of my career where not being in email is detrimental to whatever I’m doing, and the more I am in email–as long as I’m efficient with it–it does move the business forward.

That’s the struggle. You get a few hundred emails and you’re kind of staring them in the face and it’s like, “How do I get the low priority ones out of here and not deal with them and only look at and respond to and organize the high priority ones?” I actually of course have a system for that. I talked about–a couple episodes ago–on the Zen founder podcast and it involves email and Trello and a label that I have called “This week,” where I dump everything in and then I circle back once a week and I go through all that lower priority stuff.

It works well for me but there’s nothing that can take 500 emails and make it a 60-minute task because it’s not just replying “Yes,” or replying “No,” some of them are like really hard decisions, or some of them takes more research and more thought. You can have an email that might take you 30 or 40 minutes just to put together whatever it is, “I need to run these numbers. I need to put a graph together. I need to put a spreadsheet together,” or whatever. That’s the fun of getting back to it.

I have had some folks I worked with who don’t experience that. It’s not everyone that has a tough time getting back and into work. Some people come back super recharged and excited, they wake up in the morning and they’re like, “Oh, I’m going to hit the ground running because I haven’t worked for two weeks,” and for some reason, I’m the exact opposite. I’m like a momentum player where while I’m working, I don’t want to stop working, and while I’m not working, I don’t want to start. It sounds like you might be the same.

Mike: Yeah, pretty much. I kept a pretty good handle on my email for the most part. I’ve got 60 in my mailbox right there. Some of them, I have to deal with them. It’s not like I can just delete them. One of them was on Google’s […] policies that are changing in a couple of weeks. I have to do something with it. I can’t just let it go. It’s not only time sensitive but it’s also in my mailbox. It’s hard to figure out what to do with some of them because a lot of them I just can’t delegate, at least not yet.

I was printing books and stuff for the Single Founder handbook through CreateSpace and then they changed everything over as of January 1st. It’s just like, “Oh great. Now, I’ve got to go figure out how this happens,” because somebody placed an order for the book and I can’t even print it. I literally can’t do anything.

Rob: I do the same thing for my book and my kid’s books. CreateSpace has existed since 2006, Amazon bought them, didn’t change anything and now they rolled it into the Kindle thing. The KDP which is like the Kindle Direct Publishing. You have to go through a bunch of configuration and then you get it set up, but they remove functionality.

I used to be able to–in CreateSpace–just send one copy to a person. Now in order to do that, you have to enter their email address in your Amazon account. Now, it’s in your Amazon account. You got to go back and delete it if you don’t want it after.

I actually debated between two options there which was to either completely give up fulfillment myself. I used to have a VA that would punch it through CreateSpace and she’s like, “This isn’t working anymore.” I either was going to completely just link off to Amazon and Audible and just walk away with my hands in the air slinked back into the hedge and just be like, “Yeah, I’m just going to let people buy from there,” but I wound up ordering 20 copies, sent them to her and she is now doing one off fulfillment.

Start small, stay small. It might sell 20 physical copies in a month through the site. It sells more than that through Amazon. That’s what I do. I’m kind of thinking to wait and see how it goes and if it works out this way, then fine. But I don’t know, I hate it when software changes like that. Why did they need to update the software, Mike? Why don’t we just use the same version that we’ve been using for 20 years?

Mike: Yeah. I find it interesting that you decided or at least contemplated the idea of just walking away from all the fulfillment that you were going to do on your side and then instead decided to have your VA send out some of the books. I’ve still got a bunch of books here. I’ll probably use those for fulfillment for right now. I’m seriously contemplating going in that direction myself. Throwing my hands up and saying, “I’m done. I’m just not even going to deal with it,” but obviously, there’s lots of other implications and things to think about there.

The only other thing I have on my side is that I got a paint set for Christmas from my wife and I think that it was actually a secret ploy because she wanted to paint some of the D&D mini figures that I ended up buying. On New Year’s Eve, we decided to spend a couple of hours with some of the kids off to an overnight sleepaway camp that was $70 for each camp down in Connecticut. Her and I sat there and painted D&D mini figures for probably two or three hours or something like that and watched a movie and went to bed. That was the extent of our New Year’s festivities.

For the listeners, Rob apparently has a power blackout right now. I’m going to be doing the rest of the episode solo. Today’s episode is going to be on getting started with event tracking. I’m looking at this just because I’m reworking some parts of my sales funnel for Bluetick and wanted to look around and see what other people were doing.

I’ve revisited this a couple times in the past but it seems like I never really do a great job of documenting the entire system. I looked around to see if there were some examples of what other people were doing and came across a couple of articles over on the Segment.com blog and we’ll link those up in the show notes including a Google spreadsheet that they have that they’ve published which is essentially a guide to how they have documented their event tracking; what it is that they track and why they track it.

I’ve been reading that and a bunch of other things and various blog posts on the internet. There’s a couple of different tips and tricks that you have for event tracking. The first thing to keep in mind is that events can happen across multiple tools. For example, when somebody makes a payment, it goes in Stripe, Stripe can trigger an event. If somebody signs up for your app, that’s an event as well and that can happen inside your app; it’s completely disconnected from Stripe. Although you can integrate it into Stripe, both of those systems have their own sets of events.

Within a Segment, obviously you can send all of your events to Segment from all the different tools, but you’re not using Segment, then you still have this problem of having events in multiple systems. If you’re going to try and track those, it makes it very difficult. The idea here is that if you have events in different systems and you’re trying to tie them together, what you want to do is you want to document them.

Before you start implementing events and trying to track them, or trying to implement sort of analytics around them, what you need to do is sit down and document them. What this does is it makes revisiting them in the future a lot easier. It also makes it easier for your new hires or contractors to see at a glance what events already exist and why those different events exist and where they are.

The other thing that I found is that usually what I’ll do is I’ll go look at my events and I will go and take a look at them. I might work with them for a couple of days or a week or two and then I don’t revisit them for several months because there are other things that I need to track. I get into other things and come back to it and I’m kind of lost. I’m like, “Where is everything? What is it that I’m tracking?” and kind of forget all those things.

Documenting these is extremely helpful. The first part of that is to define what your events are. Segment recommends defining three core life cycle events. Anything more than that is probably going to be overwhelming. The idea is: what exactly is a core lifecycle event?

A life cycle event is essentially something that your customer needs to do inside of your app so that it will start providing value to them. We’ll kind of refocus this a little bit to event tracking inside of your app or the ancillary stuff associated with it, explicitly for your app and not necessarily in other tools because you don’t necessarily have a lot of control over what those things are named or how they’re put together but you may still want to document what some of those are.

Some of the things you need to look at is whether or not the app is providing value to them and what are the different events that have to happen before they get there. The first one might be that they signed up for an account. Obviously, that’s one of the first things that you probably want to track. Once they signed up for an account, there may be other things that you have to track. For example in Bluetick, once they’ve signed up for an account, they’ve gotten in there, they need to connect their mailbox. If they don’t connect their mailbox, they can’t get value out of the product.

There’s other things that they need to do as well. They need to set up a sequence. If they haven’t set up a sequence, they’re obviously not going to get any value out of the product because it’s not going to be sending out emails on their behalf. Think about the exact things that the customer needs to do before your app is going to provide value and focus on those as your events.

Next step is to name each of your events. I would highly recommend using some sort of a naming convention. Segment recommends that you use past tense verbs to describe them. Instead of saying, “Signing up,” you say, “Signed up.” If it’s sending data, you say, “Sent project data.” If they started a subscription, you say, “Started subscription.” You don’t say, “Subscription started,” that’s more of a description of what it is as opposed to the past tense description of it. You’re using it as a past tense verb as opposed to nouns.

The next part of your naming convention is make sure you’re using capitalized letters for these. Again, these are just recommendations, they’re not set in stone. If you decide that you’re going to do it differently, that’s totally okay. Just make sure that you’re consistent across all of the events when you do this. If you write these down and you are consistent across, it just makes it easier to eyeball something and say, “That’s an event,” versus, “That’s a property.”

Next thing, obviously that leads into properties. For each event that you have, which properties are going to be supplied as part of that event and what are the property values being supplied? By property values, I don’t necessarily mean is it an integer or is it a string. That kind of goes into it, but you really want to document what the name of that property is and what its purpose is. For example, customer ID, you can describe it and say it is an integer describing the unique customer ID inside of my local database. You might also say that it’s a customer ID that’s a string representation that’s the public facing version of that. You may track both of them. It depends on kind of where you’re tracking those events and seeing them and sending them.

Next one, document exactly why is this data being tracked. Why is it important to you? What is it going to do for you and what are you going to do with that data? If you’re tracking an event just to track it, it’s not very valuable. What you really want to do is focus in on those events that you’re going to take some sort of an action on. In the case of when somebody signs up, the signed up event triggers, at that point then what?

You’re probably analyzing the people who signed up and trying to figure out whether or not they’ve started a subscription. All the different things that go along in the middle, whatever that funnel looks like, you’re going to want to track people along the way to see where the drop off is. That’s why you track signed up because that’s kind of a starting point. You also track the started subscription because that’s the end of their trial period. What you want to do is make sure that you’re only tracking the events for which you’re going to take an action on. If you’re not doing that, you’ve got all these different events that you’re looking at and it’s really just going to be confusing.

The next thing to take a look at and make sure that you document is where is this event coming from? Whether you document this as a URL, or a set of URLs, or wild cards or something like that, there’s a lot of different ways to do it. You may even say that this particular event comes from Stripe or gets fed in from Zapier, or some other tool and then put it into your system. You really want to know where it comes from and what is triggering it. Because otherwise, it’s going to take you awhile to figure out how events lead into one another.

For example, if you have a Stripe event and it happens, it says, “They started a subscription,” because the billing got triggered, how is that done? Is it done natively from a Stripe subscription, or is it something that you initialize inside of your app, you send it over to Stripe, and then it comes back, and then Stripe does it. Depending on which of those two things is true, you’re going to have to document that differently because what you don’t want to have is you don’t want to have this event that says, “Started subscription,” and then not be able to find where that event gets triggered.

Otherwise, you can try and modify what your sales funnel looks like because you’re trying to optimize some things and then suddenly these new events keep popping up. You thought you removed the code for it but you didn’t remove all of it because there were other codes in different locations, either on the app or in some other tool that gets fed in. You want to make sure that you document not just the tool that it comes from, but how it’s triggered and how that data gets back into whatever your essential repository is.

Like I said, whether it’s Segment, or your own app, or your own database, or mixed panels, something along those lines. You need to know the entire path because if you don’t have the entire path, lots of things can go haywire and it’s really hard to deal with those pieces of data. Especially when those events are triggering other things because essentially it’s a cascading system and it’s so hard to remove some of those events or prevent things from happening if they are triggered by things.

Next, you’re going to want to take a look at exactly the code that is in place and document exactly what that is supposed to be inside of whatever your document is. Again, Segment uses a Google sheet to document it. We’ll link that up in the show notes. I really think that it’s a good idea to go take a look at that and see what they do and how they do it because they have the exact snippets of code that are in there. All the stuff that I’m talking about today is all documented in there.

Once you got that code documented in there, just at a glance, you’re going to be able to say, “Well, is this JavaScript, is it going to be sitting on a webpage?” You’ll see that based on all the other information that you’re putting into this Google Sheet. You’ll see is it JavaScript, is it Ruby, is it C Sharp. You’ll get a sense of that when you take a look at that code, or there may even be something in there that says, “This is externally generated and we don’t have anything.” For example, one of their events says that it comes from a Zendesk webhook. Obviously, there’s no code for that. It’s just configured directly inside of Zendesk.

Next is take a look at the status of those events. The status fields are actually pretty important. This isn’t something I had thought about until I took a look at their documentation. They have three different fields for this. They have ready, installed, and tested. They have a yes/no for each of those. It may be installed but it hasn’t been fully tested. They may have put it together and it’s maybe ready to be deployed, but it hasn’t actually been installed on to the website or into the app,, or anything like that. They also may not have tested it.

The other thing that you can keep in mind here is that you could add another field here, or you could even just reuse the install field to keep track of this. You may decide to deprecate certain events because as I said before, once an event is in your system or has been in place somewhere inside of your app or as part of your app’s life cycle and it’s been used to track your customers, it’s impossible to basically rip that out because it’s a historical event. You can’t delete it and say this never happened, because it actually did. You just have to make sure that if you decide that you’re no longer going to be tracking a particular event, that you change the status in there so that if you go start looking at customers that are six months, or a year, or three years old and you start seeing these weird events in there, you can look at the documentation and say, “This used to be used for this at that point and now it’s no longer used which is why all the new customers don’t have that anymore.”

Then the last thing to keep track of–and this is kind of a notes field–it just allows you to put whatever other information you need to put in there to discuss this particular event, maybe you say, “This was deprecated on such and such date,” or, “We created this on such and such date,” those could be their own unique column inside the spreadsheet. But in any case, it allows you to put some notes in there.

Now that we’ve kind of talked about the documentation itself for these particular events, one thing to think about is why use events at all? If you look at a bunch of different marketing platforms, you’ll see things like some of them use tags, some of them use events, some of them have both. The key question here is what’s really the difference? Why would use one versus the other? The thing to keep in mind with a tag versus an event is a tag is essentially a status field, there’s a categorization. Does this need such and such criteria or does it not? Have they achieved this particular goal or have they not? That’s a little different from an event where an event also has a date and time that something happened.

With the tag, it just says is it yes or no. Whereas with an event, it may have that information, but in addition to that, it also has a date and time with it. It could happen more than once. You may decide if this happens twice within a week for example, let’s send out a particular email, or let’s act on that in a certain way.

For example, in one of the things I have in Bluetick is that when somebody’s subscription is canceled and then a new subscription is created, that is essentially an aggregate the says, “Okay, do not trigger an event for this,” because it’s not a cancellation. I treat it that way because inside of Stripe, I can’t just say, “Translate or convert this subscription from this level,” I can’t do that. Instead, what I do is I say, “Well, if this event happens and then this other event happens within a certain timeframe, then treat it in one way. Otherwise, treat it a different way.” If an event comes in and says, “Subscription cancelled,” and then there is not a corresponding subscription created within maybe four to six hours or something like that. If those two things don’t go together, then treat it as a cancellation and it triggers that cancellation event.

That’s in my system, it’s not Stripe’s. Stripe is obviously going to say, “Okay, well this is a cancellation and then here’s a new subscription,” but to me in my own marketing sales funnel, it is not a cancellation. It is, for Stripe, but in my events system, it is not. Those are the types of things that you want to make sure that you differentiate between how you’re tracking your events, versus how other people are.

The nice thing about this is that, when you’re using an event, it’s a lot better than just the fact that something happened in the past. It’s because you’ve got that time and date associated with it. Think of for example if there’s something in your app and somebody runs into a particular error, and you have the error surface back into the backend of your system. Maybe it’s a frontend client side JavaScript error, maybe it’s a backend inside of your Ruby code or something like that. That stuff can bubble up into your event system, and your event system can take a look at that and say, “Well, this particular customer ran into this problem,” and we’ve got all the documentation around that the says, “Here’s the stack trace,” or “Here’s the line of code that they ran into through this particular error,” and you can dig into it and figure out why.

But when you’re trying to prioritize things, you may look at that and say, “Well, do I need to prioritize this higher? Did they run into it 30 times or 50 times in an hour? And then they went over to the help desk or the documentation and started looking there. Then they came back and they ran into it more.” That’s a lot more information that you’d be able to see from an event than if you were to see from a tag. A tag will just tell you, “Well, they ran into an error,” but the events, the series of events, you’re going to be able to see that and see exactly what that person did along the way.

Now, to kind of step a little bit back from that, I’m not saying that you would go in there and you would necessarily create all of those things as events in your system that you would be tracking on a regular basis and trying to use to match up to your KPIs for the system, for your application, and try and move the business forward, or tweak different things to make that possible. What you might do is you might want to say are people running into errors with a particular piece of the application before they reach one of those goals along the way in order to activate them into a customer after they’ve signed up, but before their subscription is created and you have charged them.

That’s the type of thing that you want to think about. How do these events chain together and what do they mean to you? What are you going to do with that information afterwards? Because if you’re just tracking events to track events, it’s not very helpful.

A key example of this I think in most cases is page views. If you are looking at anonymous visitors coming to your website and trying to figure out what is the path that they go through on your website. In some cases, that’s very important. In a lot of cases, it’s not, though. All these events that can be triggered you can say, okay, here’s a page view for example, that’s the event that gets triggered. Then for the properties you may say page name and you send that into your analytics software or whatever it happens to be. As I said, whether it’s Google Analytics, or mixed panel, or Segment or what have you. You’ve got that information, but what does it really do for you? Are you going to tweak the layout of your website? Are you going to make changes to the web pages? Are you going to modify the navigation a little bit?

If those are the types of things that you’re looking to do, then yes, you should absolutely be tracking those. But if you’re just tracking them to track them with no purpose in mind, then they’re worthless. The one caveat I would say with that is that you start tracking those events in order to get a general idea of what’s going on. For example, how do you know how many people visited your about page? That’s one of those key things that a lot of people don’t spend very much time on their about page. It actually is a page the most people’s websites gets a fair amount of traffic and these people want to know about the businesses that they’re buying things from.

If you need to know how many people are coming there, most people will look at their Google Analytics but that’s a situation where you could say, “I’m sending this information into my analytics software and I’m tracking that because I want to get a general idea of how many people are going there.” Once you have that, you can start narrowing it down because you’re associating each of those events with a visitor or with a unique user, that gives you the ability to say how many unique visits is this getting versus the total number of visits.

The same person visiting that 10 or 15 times sends a very different signal than 10 different people who visited that page once. With all that, I think I’m going to wrap up today’s episode. Again, we’ll link up both the article itself to the Segment blog and a link directly to the Google spreadsheet that they have directly in the show notes for this episode.

If you have a question for us, you can call it into our voicemail number at 1-888-801-9690 or you can email it to us at questions@startupsfortherestofus.com. Our theme music is an excerpt from We’re Outta Control by MoOt used under Creative Commons. Subscribe to us in iTunes by searching for Startups and visit startupsfortherestofus.com for a full transcript of each episode. Thanks for listening and we’ll see you next time.