Importance of feature tracking -Rockstar developer’s trait.

— by Sambhav Jain

As developers we ship 100s of features month on month. New Features comes in every sprint cycle and we move on to ship the next 100. We even monitor our services, web performance cycles, page-speed scores, SEO and all engineering activities. But how many of us have turned back and said

“Let me have a look at the feature I have shipped in last release, and see how it’s performing ? Was it worth my time and effort ?”.

If the results were below average then you have just lost your precious time you didn’t realise. Developers often loose their effort, which can be utilised in reducing tech debt or work on something impactful for business. But we won’t be knowing this if haven’t asked ourselves this question. Knowing that we loose something is important. So that we can counter this part and get a learning from this and analyse what went wrong. Asking questions is what makes us analyse and activate critical thinking part of our mind.

Asking questions is what makes us analyse and activate critical thinking part of our brain.

Importance of analytical events

There comes the importance of events we add for each feature. Events are responsible to track a features performance on ground or I would say here on user’s experience. Generally, a product person would come to us with a feature and also gave us some events to add. But it’s not just for them. It is for us as well, to track our shipped feature, so that the next time a relatively same feature comes we can ask question or raise a concern over that. This practice will save our and product owner’s time. He might have missed some insight, which we can provide or can counter the discussion with data-driven approach.

How to create this as a process

1. Do not create features without proper events. Always ask your product owners to provide proper events before proceeding to dev.
2. Make sure any new feature should not be shipped w/o events.
3. Events can be triggered on simple user actions like view, on-click, on-hover, etc.
4. After shipping the feature, take help from product owners to walk you through analytics dashboard. (One time activity)
5. Check appropriate funnel (this you can also take help from product owner) to analyse the feature’s impact and other conversion factors.
6. Now, take 5 minutes per feature to see its activity and further impact on conversion.
7. You can do the above step anytime of the day, but generally it’s better to have a look just before your daily scrum call. By this way you have something to share and raise concern if requires.

Conversion Funnel Jargons

1. Onboarding journey: This will be a page-view event generally which fires, when user landed on a page.
2. I2V <Impressions to View>: When user sees a list of items, those are impressions firing for each view item. And then user clicks on a single item is and land on its detail then view event is fired so Impressions to view conversion.
3. V2BI/AddToCart: when user clicks on a button for creating the order i.e Booking/Order Initiated or Add to Cart or Buy Now.
4. BI2BC <Order Creation to Successful Payment done>: Steps involved from add to cart to final payment and confirmation order success screen.

There can be post booking/order confirmation funnel as well, depending on the use case.This basic funnel can help us track our feature’s impact on the conversion.

Use-case

Let’s say we have added an educative tooltip in our product detail page, which basically educates user about the current item. Now, we need to check if that feature is actually improving our conversion from view to order creation. For this, we can track the number of clicks on that tooltip and conversion rate for those users which have clicked on that tooltip and clicked on order creation. So our View to Order creation funnel is impacted positively due to this small feature. Although A/B test experiments also comes into the picture in more precisely identifying the conversion/drop cause, which you can also ask from your product owner, how is the experiment working, to keep a check.

Key takeaway: Analytical decisions should be driven from data. Owning the smallest feature in a large ecosystem is the start of your exponential growth from junior to a rockstar developer.

Conclusion

As developers, we kind of fall in a trap of development and engineering cycle. And often miss out, that the core part of engineering existence is to benefit the end user and business. Feature tracking plays an important role in that. This trait is basically what differentiates between an average and a rockstar developer. This is something senior developers and leaders should encourage junior developers to do and create an ownership mindset. Ownership is not only developing the feature end to end. It’s also to monitor and make analytical decision based out of it.