This post presents a portion of a LinkedIn conversation thread dealing with using analytics, such as Google Analytics, in tech comm. The thread picks up with my request to the original post. (Thanks to Evin Wilkins for starting this whole thing, and Hagay Vider, Matt Sullivan, and Marion Deland for the responses that form the thread.) And with that...
----------------------------------------------
Neil Perlin
President, Hyper/Word Services
… I'm going to be guest-editing an upcoming issue of the
STC Intercom magazine with the theme of the bleeding edge. I've got all my
topics covered save for one, the use of analytics with regard to tech comm and
online help - RoboHelp, Flare, et al. I'm having trouble finding a writer for
that topic but I'd hate to omit it. Hagay and Matt and everyone else - do you
guys know of anyone who's familiar with analytics and who's used it in a tech
comm context?
Hagay Vider
Technical and Marketing Communications Manager at High
Security Labs
Neil, if you're looking for content professionals who use
Google Analytics, then you should be looking in a different direction. I have
used GA for other purposes, not to get usage statistics of technical
documentation, but I understand your reasoning. You should look towards other
fields for inspiration.
The most common use of GA is to "monetize"
content, meaning that web site owners write content that would grab eyes, which
justifies charging money to advertise on their sites. This is different than
the Wall Street Journal selling subscriptions, and then restricting some
content only to paid subscribers. This is free and open content that's paid for
by ads.
Technical documentation is not often monetized, since
it's usually provided as a type of "customer service" to customers
who already bought the product. The only reason I can think of to perform
analytics on technical communications is to coordinate with customer service.
Where do customers look for information? What information is missing that
causes them to open a service call? Should we include this information in the
documentation to prevent service calls?
GA is often used for free sites that provide useful
information to readers who will follow through with purchasing a product. Such
sites include articles on investing, consumer issues, dieting, health and food.
These are often the most popular sites, and advertisers know that their readers
are ready to make a purchase. The more hits their pages get, the more money
they can charge for ad space. Some of the larger sites have a "contact
us" page where they sell ad space directly to customers. They provide
analytics results as part of the quote. The smaller sites use Google AdSense
some other ad space marketing service.
Another group of sites are "news aggregators".
They copy news sites on a wholesale basis, and save the content for subscribers
who do research, want to dig up require old content and the like. The analytics
helps them know which information is in demand. This is much closer to the
requirements of technical documentation.
In any case, using GA on your own technical documentation
will not create enough traffic to show substantial analytics. You options are
to either publish something and get as many of your friends to visit the site,
or you can create analytics on different pages in existing popular site, and
show how they compare. Visiting your own site often yourself won't work, since
the analytics looks for unique IP addresses.
On to the subject for bleeding edge, technical writers
sometimes take jobs writing general interest articles and blogs on technical
subjects, like software, consumer electronics, medicine, and the like.
Sometimes its very technical. This is actually a rapidly growing area within
technical/specialized writing.
I previously wrote articles and blogs for an electronics
company. An accountant friend of mine recently asked me to write a blog for his
accounting firm's web site. He likes my writing better than his own. A resort
where I stayed asked me to write a review. None of these examples wanted to
monetize the content, but it's not far. Getting prestige for putting out a blog
is usually higher priority for them than the actual analytics, and they
probably wouldn't know what to do with those analytics.
The first issue with analytics is why you want it and
what you expect to get out of it.
Co-author of Publishing Fundamentals: Unstructured
FrameMaker 11. Trainer and Developer in Tech Comm and eLearning
Sorry Neil, I don't know anyone who has done this, but
I'd do it on spec for a client if they were interested!
Hagay, I respectfully disagree with your assessment of GA only in terms of monetizing content. While a monetary transaction is certainly *one* goal of GA, knowing more about your users and knowing what they do (and don't) respond to are never a bad idea. Improving customer service and decreasing employee time spent on problem solving affect the bottom line as much as a few more transactions.
And while a small company or resort may not have time to fully contemplate GA on their blog, or even their site, many companies have the scale to do so.
Even small orgs can use GA to determine their spend on marketing, content dev, and other significant activities.
I thought Evan's original premise was a good one, and would bet dollars to doughnuts that embedding the GA code would be do-able, and worthwhile for any org that currently does GA.
Hagay, I respectfully disagree with your assessment of GA only in terms of monetizing content. While a monetary transaction is certainly *one* goal of GA, knowing more about your users and knowing what they do (and don't) respond to are never a bad idea. Improving customer service and decreasing employee time spent on problem solving affect the bottom line as much as a few more transactions.
And while a small company or resort may not have time to fully contemplate GA on their blog, or even their site, many companies have the scale to do so.
Even small orgs can use GA to determine their spend on marketing, content dev, and other significant activities.
I thought Evan's original premise was a good one, and would bet dollars to doughnuts that embedding the GA code would be do-able, and worthwhile for any org that currently does GA.
President, Hyper/Word Services
Hagay,
Thanks for your post. I don't entirely agree with you regarding tech comm's use of GA since while tech comm (probably) isn't going to be monetizing contact, they still want to know who is using it and its successes and failures (which is basically your point about coordinating with customer service). That disagreement aside, I think your response would make a fine blog post that introduces one aspect of analytics. Do you have a blog on which you could put your post? If not, would you mind if I put it on my blog, with full attribution to you of course, as a discussion point for tech comm?
Regards,
Neil
Thanks for your post. I don't entirely agree with you regarding tech comm's use of GA since while tech comm (probably) isn't going to be monetizing contact, they still want to know who is using it and its successes and failures (which is basically your point about coordinating with customer service). That disagreement aside, I think your response would make a fine blog post that introduces one aspect of analytics. Do you have a blog on which you could put your post? If not, would you mind if I put it on my blog, with full attribution to you of course, as a discussion point for tech comm?
Regards,
Neil
President, Hyper/Word Services
Matt,
Thanks for your post in response to Hagay. I think you and I are seeing a different side of GA because we're in the same field, whereas I suspect Hagay is coming at it from a different angle. (Hagay, true?) Watch the April Intercom for an article about analytics for tech comm as part of a bleeding edge theme to the issue.
Regards,
Neil
Thanks for your post in response to Hagay. I think you and I are seeing a different side of GA because we're in the same field, whereas I suspect Hagay is coming at it from a different angle. (Hagay, true?) Watch the April Intercom for an article about analytics for tech comm as part of a bleeding edge theme to the issue.
Regards,
Neil
Technical and Marketing Communications Manager at High
Security Labs
Thanks to both of you, Neil and Matt.
Yes, I am coming from a different angle. I have worked
with Google Analytics in the past. It was of limited use as a tool for my
technical publications, but I more often documented its uses and features in
the line of business of the companies where I worked.
The reason GA is so new to technical writers is its limited perceived benefit
(I emphasize perceived). GA is not new. It is already very strong in other
areas that find its ability to generate revenue or save money. This is also
where technical communications can benefit, and benefit the companies who
employ the technical writers.
We are already aware how the old school format of
technical documentation, which uses the printed page paradigm, is gradually
shifting to mostly/only electronic publishing and distribution.
Companies that needed technical documents didn't always
see it in full context of its operations and line of business, and neither did
the technical writers. What was not so obvious was how technical communications
can benefit marketing, sales and support. The technical writers know little
about who reads their documentation, how much they actually read (if at all),
and especially what content they miss that eventually turns into an expensive
service call. This is where the savings comes in - a service call that could
have been resolved in advance with a visit to the WebHelp. GA can help locate
and link the support expenses to specific items of documented information. I
have used GA to a limited extent in my technical documentation, but the traffic
was not heavy enough to provide any useful insights.
The newer side is generating revenue through technical
communications. I know of companies who are considering monetizing their
technical documentation, but none who actually tried to sell it, let alone made
any money. This is especially common with companies who market a FREE-MIUM
product or service. The initial product is basic and free, but advanced
features are only available with a paid subscription or by purchasing the
"Pro" version. With this model, users of the basic free product get a
short Quick Start tutorial, in a web page, PDF download, Video, interactive
Flash, or some combination. The heavier side of technical communications is
only provided to paying customers, and is part of the full product support
package. Again, I have yet to see a company that succeeded selling its user
manuals, but then I am not in contact with every new company.
This is a new area, and certainly "Bleeding
Edge."
Co-author of Publishing Fundamentals: Unstructured
FrameMaker 11. Trainer and Developer in Tech Comm and eLearning
@Neil, feel free to use this as blog fodder!
I think it's an interesting topic, though as I said I've not implemented GA code in a project yet. If as Hagay said, the sample size is just too small, then perhaps in smaller implementations, it's just not worth it. But even for small samples, you'd get a sense of the number of users, and what they're doing.
I think it's an interesting topic, though as I said I've not implemented GA code in a project yet. If as Hagay said, the sample size is just too small, then perhaps in smaller implementations, it's just not worth it. But even for small samples, you'd get a sense of the number of users, and what they're doing.
at Capensys Ltd.
Coming in on this late...We use Google Analytics to
measure our RH projects for clients all the time. We embed the code into the
master, and publish as WebHelp We have a different account set up for each
client.
It does have limited use - it can't measure exactly who is reading the files, which is fine because it protects the privacy of the user (important in Europe, especially). But it tells the client which city/country the user is in, and whether it is a mobile device. If you dig down, you can see which pages are accessed the most, which is also useful. (While the overall project is addressed as index.htm, the individual pages are bookmarks, and can be found.)
Hope this helps,
Marion
It does have limited use - it can't measure exactly who is reading the files, which is fine because it protects the privacy of the user (important in Europe, especially). But it tells the client which city/country the user is in, and whether it is a mobile device. If you dig down, you can see which pages are accessed the most, which is also useful. (While the overall project is addressed as index.htm, the individual pages are bookmarks, and can be found.)
Hope this helps,
Marion
