In the world of databases, it’s common to talk about CRUD operations. Those are the four foundational functions: create, read, update, and delete. For REST APIs, we use the HTTP verbs post (create), get (read), put (update), and delete. These four simple concepts are the building blocks for essentially any application you build, regardless of the functionality or data you’re tracking. Like a lot of ideas in programming and computer science, once you understand these concepts you can easily see how the world fits into their structure.
Likewise, many levels up the stack, I’ve been thinking a lot about events. Segment, who was bought a few months ago by Twilio for $3.2 billion has a simple value proposition: one bit of code to track data across multiple systems. Their innovation was to generalize the actions of tools like analytics and marketing automation into a few simple calls so that you could install one snippet of code on your application or website and plug it into a huge number of different systems downstream.
Like those technical initialisms I talked about above, there are a few simple Segment calls that allow you to do almost anything:
- Identify: Who is the user?
- Track: What are they doing?
- Page: What web page are they on?
- Group: What account or organization are they part of?
Again, what’s powerful about these simple events is that they become the backbone for almost everything that happens in sales and marketing (and analytics). Page is easiest to grasp: it’s a way to keep tabs on what page people are looking at.
Track, on the other hand, is what you do when a user takes an action. That action can be anything you imagine, from clicking a link, to filling out a lead form, to inviting a user to your application. It looks like this in its raw form:
Where the concept of track gets even more powerful is as you start to think of the different kinds of events you might want to follow outside your walls. It could be email opens from your marketing automation system or even meetings in your calendar. The power of track as a concept can be thought of as a way to generically describe activity. In Salesforce, for instance, you may log meetings and emails. In theory, these could also be track calls.
Of course, track isn’t all that useful without identify. Identify is the way you add information about the user to your track calls so you can cut the data in more interesting ways. Segment calls these “traitsm” and they look like this:
The advantage of doing things this way is that instead of including that data on every track or page event, we send an identify call that includes any information we want to store on that user and update that with additional identify calls in the future. The expectation is that all downstream systems ingesting these events will put that data back together in the way it was intended. So, for instance, if a user signs up for your service, you would could pass their first name and job title (both part of your sign-up form) as attributes on your identify event. If, in the future, that user also tells you they live in New York, you might pass that data along on identify as well. When that happens, all your downstream systems will add it to the list of attributes for that user.
If you wanted to see all events from users in New York, the system would check user attributes for location: New York and show you matching events for NY-based users. By splitting up identify and track, not all systems need to know all the personally identifiable details about your users and can continue to call track with just an ID.
Finally, group is a lot like identify, but for tracking information at what we would think of as an account level in sales. An example group call looks like this:
On their face, these are all simple concepts represented with simple verbs. But when you start to imagine how you can put them together, you see their power. First, you can begin to see how sales stages can move to be defined with event data rather than the more qualitative entrance gates we see now. Product qualified leads are a start to this process. By defining the stage of an opportunity with product data (for instance signed up for trial, invited two users, and set up critical module), we get a much higher-fidelity view of whether we have a serious prospect or not.
Beyond that, though, there is a critical role for high-touch sales, particularly in an enterprise environment. Many of the events that happen in a high-touch sale may occur outside the walls of the product. It could be a conversation on the phone or an email answering security questions from the CSO. While these might be logged in CRM, we don’t necessarily think of them as events in the same way we would added user or visited pricing page. But they are, and the only thing keeping us from running them through the same pipeline as our other product and website events is some creativity and technical elbow grease.
Are you using or interested in using events to help define your sales stages? We’d like to hear from you and show you what we are up to.