How Ghost increased conversions(blog.ghost.org) |
How Ghost increased conversions(blog.ghost.org) |
In general, though, strong endorsement of figuring out what people care about quantitatively and qualitatively, instrumenting that, and then testing early in the funnel improvements to it. The gold standard is, of course, not doing retrospective analysis but rather split testing the intervention. I sympathize that this is difficult for a lot of SaaS apps as you need high trial volumes to make it work.
I can't share client results but my blog probably has two or three write ups of 10%+ lifts for BCC doing this.
It is not included in this post whether the overall conversion rate actually improved substantially after the changes were made.
The title of the post is "How we Figured Out What Makes People Love Ghost 1,000% More" - which I think is still pretty accurate :)
I disagree. If you choose the bucket "people who subscribed to Ghost Pro", they would convert ∞% better than the bucket "people who didn't sign up for Ghost Pro". That doesn't mean that signing up for Ghost Pro makes people love Ghost ∞% more.
More generally, how can you tell if people installing a custom theme makes them love Ghost more, or if people install a custom theme because they love Ghost more?
Getting more people into the bucket of "people who installed a custom theme" doesn't actually help your bottom-line conversion rate until you can establish unequivocally that the people you've added to the bucket convert at the same rate as the bucket did before they were added to it.
Did this end up raising overall conversion rates proportionally? It could be that users who would already have converted in the end are more likely to bother to set up a custom theme.
Ok, so that may not sound totally convincing, but in general I think it is a big problem with the analytics in the article. If you can't tell if A caused B or B caused A, then you can't reliably act on it.
I love Ghost's simplicity for blogging, but then I spotted an egregious spelling mistake in one of the articles I'd published. I went back to the editor to check where I'd missed the ubiquitous red squiggly line, and found there wasn't one. No squiggly line, and in fact no spellchecker at all!
Given that spelling is very important for blogs, and that all browsers have very effective spellcheckers built in, I'm at a loss to understand why this wasn't bug number 1 to the developers. They use a markdown editor that somehow kills browser spellchecking, but there are several alternatives out there and this was a definite "Oh no!" moment for me.
As a user, however, I'm annoyed by videos, and hardly ever watch tutorial videos. Why spend a minute and a half watching something when I can read it much faster? Especially if setting up a theme is as easy as you're trying to make it -- shouldn't it be obvious how to do it?
Me and my girlfriend are looking for some gigs so we can buy a ticket plane and meet in February (she is in Italy right now while I am in China).
She is working through her PhD in Statics while I am a developer with a lot of interest in data analysis and visualization.
If somebody need the same analysis they did a ghost it is something we can handle pretty well.
If you want to collaborate just drop a line at: simone (at) mweb (dot) biz
[End off topic, and sorry about that]
This is incorrect. Let's say we have two buckets, A and B, where bucket A is people who haven't used a feature and bucket B is people who have. If some testing shows that people in bucket B convert far better than people in bucket A you make a change to get more people into bucket B. The change is successful if more people end up in bucket B and bucket B still outperforms bucket A and the total contribution coming from bucket B is higher. Bucket B doesn't need to perform equally well before and after the test.
Using the numbers from the link bucket B was performing at 10x the conversion of bucket A. Out of 10,000 users bucket B contributed 70 subscribers. After the changes bucket B received almost five times the users as previously and converted at four times the rate of bucket A. Out of 10,000 users bucket B contributed 884 subscribers. If the change had no impact we'd expect more users in bucket B but not more subscribers. These numbers aren't really accurate since I took them from the diagrams in the article and they change what they're looking at between the two. To be correct you need to compare the same thing before and after changing a feature.