A post about a comment

Lots of blogs still have sad, neglected little sections exhorting people to “Leave a Reply. Want to join the discussion?  Feel free to contribute!” at the end of each post, even thought all the conversation’s (mostly) long since moved on to other places.

So if you do go to the bother of paying attention to what someone’s written, and then take the time to leave a considered comment, only for it to be deleted… well, that’s annoying.

Which is what happened to me a couple of months ago. The good news is I have my own blog as an outlet for this sort of thing, and I’m screenshot-happy, so my comment wasn’t lost forever.

So anyway. A ticketing supplier put out a post titled “Google Analytics Dashboards – What’s On Yours?” (the lack of link is deliberate). I do a lot of work with ticketed venues (theatres, arts centres, museums, etc) and Google Analytics is very much my bag, so this was right up my street.

It wasn’t a bad post, but a couple of things caught my eye. The main thing was this table…

Google Analytics traffic sources table

Being the eagle-eyed type, I noticed a few issues with the data in that table, so I left the following helpful (I thought) comment…

The traffic sources screenshot is interesting. At a guess, I’d say there’s an issue with cross-domain tracking that’s not been solved properly. Revenue from direct traffic is unusually high, which would be fine on it’s own, but revenue from organic is weirdly low. The two together point to a problem. Usually you see this when the website’s domain has been added to the referral exclusion list in GA, but the tags on the pages aren’t behaving like they should.

Also, the 4th line of that table – it’s been redacted, but I’d guess that’s a self-referral. It’d explain why, of 6,000 sessions, none are from new users.

So my guess is that a lot of revenue is being incorrectly attributed to ‘direct’, making a mess of any ROI calculations and meaning that other marketing channels aren’t getting the recognition they deserve.

I tried to phrase it gently, or at least in a ‘huh, isn’t that interesting’ way. Thing is, this is one of the most fundamental, but also very common, errors that I come across when auditing Google Analytics accounts. I won’t go into it here but it’s not good, causing double-counting of sessions and ruining marketing attribution.

It’s really not the kind of thing you want to be showing off in a blog post where you’re trying to claim how great you are with analytics.

There were two more issues with the post.

One was very minor. The Google Analytics Shopping Report (an enhanced ecommerce feature) was referred to as the Checkout Funnel, which is a different report. Like I say, no biggie

The other was more major. The post ends with “if you would like some help getting these up and running, please don’t hesitate to get in touch.”

As you’ve probably gathered, doing that would be a mistake. If you want a hand with your analytics then you’d be much better off getting in touch with someone who knows what they’re doing.

To be honest, I didn’t expect my comment to be published. I thought maybe they’d correct the errors I pointed out and drop me a line to say thanks for helping them to avoid looking like idiots. You’d have thought that would have been easier. Ah well.

Online fundraising: donate buttons and the need for context

I was flicking through a copy of Now, New and Next, which is a magazine from the Arts Fundraising and Philanthropy programme.

Now, New and Next

There’s a good article about how smaller organisations are diversifying their fundraising efforts and it calls out a few small changes that are making a difference…

Putting in place simple response mechanisms such as donation buttons positioned prominently on websites, collection boxes, and offering the opportunity to top-up the ticket price.

I want to pick up on the ‘donation buttons positioned prominently on websites‘ bit and add something so that people don’t get the wrong idea.

It’s this. I’ve seen websites with donation buttons sprinkled all over the place, I’ve fielded requests to add them (back in my web design agency days), and I’ve seen the stats showing hundreds of thousands of people across multiple websites all ignoring them.

You know that awkward thing where someone goes in for a kiss and the other person dodges?

That’s what it’s like seeing those buttons littered around the place.

That’s not to say you can’t ask for a donation online. Of course you can. But context is key.

A donation button should be there, ready and waiting, when:

  • You’ve provided some sort of value to someone. For instance, if someone has been allowed to download all your podcasts or learning resources then absolutely ask for a donation towards the cost of producing and maintaining those things.
  • The person already has their credit card out. A simple message at the point of making a transaction can work very well.
  • On a landing page for an email/social campaign. You’ve warmed the recipient up to the idea of a fundraising campaign in their inbox or news feed, they’ve clicked through and the call to action on your landing page is there to seal the deal.

You may have your own things to add to that list, and I bet the context is stronger than ‘the person just happens to be on the website’.

It’s why these days the smarter sites are falling over themselves to offer you an ebook, a chance to win stuff, access to a back catalogue… something in order to pull you in. That offer is their most prominent call to action. The idea is that once the person is (contentedly) hooked they can then start building a (more lucrative/engaged) relationship with them. There are even whole products built around this premise.

So to sum up, from what I’ve seen, ‘donate’ buttons on every page on your website are likely to be ignored. If that’s the best you can do for now (and the article was aimed at smaller orgs) then fine, I get it. But I’d highly recommend doing something that brings the person into a context where they’re more likely to want to donate to you. Then you should make the ask.

Notes on what’s on listings for cultural organisations

NB: right now this post is a bunch of hastily thrown together notes. I’ll come back and add, edit, rearrange, and rephrase things later.

What’s On listings tends to live in four places:

  • Dedicated What’s On / listings pages
  • Specific groupings (often season or series)
  • Homepage
  • Relevant other pages – production pages, blog posts, about pages – where productions / what’s on listings are presented contextually.

These might fit on a spectrum depending on the range you show to the user at any point…

  • You pick  (eg. what’s on listings page)
  • Pick from a limited range (eg. season grouping or ‘you may also be interested in’-type recommendations)
  • Our selection (eg. homepage)

These notes are focused on the dedicated What’s On listings that are common to most cultural organisations.

User behaviour on What’s On listings can be lumped into two types:

  1. Browsing (the person may not be sure what they’re looking for, but is likely to have some criteria in mind)
  2. Searching (the person knows exactly what they want and everything else is a distraction)

Users with different aims are going to have different requirements. They’ll want to find their way through event listings in different ways and their mode of behaviour might change from one to another at various points.

There are various tools that can be used on a What’s On listing page to help a user find what they want:

  • A list of every production/event
  • Filters (including faceted search)
  • Date picker
  • Highlight block (to bring up the big show that might otherwise be lost in the jumble of other events)
  • Search bar
  • Personalised results (based on preferences, browsing history, etc)

For example, Hackney Empire’s what’s on listings contains a list, calendar, filters, and a highlight block.

Hackney Empire what's on page

A person searching for a specific event may well just use the search bar, or pick something in the highlights block. Someone who’s just browsing may want the full list, or a broad filter.

Once they’ve narrowed a selection down to a list, how do they parse that? That’ll depend on how big the list is and what their next criteria is. This can be hard to judge but there are well-known trends. For instance, for classical music, repertoire is key.

Following from this, there’s an argument for adding ‘comparing’ as a third mode of behaviour. This often comes into play slightly later in the process, when a user has chosen a production / event and is looking for a particular performance. Have you ever clicked through multiple dates of a show looking for seats in the right area, or for the right price? That’s the sort of thing I mean.


Filters tend to relate to production-specific metadata:

  • Artform / genre / category
  • Theme / season / series
  • Presenting company or cast/creative
  • Repertoire
  • Event type (family, relaxed, etc)

Or more practical logistics:

  • Location (country, city, venue)
  • Date (via a date-picker or calendar) and/or time (e.g. matinee or evening)
  • Price
  • Availability of tickets 

Different organisations will need to handle these in different ways depending on the type of programme they offer, how sets of events might be bundled together (eg season subscriptions), the ticketing system/CMS they have in place, and various other considerations (price and availability can often be tricky to handle for nobody’s particular fault).


The back-end storing of events is in a pretty good place these days. There are good systems that can handle this. Where those back-end systems can fall down is in:

  • Not having custom fields that allow you to tweak the last 10% to get a setup that totally matches your needs
  • Integrating with a CMS or other parts of the digital marketing stack
  • Providing some types of data (I’m looking at you, availability) via an API

These problems tend to be worst for organisations that are using older websites or ticketing systems.


Questions to ask:

  • How much information about a production should be put on the What’s On page? You want to avoid people having to click into every production to get the info they need.
  • Should individual dates for a performance be listed separately?
  • How should productions be ordered?
  • What’s the best way to list everything – grid, list, calendar… other? And if you have multiple options, what should the default be?
  • What do you do with really long listings – paginate, infinite scroll, etc
  • With filters, what order should they be in and what should be the default state of each. Is faceted search a good way for you to go?
  • Whether to put everything together or not (what if a large number of smaller events drown out the main productions?)
  • Should every event be treated the same and given the same prominence?
  • Should events be differentiated in a listing through, for instance, colour coding or iconography?

The optimal layout for listings might depend on whether the user is in a browsing or searching mode. An image-heavy grid might work for flicking through lots of one-off events; a list might better suit someone who’s picking from a filtered selection.


When you’re doing user testing of What’s On listings you might consider testing:

  • User generally browsing for anything at all that might be of interest
  • User looking for a specific show (ideally not something at the top of the listings or in a highlight block)
  • User looking for something featuring a specific cast member (where relevant eg ‘the play with Billie Piper in it’)
  • User looking for something on a particular date (eg when friends will be visiting)
  • User looking for something they can take the grandchildren to see/do

You can also put constraints in the way of people – ie not allowing them to use the search feature.

And don’t forget to test on several types of device. Filters tend to be designed really well on desktop, but less so on mobile because they take up quite a bit of space when open and are ignored when closed (this is a massive generalisation – good examples are out there).

Also, heatmaps are a shortcut to seeing:

  • Which filters people tend to click
  • How popular your search function is
  • Which part of the search listing people click on (non-clickable images are a classic)
  • How far down the page people are willing to scroll

A few cases studies

NB: many of these might be outdated now, with the websites having been updated.

Tate puts all events behind filters, which assumes that nobody is going to be interested in everything and that it’d be best to get some of those preferences down early on.

Royal Albert Hall homepage and what’s on are interesting to contrast.

Royal Opera House again, compare homepage and what’s on.

Southbank Centre Lots of events and an example of the ‘tag everything and let people filter it’ approach.

London Symphony Orchestra a different set of considerations for a classical audience.

The V&A. An example of a complicated one, with a mixture of:

  • paid and free exhibitions
  • permanent displays
  • courses
  • talks/lectures
  • and more…