Posts Tagged ‘Tracking’

Analytics

The short answer is yes – the product/team will definitely benefit by having web/app analytics tracking as part of the definition of done (DoD).

The only time that a separate analytics tracking story should be written and played is typically in the scenario of:

  1. There’s no existing analytics tracking, so there’s tracking debt to deal with including the initial API integration
  2. A migration from one analytics provider to another

The reason why it’s super important to ensure that analytics/tracking is baked into the actual feature acceptance criteria/DoD, is so then:

  1. It doesn’t get forgotten
  2. It forces analytics tracking to be included in MVP/each product iteration as default
  3. It drives home that having tracking attached to a feature before it goes live is just as important as QAing, load testing, regression testing or code reviews

Unless you can measure the impact of a feature, it’s hard to celebrate success, prove the hypothesis/whether it delivered the expected outcome or know whether it delivered any business value – the purpose of product development isn’t to deliver stories or points, it’s to deliver outcomes.

Having a data-driven strategy isn’t the future, it’s now and the advertising industry adopted this analytics tracking philosophy over two decades ago, so including analytics tracking within the DoD will only help set the product/team in the right direction.

wpid-tag-management.jpg

The top two tag management tools currently on the market are BrightTag and Tagman. Both offer more than just tag management such as attribution modelling and performance reporting.

As clients add front end marketing data into their in-house DMP’s, elements such as attribution modelling and performance reporting is pulled from the DMP. I have mentioned this before, but the reason why attribution modelling and performance reporting should always be driven from the in-house DMP is because the data will be:

  1. Across all channels and data sources.
  2. You can build your own custom attribution models.
  3. Performance is defined across a multitude of KPIs such as cohort ROI, projected ROI, cohort CPA and projected CPA.

Let’s focus on the actual tag management feature, this has certainly been attractive to many brands over the years especially those dev teams who take + 12 months to implement a new tag (I have personally witnessed this for a car insurance brand). Times have changed, websites are now more advanced than ever alongside more advanced products across multiple devices which has led to a prioritisation of developer recruitment in-house. As a result something like creating a tag management feature within their back office system would be second nature to the majority of dev teams.

What they’d be able to build which would typically take one developer two weeks to a very maximum of one month including QAing would be:

  • Compatibility with all tags including floodlights, analytics such as GA, SEO tracking.
  • No limit to volume of tags.
  • Implementation by URL string.
  • Fire pixels based on variables.
  • Passing back variables to pixel suppliers.
  • Killing a tag from loading if the response from the third party is slow.
  • Asynchronous tag loading.

Sending a work request to your dev team to build a tag management feature in your in-house back end system certainly proves to be cost efficient as you’ll find it would save you at least £60k to £100k every year. Those who aren’t motivated to build a brief like this or have much dev resource then there is the completely free Google Tag Manager product available.