Cancel

Sarah Gooding

Why You Should Never Add Analytics Code to Your WordPress Theme

gaThis is a simple thing but it bears mentioning. Many major WordPress theme providers offer the ability to easily add Google Analytics or other tracking code via the theme’s options panel.

The idea stems from wanting to market a theme with everything needed to create the website that you see in the demo. Theme developers have been successful at selling themselves as one stop shops. To that end, they often pack WordPress themes full of code that is better suited to the realm of plugins.

One common example is a theme option to add tracking code. It’s likely one of the last options listed in your theme’s dashboard panel. It’s a really easy place to add Google Analytics code, but please resist the temptation to paste your code in here.

Analytics Code is Not a Theme Feature

Site analytics are not a theme feature and simply do not belong in your theme. Analytics has nothing to do with your website’s design. Even if Google tells you to add this to the header of your site, do not directly edit your theme.

The reason for this is that WordPress themes were made to be easily swapped out. More than likely you’re not going to use the same theme forever. But if your analytics code is in your theme options, then you’ll lose it when you change themes. By the time you realize it, you may already have large gaps in your analytics.

Do yourself a favor. Instead of adding the code to your theme every time you change themes, just drop it in a plugin. There are plenty available on wordpress.org. You’ll only have to add it once and it will be safe when you change the design of your website.

Theme Developers: Stop Tying Data to Themes

Portability - I has it
Portability – I has it
This discussion boils down to data portability, a topic of recent conversation on Justin Tadlock’s blog: Why custom post types belong in plugins. If you’re a theme developer, please do not tie any form of data or content to the themes you create. This includes analytics, shortcodes, custom post types, booking and event management, testimonials, fundraising functionality, portfolios, etc. The list could go on and on.

If a user cannot quickly pack up his data and go after using your theme, then your product has become a dead weight. In a perfect world, WordPress consumers will start looking at themes with this question in mind: “If I wanted to stop using this theme tomorrow, could all my data go with me?” If you’re selling a product that doesn’t pass that test, then you might want to make a few changes for the sake of data portability.

Better options would be to include functionality plugins with the purchase of the theme or recommend a high quality plugin to accompany it. Keeping those functions separate from the theme itself will help users to take their data with them when they change themes. As a bonus, it’s also easier to troubleshoot when providing support. Let’s just keep themes clean. We’ve all been guilty of hindering data portability in the past, but now is good time to start building WordPress products differently.

Category: ,
Tags: , ,
31

31 responses to “Why You Should Never Add Analytics Code to Your WordPress Theme”

  1. agreed x 10000!

    Used to be cool to simply swop out a theme and all content remains in tact. After all thats the whole point of a ‘theme’ right?

    The shortcode fad along with making things built in becomes really frustrating, more often then not when clients want a design changup, it turns out to a full blown revamp and redoing content and pages!

  2. Which is why Themes hosted in the official WPORG Theme Directory are not allowed to include site analytics options (or other, similar functionality-not-presentation features).

  5. Nearly every major WordPress theme provider offers the ability to easily add Google Analytics or other tracking code via the theme’s options panel.

    I’d at least think the major providers wouldn’t do this. I like to consider myself in that pool of theme providers, and it’s something I definitely don’t do.

    @Devtard

    I actually prefer to hardcode similar things into the theme – I try to avoid unnecessary plugins whenever I can.

    I’m not sure how that makes it an unnecessary plugin. It literally takes the exact same amount of code to add it via plugin as it does via theme. This is precisely the reason the plugin API was created for WordPress.

    Not to mention, whenever you change themes, you’ve got to remember to copy and paste that code into your new theme.

  8. Hi All

    I just completed a cert in Google Analytics Fundamentals, unfortunately the coarse ends tonight. (If certs are what your into) Google recently announced that they are going to keep the lessons online.

    As a knowledge base this is a fantastic resource, certainly the best online coarse I have yet experienced. Don’t let the word ‘fundamentals’ mislead you, it really goes in to a lot of detail, best practices and is perfect for online sole traders and SMEs.

    Don’t be surprised if you gain a whole new perspective on analytics and how valuable the data they provide can be.

    Yoothemes is perhaps the biggest theme shop I know of that adds Analytics to their themes. Good themes, it’s just shame that people may loose information unknowingly and needlessly. Good developers, and Yootheme are brilliant developers, should know better.

    I can’t complain. I submitted a theme to the WPORG repository, a few weeks back, with a Custom Post Type, for a slider. I had assumed that sliders where presentational, I never gave a second thought to data portability. This functionality is so pervasive in commercial WP themes that I was surprised. I was pointed to Justin’s above article which makes perfect sense.

    I was certainly aware of lock-in features but I wasn’t aware of it’s extent, there are still some gray area’s I’m still not so certain about, such a widgets. I remember that question was addressed in an article by Brian Krogsgard on Post Status, I just can’t find the link. I recall that there was ticket, but it never materialized.

    That feature implemented would be great to see!

  10. @Justin Tadlock – You are right.

    But I regard any plugin that does only trivial things (which can be easily done manually) as unnecessary. If I had to use a special plugin for every tiny change (e.g. for adding new sidebar/footer links), it would drive me crazy.

    I usually tend to check whether the plugin is safe to use – doing that every time a new update is available would be insane. Not to mention dealing with potential incompatibility issues, poorly written code etc – that’s really something I’d want to avoid.

    I don’t switch themes very often anyway. Besides, tweaking my own theme makes me happy. :)

  11. But I regard any plugin that does only trivial things (which can be easily done manually) as unnecessary. If I had to use a special plugin for every tiny change (e.g. for adding new sidebar/footer links), it would drive me crazy.

    To each, his own of course; but I’m exactly the opposite. I’d rather have 60 single-function Plugins active than one Plugin that does 60 different things.

    I usually tend to check whether the plugin is safe to use – doing that every time a new update is available would be insane. Not to mention dealing with potential incompatibility issues, poorly written code etc – that’s really something I’d want to avoid.

    The ease of verifying the safety/integrity of a Plugin update is inversely proportional to the complexity of the Plugin.

    I don’t switch themes very often anyway. Besides, tweaking my own theme makes me happy. :)

    If you’re in complete control of your own Theme, then it makes little difference whether your functionality code resides in Theme or Plugin. But if you’re not in complete control of the Theme, then you’re just setting yourself up for problems.

    My personal preference is a site functionality Plugin, that separates out different functionality into different sub-files. It makes troubleshooting as simple as commenting out the include() call for a given sub-file.

  12. I’m also in the camp of “as less plugins as possible”, BUT when it comes down to these things.. leave it to the plugins.

    It’s the reasoning of “everything in one place” that makes some themes a bloated mess. I remember having to hack a bestselling TF theme that the client already bought as a cheap all-in-one, ending up in a 10s homepage load.. and afterwards a bill from me..

    Plus, the portability of content is priceless, as demonstrated by another company, where one guy, not hindered by un-knowledge decided to ‘quickly and swiftly’ replace the theme (because he could, right ?), in the process cancelling out hundreds of portfolio posts already put in by his co-workers.

  13. @Devtard – I like using single-use plugins because they have this very nice link next to them called “Activate” or “Deactivate”, which lets me play around with which ones are working when I’m trying to figure out how things interact.

    I could do the same thing in a single file and edit the code to comment out lines and such, but having on/off switches is pretty handy.

  15. A point worth noting. We’ve had this issue whenever we had to themes on website with custom sidebars. Our angle for this particular problem was to integrate an importer into our own solution for custom sidebars (Power Widgets). The importer allows you to inherit custom sidebars settings from the old theme and keep them active on the theme, with the ability to match sidebars to inherit old settings – this comes handy whenver themes vary in their default widget areas. The feature explained here: http://goo.gl/QVCuGq
    Feedback welcome

  17. AAAAGREEED!
    Roots theme has GA in there and I brought it up to them in issues or on twitter (i forget) and they couldn’t see my point… refused to accept the idea that it shouldn’t be in a theme.

    And then things like this: https://github.com/roots/roots/pull/891

    like… whatever. But agreed. GA and CPT’s and metaboxes etc shouldn’t ever be in a theme. Maybe theme devs will include an optional plugin that does some of that

  18. I’d recommend using WordPress SEO by Yoast and adding your analytics number through that plugin. If you change or update your theme, the tracking will still be there and this SEO plugin is an essential install for me.

  19. @Chuck Reynolds – Using Roots theme is slightly different as it’s intended to be a base-theme structure for any custom-built theme. Assuming the site is custom, the owners and developers will continue to utilise the Roots theme as the base framework as apposed to swapping other generic designed themes.

  20. Interesting point of view, but WordPress Themes become more complex and its sometimes difficult to keep all their functionality away from their own framework or structure. Yes, there are plugins, and themes are primarily intended to represent the look of the websites, but people are willing to have an all-in-on solution. Probably there should be certain rules or standards to somehow separate the visual representation from the functionality and in the same time to keep the layout attractive for customers.

  21. @Igor Pisov –

    Interesting point of view, but WordPress Themes become more complex and its sometimes difficult to keep all their functionality away from their own framework or structure.

    Themes should be presentational, period. The primary problem in the market is that end users are unaware of the problems created by Themes defining site functionality and content generation. All we can do is actively try to educate end users, and eschew marketing tactics that are harmful to end users.

    Yes, there are plugins, and themes are primarily intended to represent the look of the websites, but people are willing to have an all-in-on solution.

    Again, the problem is end-user education. That “all-in-one” solution is and will be harmful to the user. Users are “willing” to have that “all-in-one” solution because they are unaware of the harm such a solution causes.

    Probably there should be certain rules or standards to somehow separate the visual representation from the functionality…

    The Theme Review guidelines for Themes hosted in the official WPORG Theme Directory prohibit Themes from implementing non-presentational (i.e. “Plugin territory”) functionality. Other directories are starting to follow suit, including ThemeForest.

    …and in the same time to keep the layout attractive for customers.

    Google Analytics (and myriad other functional elements) have absolutely no impact on the layout, whether added via Theme or Plugin. They are fully functional, and not at all presentational. Thus, the attractiveness of the layout cannot be adversely impacted by placing that functionality properly within a Plugin.

  24. @Chip Bennett – I agree with the most of your statements, but I think the process of educating end-users is quite difficult at this point, but possible (giving the current scale of WP themes market) and I was referring to a theme’s attractiveness as a product (not in terms of visual representation). As of standards, I think TF admitted this deviation for marketing purposes and now are starting to set up and follow some new guidelines to have a better compliance with everything we’ve discussed earlier. We’ll see what happens, regards.

  25. Can see the logic to this, but would disagree. Adding an extra plugin just in case you forget to migrate the GA code isn’t a great reason… trying to run a site with as few unnecessary plugins as possible is more important IMO.

  26. Great point. There so many great themes and theme companies out there that integrate this and don’t think of the consequences you mention.

    I always use plugins as much as I can and the least within the theme options provided.

    However, I haven’t swiped one theme yet in the last 5 years on any site where I didn’t have to do some tweaking. Especially with themes that have options in the framework.

  29. Thanks for mentioning this. I just swapped my theme and was wondering if Analytics and Webmasters were still tracking. They say they are, but they don’t seem to be, and I can’t find the code in the new theme’s Editor file.

  31. I disagree you can’t be relying on plugins for everything, just put the code manually on theme. if the theme already provides a way to put the code from the admin dashboard even better for the people that don’t want to edit files. It’s a pretty neat feature.This post is rather absurd and wrong.

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: