Analysing analytics
Jeremy Keith
331

Hey Jeremy,

As a digital analyst, I have a few bones to pick with your article. Ultimately, I am glad to see the skepticism of throwing a bunch of third-party scripts on the site. I am totally on board with that sentiment. All scripts should be heavily vetted, documented, and the business value associated with the script should outweigh any performance impact to the site.

I think there is some confusion around data processing vs. data collection in terms of impact to site load. If you’re adding events to your site in order to document user behavior/activity, this does involve some code (either through a tag manager or hardcoded) which does introduce some performance considerations. It falls on the organization to be intentional with their data collection in order to stay away from performance issues (which I am 100% with you on). But to identify data already being collected as a goal (either an event or a destination) doesn’t impact site load, as it takes place during data processing on Google servers. Goals are a great way to segment specific, high-value actions on your site for analysis.

A final thought. You mention “delivering a performant, accessible, responsive, scalable website isn’t enough” as if it should be, and I have to disagree. It’s not enough for a business to simply have a great website if you are unable to understand performance of channel marketing, track user demographics and behavior on-site, and optimize your site/brand based on that data. I’ve seen a lot of ugly sites who have done exceptionally well in terms of ROI, simply because they are getting the data they need from the site in order make better business decisions. If your site cannot do that (ie. through data collection, often third party scripts), then your beautifully-designed site can only take you so far.

Like what you read? Give Kelly Burgett a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.