Summary
We’ve recently moved over to using Google Tag Manager (GTM) on the redesign of Worldgallery. The promise of being able to “update your website tags…without bugging the IT folks.” was too hard to pass up. The reality of GTM, however, has proven to be something all together different.
We also use Optimizely quite heavily on the new site. And the easy integration with Google Analytics(GA) via Custom Variables mean that we can easily segment the Optimizely visitors by buckets. For instance, we can run a report that gives us “Ecommerce value of all visitors who saw Version A of the checkout page” or “Time on page for visitors who saw Version B of a certain landing page”. This greatly enhances the default reporting from Optimizely.
The Problem
Now that Google Tag Manager is responsible for loading all javascript on the page, we need to be sure that they get executed in the correct order. And that order is 1) Optimizely followed by 2) Google Analytics
By default, GTM does what it does as and when it sees fit. So we can’t be sure that the tags will fire as needed. However the fix for this particular problem has already been solved.
In a nutshell:
- Load the Optimizely code in a GTM Custom HTML Tag.
- Then set a dataLayer variable in that tag which says “OK - Ready to go”
- That then triggers the GA pageview to fire. Simple!
But that wasn’t enough to make it work…
Yes, we could fire the GA pageview at the right time - after Optimizely has done it’s thing. But for some reason the Custom Variables still weren’t being sent along with the request.
The Solution
Fast forward about 30 hours of head-scratching and a large handful of experiments. When finally the missing piece of the puzzle was found.
There is a poorly documented feature of GTM for the Tracker Name setting. Reading this would lead one to believe that all this setting does is allow you to “name the tracker object yourself”.
What isn’t mentioned is that by turning on this setting (which can be found under Advanced Settings for the Page View tag) you effectively make the tracker name public. This is your UA-XXXXXX-X number. Without this information Optimizely is not able to set the Custom Variable correctly.
Conclusion
If you use Google Tag Manager along with Optimizely and want to take advantage of Google Analytics Custom Variable segmentation - pause for breath - then you need to:
- Tick the box next Tracker Name under Advanced Settings (but don’t fill anything in the text box!)
- Follow these instructions to ensure the correct load order of scripts
- GOTO PUB
Leave a comment
In reading What CTOs Fear Most, it’s clear that managing priorities is a common fear amongst technical managers.
The Easyart technical team is in the midst of redeveloping a platform that has been running for well over a decade, we are continually faced with difficult decisions about what features are worth migrating, and how they compete for resources with new features.
In our circumstance, retaining a feature is actually a new development task which is competing with every other task. Most of the existing features are there for good reason, but it’s worth challeging the idea that every old feature is going to have more business value than the new features they are competing with.
Just because we can, it doesn’t mean we should. Just because a feature exists, removing it doesn’t necessarily make the product poorer. This point of view can be unpopular but the opportunity to shed some technical debt and rationalise our offering can make the hard work worthwhile.
Julie Zhuo, Product design director at Facebook makes the point well in her fantastic blog post The Tax of New (paraphrased here):
Run that line of thinking too many times and you get death by a thousand paper cuts. This is how good, simple products become quite the opposite.
The tax that comes with introducing any new feature into your product is high. I cannot stress this enough. Sure, maybe the new feature isn’t hard to build, maybe it only takes a couple days and a handful of people, maybe it can be shipped and delivered by next week.
Perhaps you will continue to develop and evolve it. Even if you don’t (maybe your plan was just to launch it and move on), the fact of its existence will inevitably create more work for you. You will get user requests and bugs about it. You will spend time thinking idly about ways to make it better. It will likely pop up in the context of your next redesign or code rearchitecture.
Another great article on the topic by Yammer’s CTO, Kris Gale, on technical debt and complexity:
For years, the two things that most frustrated me to hear from product managers were “how hard would it be…” and “can’t you just…” It took me quite a while to figure out why I had such a strong, visceral reaction to these phrases. The answer seems obvious now: The work of implementing a feature initially is often a tiny fraction of the work to support that feature over the lifetime of a product, and yes, we can “just” code any logic someone dreams up. What might take two weeks right now adds a marginal cost to every engineering project we’ll take on in this product in the future. In fact, I’d argue that the initial time spent implementing a feature is one of the least interesting data points to consider when weighing the cost and benefit of a feature.
And this brilliant rant by Des Traynor argues that there is simply no such thing as a small change:
Agreeing to features is deceptively easy. Coding them rarely is. Maintaining them can be a nightmare. When you’re striving for quality, there are no small changes.
When you release a feature it’s not the end of the job, it’s just the beginning!
Thankfully none of this means we should avoid new ideas or innovation, we just need to put some process around our decisions to ensure that new features are providing value, not just technical debt.
For existing features, study the data. If this feature is providing real business value, it’s worth retaining and developing further. If not, consider removing it.
For new features, it’s important to define success criteria upfront. If the feature doesn’t meet the measure of success you’ve defined, remove it. And if it does, we know the debt is worth taking on. Ideally these metrics should be published so that later down the line when someone asks “why do we have this feature”, there is an answer to point to.
Adding these processes requires great discipline, but it provides a confidence that every new feature is providing real value to the company.
Update: some discussion on Hacker News
Leave a comment
After a period of beta testing, user testing and painful analysis, last week we migrated WorldGallery.co.uk to Kubrick, the new platform we’ve been working on in the London office. Kubrick’s primary objectives are textbook e-commerce, but the technology and processes are a bit more interesting (which I will write about later)
Improving conversion rate
When you have a product catalogue as extensive as WorldGallery, it’s a challenge to help users find the product they want to find. I think this is particularly true of art products which are often difficult to categories.
The primary focus has been a new category structure, and adding the capability for users to navigate directly to artwork, artist or category pages via a new search auto-suggest feature. The result is a more curated user experience.
- Key tech: Rails, Sinatra, ElasticSearch, JSON
Improving AOV
We have a massive range of frames and a brilliant team of master framers, and frankly we need to do a better job of getting our customers interested in frames. To do this, we’ve integrated framing directly into the main product page and made it near-instantaneous to navigate between various types of unframed, canvas or framed products.
Increase traffic
We’ve vastly simplified the structure of the site (focussing on artworks, categories, artists and artworks), resulting in one authoritative URL for each page (rather than rewrites which can result in multiple URLs for a single entity).
For example, the “Modern Art” category used to be available via a number of URLs like these:
- /mt/Modern-Art-Prints-51-2.html
- /category/modern-modern-59.html
All of these should now redirect to the one “true” modern art category: /art-prints/modern-art. This is better for users and better for Google.
- Key tech: Rails, Rack::Rewrite
We also had some secondary goals in this development:
- Make the site mobile-friendly for the 25% (and rising) of users that access our sites on tablets or mobile
- Improve engagement (measured in time on site, number of page views and return visits)
- Improved monitoring
- Automated testing on everything
- Increased speed of development
We’re already seeing some positive results and look forward to migrating some of our other sites over.
Leave a comment
Nobel Laureate Daniel Kahneman:
Somewhat surprisingly, few organizations keep track of what’s decided and why.
This seems idiotic when you consider that often thousands of dollars are spent making a decision. Of the few that do keep track of decisions, fewer will be honest about what’s actually discussed.
This one of the reasons I think it’s worth spending work hours blogging. To distill ideas and decisions and share them with the organisation and your peers.
Via the wonderful Farnam Street.
Leave a comment
