Updates to pageview measuring
Typekit’s plans are structured, in part, around an allotment of monthly pageviews, which are counted in aggregate across all of the kits in your account. Until now, the system we’ve used to track pageviews on users’ sites has not accounted for browser caching. This means that we have undercounted the number of pageviews on all users’ sites. We are now making a shift to incorporate pageviews into the way we pay our foundry partners. As a result, starting today, we’re moving to a system which will help ensure more accurate pageview measurement, whether a kit remains cached or not.
This new system uses a one pixel transparent image to record every pageview; the image is loaded asynchronously and will not block page loading. This is a common pattern used by many web services, and one which we have already put to use on our CDN-integrated Enterprise plans. We are confident you won’t see any meaningful difference in the appearance or loading of your sites as a result of this change.
You may, however, notice the pageview chart on your account increase over the next few weeks. If you were close to your plan’s pageview limit before, you may find that this update puts you over that limit. That said, we will not automatically shut off any account that goes over the limit solely as a result of this change; rather, any Typekit user with an account created today or earlier will be given a three-month grace period on their pageview limits. If this update puts you over the limit of your current plan, that means you have time before you will be asked to upgrade to a higher plan.
The data that we collect from this pageview measurement will be used in two ways: to monitor whether accounts are within their plan limits and, most importantly, to compensate our foundry partners for the use of their fonts on users’ sites. Our goal has always been to provide an excellent service while also supporting the hard work that foundries and type designers do to bring their type to the web; more accurate measurement allows us to do all of these things better.
As always, if you have any questions about this, reach out to support@typekit.com and we will get back to you right away.
10 Responses
Comments are closed.
This sounds like a price increase justified by some gobbledygook about “undercounting”. You mean Typekit’s been cheating itself and now it’s customers have to pay more?
The goal here is not to increase prices (which would have been much easier to do); the goal is to fairly compensate our foundry partners for the use of their fonts. I believe our policies have always been transparent and fair, and this change continues to reflect that.
(this is a reply to Mandy Brown, because that button is unavailable)
you don’t need to do that. ratio of pageview counts between different fonts will most certainly stay the same (statistics ftw) no matter if you count caching or not, because it’s equally distributed among websites/browsers/users/fonts.
that’s a bit dishonest imo. the only effect this will accomplish is higher prices for your users, and you know that..
Tom: The ratio of total pageviews to non-cached requests (i.e. the cache hit ratio) will most certainly not stay the same from site to site, user to user, or even font to font. The measurement depends on what kind of site the fonts are on, how it’s structured, user behavior, and which fonts are popular for which types of sites. Imagine a site where you click through many pages in under five minutes vs. a site with a single page that you visit once a week and then leave. The only way for us to be accurate is to measure the actual metric in question.
These are good news to me.
Will font foundries that license webfonts to be hosted on Typekit be able to view now montly page views per website using their typefaces? Would be a huge help!
A
Yes, the foundry stats page will start to reflect this new measurement over the course of the next few weeks. Stay tuned!
I thought the point of charging per-pageview (more precisely, to have plans that break into groups by number of pageviews) was to ensure that you are fairly compensated for the bandwidth required to serve kits? If kits are cached client-side, then you’re not using any more bandwidth.
I’m not sure what relationship exists, if any, between how many pageviews a webfont gets and how much its owner should get paid. I don’t believe it’s common for traditional typeface purchase licenses to restrict, for example, the circulation of the magazine in which it will be printed. Am I mistaken about that? Why adopt this model for webfonts?
The price for a web font does not only cover the bandwidth and other technology costs; it also compensates the foundries and type designers who work hard to bring these fonts to the screen. We have always maintained that pricing for fonts should be connected to use: a large commercial site with lots of traffic should pay more for the same font than a small blog with only a few visitors a day. That has been — and continues to be — one of the reasons for our tiered pricing.
This change only affects the mechanism for that measurement, not the underlying rationale.
You can’t fix proper caching for your kits (been years now, it’s not really that hard), but you have no problem adding yet another delay with additional http requests? Since typekit has to block to prevent flickering the gif file will of course affect latency. Even the GA tracking widget can cause a 50% increase in DOMReady.
There are a few separate issues in here that I’ll address individually.
First, you mention caching. Currently, we have to balance between kit updating speed (how long before published changes to show up) and longer cache times. This work moves us closer to being able to use much longer cache times for our fonts and improve caching in other ways. Stay tuned.
Second, you mention a delay caused by additional HTTP requests. The image loading is kicked off by the JavaScript, but it happens asynchronously. It shouldn’t significantly increase the time it takes the JS to execute, and the image request itself shouldn’t affect when the DOMReady event fires. DOMReady fires once the page is parsed and all non-async scripts are executed. The image request happens asynchronously and in parallel with requests for other assets on the page.