Issue regarding where feature specific tracking functionality should live

[ifeanyiisitor]

At the moment, our plan is to extract the core (non app specific) tracking functionality from within n-ui and place it in n-tracking. By not placing app specific tracking functionality within n-tracking, we aim to make the n-tracking more cohesive, less magical and less prone to becoming redundant without anyone realising that it has become redundant (See https://trello.com/c/jgUP34ZL/14-js-tracking-initialisation). The problem, however, is that some tracking functionality (like the audio teaser view tracking functionality for instance) is feature specific and as such, span multiple apps, but not every app. Because of this, initialising such functionality within the apps themselves (as opposed to initialising them within n-tracking directly) poses the following problems:

• There will be some potentially significant work to install such tracking functionality on the apps that require them. Such work would include doing an audit of sorts to find out which apps require them.

• If the interface requirements of a particular tracking functionality changes, then multiple apps will have to be updated to reflect the change, which is not ideal. It would be much more maintainable if the change only needed to be made in one place.

• It becomes possible for some apps to be missed out (i.e., not end up being tracked), especially when new apps are created.

Treating such tracking functionality as site wide and thus initiating them within n-tracking directly, would sufficiently address all the aforementioned issues. This would leave us, however, with the problem that it may become possible for such functionality to eventually become redundant without anyone realising it (which is one of the reasons why we wanted to not have app specific tracking functionality living within n-tracking).

It seems that such tracking functionality, due to being feature specific, should really be colocated with the specific feature that they track. This way, every app that pulls in the feature, will automatically get the tracking functionality and if the feature is decommissioned, then the tracking functionality would also automatically be decommissioned. The following may be needed, however, to make this work:

• If the feature is not well encapsulated, some work may be needed to encapsulate it, and this work may include having to amend multiple apps in order to have them use the encapsulated variant of the feature.

• If the feature is well encapsulated but is not only used by ft.com (like an origami component for instance), then some work will be needed to create ft.com variants that wrap the original feature, so that the tracking functionality may be added onto it. Such work would also involve multiple apps having to be amended to make use of the ft.com variant of the feature.

Any thoughts?

[i-like-robots]

I'm going to start by adding some folks to this discussion who I think may have some insight into this problem:

@kavanagh @debugwand @adambraimbridge @tbergmen @carlesandres

And to pick up on some of the specific points raised...

This would leave us, however, with the problem that it may become possible for such functionality to eventually become redundant without anyone realising it

Yes, we have tracking code which we still ship but has not been relevant for nearly 3 years!

It would be much more maintainable if the change only needed to be made in one place.

Absolutely. Taking the audio tracking as an example, if we're rethinking tracking initialisation can we not make it possibly to locate the tracking inside the audio component?

[tbergmen]

I would like to tag @saldixon for this issue. She has implemented the custom tracking code for teaser testing in the next-front-page.