One of my Clients wan't to distribute there monthly print-magazine also as free PDF download. Similar to HackerMonthly. We are currently not using any CMS so we are open to every solution.

I could be done with Google Analytics if I specify a separate Goal for every file that will be available but I hope I do not have to go there.

Important statistic would be:

  • # of Downloads per File
  • Geographic region of the downloader

moderator: add tag "file-distribution" if you consider it appropriated

  • Google analytics can solve all of the above pretty easily. If for example you are serving up a file by using link.php?id=<id for file> or something of that nature you could add analytics to link.php file and sure enough you will get statistics on all files you serve up from that link.php file.
    – Chris
    Aug 31, 2010 at 19:35

3 Answers 3


You could keep track of number of downloads per file simply by feeding the file through a server side script in the language of your choosing as opposed to linking directly to the file. By doing it this way every time the file is requested you can log it, and information about who is downloading it, in a database. See this answer for an example of this in PHP.

To learn the geographic location you will need to use a GeoIPService to translate their IP into a Geolocation. Then simply save that information with your download information.


I took this on with a past employer. After much discussion, we opted AGAINST .pdf as the sole electronic distribution method due to the extra load time, annoying software, and (somewhat) questionable visibility with the search engines...I know, I know, Google does search .pdfs....but it seems to grab traditional HTML sites BETTER.

So, our solution was to deliver the site in newspaper format via a custom CMS that we wrote in-house. We could then use Google Analytics to track inbound, outbound AND search related traffic plus paths through the site. A big part of the traffic we received was referrals from current readers, and there was no way to track who's passing around a .pdf via email forward. It's easy, however, to track a "send to a friend" link on a site...which is why you see it on CNN, MSNBC, etc.

An added bonus is that by doing it the way we did, we could use queries (or RSS, which we also offered) to cross-post the content back on the main site and the 25 other sites that the company ran. So, a particular letter from a high-ranking CEO could be used to populate multiple newsletters and websites with just a few clicks.

Later, to appease the print-obsessed crowd, we did begin offering a .pdf download, generated on the fly server-side. Sure, it wasn't a perfect, custom laid out graphic marvel...but it worked, was automatic, and people liked it. Load time for the .pdf was ~20-30 seconds if your .pdf viewer wasn't open. Load time on the non-pdf site was about 1sec by comparison.

Administration-wise, we went from hours per newsletter down to less than an hour. An accompanying email system was setup to auto-generate a email blast with the month's articles, with just a handful of clicks. The email blast immediately ratcheted up viewership and doubled return visitors.

  • thanks for the shared experience, I will run it by my client Sep 1, 2010 at 8:48
  • I would like to see more on the implementation side of this and how you were able to cross publish. Sounds very interested.
    – Chris
    Sep 1, 2010 at 12:07
  • @chris, it was actually a pretty low-tech approach. Because we controlled all the servers, I was just able to grant access between DB's and build a class that would allow me to query content between sites. Had I not had access, I probably would have just extended a simple webservice to pass data. Really, the more technically challenging assignment was building the bulk email generator so that it output a good-looking, 100% correct template that could be "slurped" by the bulk email tool (a heavily modified version of interspire email marketer) Sep 1, 2010 at 14:17

We had a similar problem (although we are not interested in geographic data).

What we wound up doing was writing a proxy for the documents. I.e. when you request http://example.com/articles/document.pdf this is actually a servlet that resolves the document name to an actual PDF, fetches the actual document and returns it to the user.

The advantage of this is that we can, at this point, log that the file was requested, who requested it and (very important for us) if they should be allowed to have it.

With this set up there is no way to access the actual PDF without going through this service, meaning that we can accurately record each request. It is however resource heavy as the PDF is read/written for each request.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.