Most enterprise software companies publish assets such as ebooks and whitepapers exclusively as PDFs. I’m not sure why. Publishing this way has at least a few problems:

1. Analytics. When someone reads your content in PDF, you lose the ability to capture time on page and bounce rate, and also you can’t use heatmapping and scrollmapping tools to tell what parts of your content visitors are spending their time on. It’s true that this data is ambiguous (are they spending time on this section because it’s interesting or because it’s difficult to understand?) but I’d rather have it than not. Also, heatmapping tables of contents in particular can be a good guide as to what content people are interested in.

2. Workflow. We’re still experimenting with InCopy and other solutions, but generally PDFs are much harder for content creators to update than HTML files. That means that graphic designers or other format experts have to get involved – which quickly becomes frustrating during the final rounds of small edits. Tracking revisions for HTML files is also much easier than tracking revisions for PDFs.

3. Search. I will admit that I’m not basing this on anything, but it seems like PDFs are less powerful for SEO than HTML pages. It certainly makes it harder to get new organic traffic to take further actions on your site based on what they’ve found.

4. Conversions. Of course, in many cases an asset download is itself the conversion. But it’d be nice to have the flexibility to send visitors elsewhere for more information or for further actions.

5. Interactivity. There are lots of other cases where it’d be nice to add interactions, embed video, etc. I, at least, have never done this in PDF and wouldn’t know where to start; but I and lots of other people do this every day in web pages.

HTML solves all these problems. It also lacks the following advantages of PDFs:

1. The paper document experience. This is the primary advantage, I think, of continuing to publish in PDF – it mimics the experience of looking at your own pace through complex marketing or informational material. Images, text, and other components are part of a single, unified file that can be emailed by a salesperson, sent to an e-reader, opened on the subway, etc. You don’t have to worry about internet connectivity or other loading issues making it impossible to get the information you need.

2. Printing. Usually, you’ll want to have printed copies of an asset that can be handed out at events. It’s hard to get something truly high-quality by converting from HTML to PDF. Also, HTML colors are specified in RGB, whereas for printable assets you’ll usually want to specify colors in CMYK or some other system suitable for printing.

3. Compatibility. Using PDF ensures that a document will look exactly the same no matter which platform you’re viewing it on. But I’ve noticed that I’m spending less and less of my time troubleshooting cross-browser issues these days, and for most marketing content, is pixel-perfection really necessary?

I think the best way to publish major marketing assets is probably in HTML by default, with a link to a downloadable PDF version.

Optionally, you might set up a landing page with an HTML short summary or selected pieces, and then have a call to action to click through to the full content from there. This would be a good idea for content that is behind a registration wall – but it also might be smart for content that is very long and would benefit from an abstract or overview page. (A registration page follows this landing page if appropriate.)

Eventually, if there is some agreed-upon way to add CMYK or other printer-friendly color metadata to HTML, something like jsPDF or another HTML to PDF converter would be the ideal solution. All the advantages of both format types without extra work to convert HTML to PDF.