Tracking user interactions with particular website UI elements is commonplace for A/B testing, funnel analysis, customer journey analysis, segment creation, personalization, marketing automation and other purposes. Unfortunately, it is all too easy for this tracking to “break” when changes are made to the UI elements being tracked.
The nature of large websites is to frequently change and evolve. Common scenarios in which changes to a UI element can break event tracking configurations include changing a button’s text or color during an A/B test, relocating a product image as part of a page structure redesign, or changing an element’s class or ID to address a new technical requirement.
The Tracking Continuity Challenge
The problem is that conventional website event tracking mechanisms all rely, in one form or another, on an element’s “selectors” and/or other coded properties. These properties can include the element’s type, its ID, one or more associated CSS classes, its link URL, its text and even the DOM structure of the surrounding page. Because changes to these properties are frequent and nearly impossible to fully record and track (to ensure that no other system somewhere is relying on them for something), event tracking systems fail frequently. In fact, we’ve spoken to large companies that actually have teams of people tasked only with coding, verifying and maintaining event tracking in their websites!
This “tracking continuity” challenge is even more significant among the handful of tools designed to automatically capture all website events. Besides the other downsides of these tools (e.g., the extensive effort required to manually name each event before it can be utilized and the lack of context details included with reported events), they are unable to connect the dots between the same UI element, following changes to the element or the page around it. The result is that these tools end up reporting many events as if they occurred with different UI elements, even though the same UI element was the one being clicked all along.
What that means for the business is fragmented analytics, inconsistent funnels, unreliable personalization and so forth.
Website Event Tracking Failures: A Few Concrete Examples
If you are involved with website event tracking in any way, you can skip this section, as you probably have hundreds of your own examples. Likewise, if seeing any amount of computer code makes your eyes gloss over, feel free to jump ahead to the next section. 🙂
- Tracking “attempted checkouts” is implemented on a website by capturing clicks on a button with the text, “Place Order” (e.g., findElement(By.linkText(“Place Order”))). An optimization consultant decides to run an A/B test to see if changing the button text to “Complete Order” increases conversions. As a result, no attempted checkouts are reported for the 50% of site visitors who see this new version of the button.
- A webpage contains two buttons: “Download Specifications” and “Watch Video”. Tracking the Watch Video button is implemented on a website by capturing clicks on the second button on the page (e.g., find(“button”).at(1)). Product management decides to change the first button to a simple text link, resulting in the Watch Video button now being the first button on the page. As a result, the number of reported clicks on Watch Video drops to zero.
- The drop-down list for selecting a product’s size is added to a funnel analysis by adding the ID “size” to the element and tracking clicks on it (e.g., getElementById(“size”)). Later, during an effort to standardize IDs, a data analyst asks IT to change the element’s ID to, “list-size”. As a result, clicks on this drop-down list are no longer recorded in the funnel.
These are three simple, but representative, examples. There are countless more examples of how tracking code that relies on element attributes breaks over time. Fortunately, there is now a better way.
A Superior, AI-based Solution for Achieving Tracking Continuity
Applying AI to the challenge of website event tracking yields an entirely new approach, one that eliminates the shortcomings of selector/property-based tracking mechanisms. Machine learning algorithms are well-suited to analyzing webpages and their constituent UI elements in a more conceptual manner, without relying on hard-coded selector parameters to identify individual components. In other words, by looking at entire webpages in a more holistic way, the AI can “understand” what is happening on a webpage much in the way that humans do.
This AI approach to automatically capturing user events in webpages exhibits many significant advantages. One of these key advantages is the fact that the AI algorithms are able to retain the continuity of individual element tracking over time, even when minor changes are made to the elements’ code or appearance, or to their relative position within a page. By intelligently analyzing element and context similarity, AI event tracking can maintain tracking continuity so that funnels, A/B testing and other analytics and marketing scenarios don’t break.
Summary
Tracking continuity is one of the big problems with previous attempts to automatically capture user events on websites. Because other auto-capture tools rely on hard-coded element identifiers, they are unable to continue to track elements when minor changes are made to an existing UI element (e.g., changing its class, ID or text) or the webpage in which they exist (e.g., other elements are removed or relocated, changing the DOM structure of the page).
On the other hand, Convizit’s AI-based automatic event capture solution ensures the continuity of element tracking over time, even when minor visual/code changes are made to elements – as is typical, for example, during A/B testing. By intelligently analyzing element and context similarity using AI, Convizit’s tracking of particular elements doesn’t become obsolete and funnels don’t break. Contact us to learn more!
