When we talk to folks about analytics, one question usually pops up. "What are your thoughts on having engineers write tracking code?" Breaking it down, what they want to know is essentially the difference between using tools that autotrack analytics versus having their engineers programmatically add tracking code, and which one is better for their company.
We decided to pen down our thoughts in this article to help illustrate the hits and misses of implicit versus explicit event tracking.
Let's get down to brass tacks, shall we?
Defining implicit and explicit event tracking
Before you go on to read about the pros and cons of implicit and explicit event tracking, let's take a step back and define the two. This will help you to understand the differences better and enable you to make an informed decision.
🤖 What is implicit event tracking?
Also known as codeless event tracking, this type of automatic event collection aims to collect all user interactions within your application. In other words, you don't need to define the events beforehand to collect data.
Tools like Heap automatically capture interactions like clicks, page views, form submissions, etc. and keeps them ready for when you need them. Whenever you'd want to analyze user behavior, you can use a visual editor to create events that you care about, retroactively.
👩💻 What is explicit event tracking?
Explicit event tracking requires that you manually define the events you'd like to track using code-based analytics. The whole concept of explicit event tracking hinges on the fact that you are aware of what events you'd need to track to get the desired analysis.
Now that we have covered the definitions, let's go over the pros and cons.
Hits & misses of implicit or codeless event tracking
Let's take a look at some of the hits and misses of implicit event tracking and how it can help you make the right choice.
🎯 The hits - implicit tracking
1. Great for non-technical teams: With implicit or codeless event tracking, anyone who isn't hands-on with code can analyze their customer behavior with a point and click solution. Paste a snippet to your site and it starts capturing all available user interactions from the client-side. Now, you can analyze different events on your web application, retroactively.
For example, with Heap, you can just define a click event for a button with an id of newsletter-button, and it will retroactively provide you with the data associated with all users who clicked on the newsletter-button.
2. No need for rigorous planning: The whole idea of implicit tracking is to have access to all the data about your customer's interactions. This saves you time trying to determine what events to track in the beginning. With features like Autocapture (from Heap), you don't need to set up a tracking plan to get started.
3. Defining the events is straightforward: Tools like Fullstory and Heap come with visual editors wherein it's easy to create various types of events within a few minutes. This saves countless development hours, which can be redirected to solving other problems.
🤦♀️ The misses - implicit tracking
1. You'll deal with messy data: There might be multiple ways in which an action is performed in your app. Imagine you are the product owner of a grocery delivery app that allows customers to place online orders, and you want to track how often this occurs.
A customer can tap the "Checkout" button and your codeless analytics tool will tell you how many times this button was clicked. However, this data can be inaccurate, considering that there can be other ways for a customer to place an order. Maybe your app has a "Buy now" button which also allows customers to place an order. In this case, if you're trying to find out how many orders were placed, you'd need to combine these events together.
2. There are security concerns: Because these tools capture all user interactions and stream this data to their service, your customer's PII (Personal Identifiable Information) and/or PHI (Personal Health Information) data can be at risk. Mixpanel retired this functionality in large part because of the security concerns in the track everything model. The idea of collecting all data is fundamentally flawed when it comes to these scenarios.
3. Your tracking can break quite easily: Codeless tracking is tied to CSS selectors for web and UI controls for mobile. So, as developers make changes to your product, your tracking can break. Taking our previous example, if a new developer comes in and decides to change the CSS ID on your "Checkout" button from checkout-button to place-order, your tracking will break and you'll be left wondering why.
4. You'll miss out on valuable data: Taking the same example, you might want to know how many 'apples' were purchased. Implicit tracking cannot capture this data. All it does is count the number of times the "Checkout" button was clicked. To answer this, you'll need to bring in a software engineer to add code to track this for you. Every auto-capture tool supports sending explicit events for a reason; it's a myth that you won't use engineering time.
5. You'll lose data because of ad blockers: Because Autocapture tools capture data on the client-side, you're susceptible to ad blockers. Most of the ad blockers on the market block client-side analytics, however with code-based tracking, you can capture analytics on your backend for your critical business metrics avoiding this problem.
That pretty much sums it up for implicit or codeless analytics tracking tools. Now, let's see how it fares against explicit or code-based tracking tools.
Hits & misses of explicit or code-based event tracking
Now that you have a decent idea of codeless tracking tools, let's look at some of the pros and cons of explicit or code-based event tracking.
🎯 The hits - explicit tracking
1. Track what you need and add additional context: With explicit tracking, you can track the data you need for analysis and add additional context behind every customer interaction.
For example, when someone presses the "Checkout" button, using an Event property, you can also track the itemcode, itemquantity, itemvalue productimagesviewed,besides tracking the number of times the "Checkout" button has been pressed. This provides you with additional context into the user's buying behavior.
2. You can rely on your data: With explicit event tracking, you can trust your data as it's integrated into your software development life cycle and won't break. When you treat your analytics like code and have a process in place for data management everyone benefits.
Let's take the same example you saw in the previous section. For code-based event tracking, all instances of placing an order can be instrumented consistently, be it through the "Checkout" button or the "Buy now" button.
3. Govern what's being captured: When you create a tracking plan, you're aware of the data that's being sent to your analytics tool at all times. You know what customer's PII/PHI data is being captured and where it's going. For example, you might want to send someone's name and email to Intercom for personalized customer success, while this information isn't needed in tools like Amplitude. Creating this data map is helpful for making sure that you're in compliance with GDPR and CCPA.
4. Capture data from multiple sources: With explicit tracking, you can capture events from multiple sources consistently including your backend, which isn't subject to client-side ad blockers. Depending on your audience, you can expect to have anywhere from 10-30% of your events blocked. For any critical data, we recommend tracking your events on the backend.
🤦♀️ The misses - explicit tracking
1. You'd need a developer's help: As the name suggests, code-based analytics tools require a developer's time to instrument events. Again, if there's any change in any of the events later on or you need to add a few more events, you need to involve a developer.
2. It takes more time to implement: Code-based event tracking takes a lot of time to implement. A tool like Mixpanel or Amplitude could take weeks, if not months, to get up and running. You're dependant on a longer feedback loop with your developers as they (write code → ship code → wait for data → run query), which is sluggish. It's a huge investment in both time and money.
3. You'd need to plan first: One of the biggest downsides of code-based event tracking is that you'd need to have everything planned and ready before it goes for implementation. This again takes a huge amount of time and effort to plan the events you're going to need in the near or distant future.
Not only that, but if you are a product manager or analyst, you might need to get buy in from your engineering team before adopting the solution. This is all because it requires development time to instrument your tracking plan.
So what should you choose?
So when should you choose to use implicit versus explicit tracking? We've created a quick guide below to help as well as listed some of our favorite analytics tools in each category.
Ultimately, use the tool that works best for your team but understand the pros and cons of each approach. Many teams needs evolve as they grow and add additional use cases for event tracking data.
Well, that pretty much sums up our case for implicit versus explicit event tracking and their respective pros and cons. Think we missed something significant? Drop us an email to firstname.lastname@example.org, and we will take a look.