If you want to skip over the data details, jump down to the Conclusions.
From Jan 1, 2017, to Dec 31, 2017, idratherbewriting.com had about 845,000 page views. Here’s a chart from Google Analytics.
(There was a slight dip mid-year because I split out the API doc site into a separate Jekyll project and didn’t have analytics configured correctly for a couple of months.)
Here’s another slice of analytics focusing more on audience:
The following table shows the metrics from the charts plus some additional detail.
|Jan 1, 2017 to Dec 31, 2017||Number|
(about 2,300 page views a day)
|Sessions (unique visitors)||534,000|
|Pages per session||1.58|
|Bounce rate (visitors who viewed one page only)||79%|
|Average time on page||2:37 minutes|
|Acquisition of sessions from Google search||73%|
|Acquisition of sessions from social media||2%
Twitter (3.1k), Linkedin (2.7k), Facebook (1.4k)
|Acquisition of sessions from direct URLs||17%|
Google Analytics indicates the following about audience demographics for 2017:
In sum, the average reader is a 30-year-old female living in New York using Chrome on a Windows PC who identifies as a technophile.
How did the metrics compare to the previous year? They’re up a bit:
There were at least 66,000 more page views in 2017 than in 2016.
These were the most viewed posts in 2017:
Average word count: 2,451
These are the most viewed posts of all time (since I started blogging in 2006):
These posts are largely the same as in 2016.
Average word count: 1,448
Average word count between top 10 posts in 2017 and top 10 posts of all time: 1,950 words
These are the top 10 pages on my API documentation site.
Average word count: 1,651 words
These are the top 10 pages on my site altogether, excluding blog posts and excluding pages from the API documentation site.
Average word count: 889 words
Average word count between top 10 pages on the API doc site and top 10 pages on the blog: 1,270.
These were my top 10 podcasts.
Average length: 32 min.
The Write the Docs podcasts didn’t have nearly as many hits. The highest show, Write the Docs Podcast #3 - Trends for 2017, had just 587 downloads. The average number of downloads was 300-400 per episode.
I didn’t realize that, for a popular podcast, all you really need to do is read your posts.
I wrote just 72 posts this year. In 2016, I wrote 96 posts. In 2015, I wrote 145 posts. In 2014, I wrote 117 posts. In 2013, I wrote 88 posts. However, I probably added 25 pages to my API documentation site this year, so the numbers probably balance out.
In 2017, my API documentation site received 309,000 visits out of the 845,000 overall visits. This is about 36% of the traffic to my site.
There are 35,408 backlinks pointing to my site. Pages with the most links pointing to them are as follows:
Average word count: 1,490
There are 2,467 URLs indexed on my site. (By the way, these particular backlink stats come from Google webmaster tools.)
These are the top queries and clicks:
It’s unfortunate that the OpenAPI initiative rebranded the Swagger spec as “OpenAPI.” It seems many people search for swagger, not OpenAPI. In choosing to use the “correct” terms for this space, I probably sacrificed a lot of potential hits.
Top countries performing searches:
Mid-way through the year, I started tracking hits on my Jekyll documentation theme. There were 73,000 page views.
However, I’m not sure if these metrics are skewed because the theme gets forked and maybe people leave in the original Google Analytics code? At any rate, I have this analytics code separated out from my main analytics because I don’t display ads on this theme. Still, this is a considerable amount of traffic.
What conclusions can we gather from this data? For example, what topics are of most interest to technical writers and other documentation creators? What is the ideal post length? What characteristics do the most popular posts share? Do the most popular posts phrase their titles as questions, as Larry Kunz observed with his trending content? Do the titles contain other trigger words that generate immediate interest?
Now that we have actual data, let’s make a few simple observations.
These topics seem to matter most to technical communicators:
Why these topics? Maybe just as end-users search for answers related to their “pain points,” tech comm readers also search for answers to their pain points. Perhaps we have questions, challenges, or other issues with these topics that make them particularly [painfully] relevant.
Agile is a hot button for tech writers, probably because of all the problems tech writers face in trying to integrate into the agile flow. Swagger and OpenAPI specifications are hot topics too because they are confusing and difficult to implement. Writers care about language and simplicity yet probably struggle to capture the readability they feel capable of achieving. Topics for beginners are also popular no doubt because of the difficulty of breaking into the field.
(By the way, analytics data explains “what is,” not “why.” We supply the reasoning behind the data mostly through speculation.)
Given the popularity of these topics, should I focus my blog more squarely on these topics of high interest? If I wanted to increase site traffic, these techniques might build more readership, more search results clicks, and more overall visits. Throughout 2017, based on learnings from 2016, I did massively rewrite and expand on the Swagger and OpenAPI content in my API doc site. I focused a bit on agile and trends as well in blog posts.
But if I only write towards what’s popular, the trajectory of my content becomes more like an annoying tennis game where the players move one step closer to each other with each hit. For example, suppose based on my metrics, I write about what gets the most hits — trends. The new trends post goes viral and drives more traffic. I write another post on trends. Bang, even more hits. Now I’m getting asked to speak on trends and people perceive me as a trends expert. In time, my blog is now reframed as “Technical Writing Trends.” When people think of technical writing trends, they think of Tom Johnson. Is that what I want? Which audience am I writing for? And what audience am I missing by not addressing other topics? What about all the readers for, say, science communication?
We write tech docs based on our user’s pain points, but at the same time, on this blog I am not necessarily writing for my readers. I write for myself. I ask questions that interest me. I explore topics I want to know more about. I explore areas I want to become more familiar with.
If it so happens that others have similar interests and questions, then great, we have a connection through our shared interest. That’s how niche communities on the Internet work. The potential audience online is vast enough that I don’t need to worry about what my readers care about. My affinity towards topics will pull out those niche readers from the cracks and crevices of the virtual earth (readers from Hyderabad to Malaysia to Greenland and more) who care about the same topics as I do. Those people searching for “context-sensitive help techniques for tab-based submission interfaces” will suddenly find a new information source in me. Maybe.
In 2018, I want to align myself with who I authentically am — in ways that I’ve never done before. This might involve me challenging more assumptions, being creatively introspective. Inside I am a curious, philosophically wandering sort of contrarian person. In 2018, I’d like to tease more of that curiosity out to the surface.
Last year, I had a similar debate about writing for “readership” or writing for “brand.” I concluded that writing for beginners (hence readership) would draw more traffic, but writing about API doc would establish my brand as an expert. I did the latter, and yes, it largely had the effect I wanted – all my posts about API doc has helped position me as an expert in this area.
Post titles with “realizations” and “failures” and “misconceptions” and “limits” (contrarian triggers) are popular. Why? People are intrigued by the proposition that what they previously thought to be true actually isn’t. Don’t we all like to have the tables turned on our sense of knowledge?
Does the data here mean that I should write more about swagger, agile, trends, plain language, TC careers, certificate programs, etc., and that I should work in the terms “realizations” and “misconceptions” and “failure” into each of these titles? For example:
Hmmm, I would click on each of these articles. So maybe there is something to this game. Put the right topic keywords with the right contrarian trigger words in your title, and you’ve got a great hook. I’m not sure how long game can last (linkbait titles have to actually deliver on the promise), but it might be fun. (Can you tell where I got the motivation for my current post’s title?)
In 2008, I observed that the most popular posts have lists in the titles, but I decided that making laundry lists of everything was artificial and suggested superficial thinking rather than deeper structured arguments (see Three Notable Characteristics of Top 10 Posts: Lists, Headings, Images).
I once read that the ideal length for the most popular posts was 1,600 words — see Clive Thompson on How Tweets and Texts Nurture In-Depth Analysis. This seemed to run against earlier advice about “optimized” lengths for online content, which typically put the recommended word length at around 500-800 words due to shorter online attention spans. Is the ideal length of online content really twice that?
I meticulously measured word counts for these more popular posts (1,950 words) and popular pages (1,270 words) and averaged them out. The average, 1,610 words, quite astonishingly corresponds with the 1,600-word-count recommendation. In The Ideal Length of Everything Online, Backed by Research, the authors analyzed nearly 600 posts on Medium to determine the reading length of the most popular articles. They found:
… an ideal blog post would be one that people read. And Medium’s research on this front says that the ideal blog post is seven minutes long. … in terms of word count, a 7-minute read comes in around 1,600 words.
They depicted this with a graphic:
1,600 words makes for a good guideline to get started.
We’ve found that 2,500-word posts tend to do best for us.
Here’s their graphic:
A few years ago, I engaged in endless debates about the ideal length of content for documentation. See these posts as examples of the content length debate:
I’m not sure we need to debate the length question anymore. We can now use “content science” to analyze the common characteristics of the most popular content online. We don’t have to conclude debates of “how long should a topic be” with answers like “it depends.” The results are in. Longer is usually better. Shoot for 1,600 words but don’t be afraid to jack it up 2-3 times that. (My value arguments post was nearly 9,000 words long, but broken up into a series, which makes more sense to me.)
Not yet convinced? You’re reading a post that is about 4,500 words long. Let’s expand the data:
I think in earlier years, I was following the model that online content should be short, but gradually I started writing longer posts. Long-form content (1,200 + words up to 5,000 +) is clearly trending. In How to Use Long Form Content to Skyrocket Your Search Rankings, the author notes that a study by Backlinko “found that on average, the sites occupying the first page of Google contain about 1,890 words hence.” The author cites another study by serpIQ that looked at top results from Google and had similar findings — “on average, posts with over 2,000 words are ranking much higher than shorter form posts.” Here’s the author’s graph:
Long-form content trends higher in results because more people link to it (thus driving up the rank and authority of the page in Google). People link to long-form content because they perceive it to have more value. Because long-form content surfaces higher in Google’s results, more readers find it and thus promote it more – and so the cycle continues.
How do we square 1,600 words with the 1.58-minute average reading time (rather than 7-minute average reading time, which is what 1,600 words requires) that I observed in my metrics? Most likely the high bounce rate and less-than-ten-second reading times for many visitors throws askew what is probably the normal reading time for a post. That is, for posts that are actually relevant to readers (removing the less-than-10-second visitor), what is the average time they spend reading those posts? My guess is that it is probably at least 3-4 minutes. In that time span, readers can absorb more material. They can jump and scan around more.
Despite the buzz that comes from sharing content on social media, traffic from social media accounts for a small percentage of my site visitors (about 3%). Most people arrive at my site through Google organic (unpaid) search (72%).
My newsletter is the tinyletterapp.com source – it drives 1.75%. “t.co” is Twitter – it brings in 0.52%. And linkedin.com traffic accounts for 0.51%. Heck, even referrals from duckduckgo.com are nearly the same percentage as those from linkedin.com! But organic search accounts for a whopping 72% of my site’s traffic. Even if you were to consider “(direct) / (none)” (which means Google doesn’t know the traffic source) as coming from social media, that’s still a small fraction of the traffic when compared to organic search.
If social media traffic is a pittance compared to organic search, why do we seem to place so much emphasis on social media’s likes, shares, and retweets? There’s something biologically addictive (endorphin releases?) that happens when you see a retweet or a like on social media, or when you see a post shared so much that an actual fire icon appears in Feedly.
But is social media overrated as a traffic generator? Perhaps SEO for Google search should be the overriding concern in each article? Should I lace the content with SEO-rich keywords and phrases? Somehow, I tend to snooze on SEO and instead get more excited about shares on social media, even though I know social media accounts for very little overall traffic in comparison to Google’s organic search. Perhaps I need to find a way to integrate the same addictive checking behavior with Google analytics reports as I do with social media. Perhaps I could set Google’s Real Time traffic report in a more visible space:
I doubt that will happen, though, because as I said earlier, I mostly write for myself.
What can we conclude about the writing techniques (the form) in these popular posts? Perhaps they form a pattern that can help me shape writing that is more powerful, that connects more firmly with people. What did I do right in some of those posts? Was it just the topic, or was it the way I approached it? Did the popular posts contain a story? A particular hook in the introduction, such as an anecdote that people connected with? Did I start with a reader question?
Although I glanced through each of the posts to try to detect a pattern, I could not see any. For example, the posts with a podcasts or graphics weren’t always the more popular. For the most part, with blog posts I try to start with a “relevance hook” — why is this topic suddenly relevant? Was there an experience I had, a newsworthy event, a question from a reader, or some other trigger? That’s just my form of writing. I think it’s a good practice, but I can’t say that it characterizes why posts become popular.
As an end summary:
What will you see in 2018 from my blog? I’ll finish up my API documentation content and publish it as an eBook. I’ll undertake a collaborative project (involving posts and podcasts) to change attitudes that practitioners and academics have toward each other. I’ll dive more into techniques for simplifying complexity, fashioning that content into a more full-length course or book. I’ll post more quick responses from reader questions that I usually answer via email. And I’ll follow up more on how to drive more value to tech comm by centering on pain points of support, field engineering, and marketing groups. So in the end, I’m not drawing my roadmap entirely based on these 2017 metrics. But I will probably keep posts long and make the titles more intriguing.
For similar posts analyzing metrics, see the following:
Get new posts delivered straight to your inbox.
I'm a technical writer based in the California San Francisco Bay area. In this blog, I write about topics related to technical communication — Swagger, agile, trends, learning, plain language, quick reference guides, tech comm careers, academics, and more. I'm interested in , API documentation, visual communication, information architecture and findability, and more. If you're a technical writer of any kind (progressional, transitioning, student), be sure to subscribe to email updates using the form above. You can learn more about me here. You can also contact me with questions.