I once had a client, a high-volume WooCommerce shop, who was convinced that a “Quick Reorder” button on the customer dashboard would send repeat sales through the roof. We shipped it in a week: clean code, tidy UI, no bugs. A month later the conversion rate had not budged, and the client was looking at me like I had sold them a lemon. I spent three days tweaking the button’s CSS on the theory that it did not “pop” enough. Complete waste of time. The styling was never the problem. We just had no idea how to measure feature impact properly.
Developers fall into the trap of assuming that live means working. Without the right signals you have no way of knowing either way. I eventually ran into the TARS framework in an article over at Smashing Magazine, and it changed how I talk to clients about success. It pulls the conversation away from broad conversion rates and toward what is actually happening in the product.
Why conversion rate cannot answer this
Conversion rate is a terrible way to judge one specific feature, because far too many things move it. Marketing might have run a bad campaign. There might be a latency issue in your REST API. You can have good UX and low conversion, or a genuinely messy UI and high conversion because the product is exclusive enough that people put up with it. Judging a feature means breaking that number apart.
TARS stands for Target Audience, Adoption, Retention and Satisfaction. Rather than watching the whole shop, you work out which share of users actually needs the feature and track only them. When I ran that on the “Quick Reorder” button, it turned out only 5% of the shop’s customers ever ordered twice. The target audience was tiny, so of course the overall conversion rate stayed flat.
Tracking adoption in code
To measure feature impact you have to hook the usage events themselves. Page views will not tell you whether anyone clicked the button, and they definitely will not tell you whether it solved the problem. Below is how I usually wire up a tracking hook in WordPress that logs those events without bloating the database.
/**
* Track custom feature usage for TARS metrics
*
* @param int $user_id The ID of the user.
* @param string $feature_name Unique slug for the feature.
*/
function bbioon_track_feature_event( $user_id, $feature_name ) {
// We don't want to flood the main options table.
// Use a custom table or a lightweight logging service.
$timestamp = current_time( 'mysql' );
// Example: Logging to a custom telemetry endpoint
$log_entry = array(
'user_id' => $user_id,
'feature' => esc_attr( $feature_name ),
'event_time' => $timestamp,
'is_returning' => bbioon_check_if_retained( $user_id, $feature_name )
);
// In a real scenario, you'd send this to a tool like Segment or Mixpanel
// Or even just a local custom table for internal audits.
error_log( "Feature Usage: " . json_encode( $log_entry ) );
}
/**
* Check if the user has used this feature before (Retention)
*/
function bbioon_check_if_retained( $user_id, $feature_name ) {
// Logic to check historical usage
return get_user_meta( $user_id, '_bbioon_used_' . $feature_name, true ) ? true : false;
}With that data you can read the pattern. High adoption and low retention means the feature is interesting but not useful. High retention and low satisfaction means people use it because they have to, not because they like it. Getting to that level of detail is why better developer documentation and honest planning save businesses a fortune later.
What skipping this costs
Building the shiny thing is easy. Proving it was worth building is the hard part. I have watched teams spend six months on a feature that 2% of its target audience ended up using. A repeatable metric like TARS, or the original concepts by Adrian Raudaschl, would have surfaced that in week two. The data does not care how clean the code was.
This gets complicated fast. If you are tired of debugging someone else’s mess and you want results you can actually measure, drop me a line. I have probably seen it before.
If the total sales graph is still your only measure of success, you do not really know how people use the things you build.
