The pitfalls of a codeless implementation

A codeless implementation may save you time up front, but it’ll expose you to serious problems, like bad data and security leaks down the road.

img45

The problems you'll encounter

A codeless implementation sounds like a great shortcut when it comes to implementing analytics. But you’ll end up with limited, unreliable data, which means you’ll spend even more time and resources on fixing data inconsistencies. This is not to mention the serious security and privacy risks codeless implementations open up.

inaccurate data illustration
Problem #1

Inaccurate data

What if there are multiple ways to perform a certain event, like “Complete checkout”, that include pressing “Enter” on a keyboard, or clicking the “One-Click Checkout” button? In order to ensure your data is accurate, you’ll need to address all of these cases individually when you set up your events, which often requires a software developer consultation to do thoroughly. Otherwise, you’ll be making decisions using incomplete & therefore inaccurate data.

Missing data codeless illustration
Problem #2

Key data points are missing

Codeless implementations also don’t give you the granularity needed for some of your KPIs. Here’s what might happen: You decide you want to see how many users have attempted to purchase item ID 2853 – but that data is not collected or included in your events because the one-size-fits-all event collection doesn’t know where to find your item IDs. It only knows that users are clicking a button with the text “Place Order.”

Missing data
Problem #3

You’re limited in what you can track

Many interactions that end up being very important to you are not tracked at all, such as watching a video, scrolling, or interacting with a pop-up modal. You’ll need a software developer to build a custom solution for these.

Changes break tracking
Problem #4

Changes to your application can secretly break your tracking

Websites are changing almost daily, as teams work to optimize performance or conversions. So even a simple edit, like changing the text of the checkout button from “Place Order” to “Finish Order” breaks your tracking. The one-size-fits-all model doesn’t know it’s the same button, so your event count drops to 0. 

Security risks
Problem #5

You’re exposed to security risks

There are two ways to address security risks. First, you can manually blacklist every possible place you might collect sensitive information, which requires engineering resources and puts the onus on you to ensure you don’t miss anything. Second, you can reduce the information that is automatically collected (such as form fields) which exacerbates the missing-important-data problem.

Neither solution is great, which is why one analytics product that offers codeless tracking says in their own documentation: “To ensure we don’t collect any PII (Personally Identifiable Information) or PHI (Personal Health Information), you need to be extremely cautious.”

Data hard to export
Problem #6

The data is very difficult to export

Due to the nature of how this data is collected, when you export the data to other tools you’re going to get a lot of raw data that’s named differently. Instead of seeing a list of events that say “Checkout attempted,” you’ll see a dump of data that looks like “{action: ‘click’, selector: ‘div#el_1235’}.” It’ll also require engineering resources to make it usable again.

Mixpanel's approach to implementing analytics

Our approach is fundamentally different. All the data is deliberately structured and defined in code, to capture the unique logic that is specific to your business. Mixpanel’s award-winning professional services team will help you build your analytics strategy, specifically tailoring it to your key business goals. We work backward from there, helping you build a complete spec for your developers, who use our SDK to instrument the events and logic.