Carriers are Making More From Mobile Ads than Publishers Are
Consumers pay 16.6x more in data costs than top 50 news sites are making in ad revenue
The New York Times published an excellent piece called “The Cost of Mobile Ads on 50 News Websites” that explains how iOS 9 content blockers significantly reduce the size of news website page loads across the top sites they looked at, since “more than half of all data came from ads and other content filtered by ad blockers”. An example image from their report:
I did some quick calculations to figure out:
- What is the required data use for content+ads from these sites costing a typical US user (who pays for a data plan from a major mobile phone carrier), and,
- How much ad revenue is that news website making on the average user?
Data costs: The average smartphone user in the US is currently using 1.8Gb a month of data (Mobidia), so I assumed they needed to at least cover that with a 2Gb plan (nobody I’m aware of gets money back for unused data today). This means a $50 cost from Verizon or Sprint for 2Gb, or $60/$65 for T-Mobile or AT&T’s 3Gb plans, according to Consumer Reports. That’s an average of $22.92/Gb or $0.0224 per megabyte (The NY Times incremental data cost estimate in their article was lower).
Page weights: I rely on the New York Times data, aggregating the number of megabytes for ads and editorial for the 50 news websites from this chart (‘data usage’), and then dividing that amount by the average number of minutes a visiting mobile user spends per month on each of those sites, which data is sourced by the Times, from a Pew aggregation of comScore data. This hence essentially assumes that the user only loads a single page and spends between 1.4 (EliteDaily.com) and 3.5 minutes (BleacherReport.com) reading it. (Note that the New York Times article says its tests only visited the homepage — in my experience and testing, article pages often have heavier ad loads than the homepage, so their methodology and hence my approach as well, are probably quite conservative). I then get a “megabytes per minute” value for each of the 50 properties.
Mobile ad revenue: The IAB estimates for 2014 (figures from August 2015 release) that US mobile ad revenue was $14.32 billion. This includes display across apps and mobile browsers, search and messaging ads — I hence think it is over-inclusive and so again, conservative for the purposes of this analysis. I reduce this number to a per-minute basis by using Nielsen’s Total Audience Report from Q2, 2015 which shows that in 2015, US mobile smartphone users 18+ are spending 90 minutes per day in apps and on the web using their devices (up from 85 minutes in 2014). I would like to do a more in-depth analysis to tease out subcategories of time spent, but given that this would also include browsing time on apps like Facebook and Twitter, this again seems like a fair simplifying assumption.
Then look at US smartphone users’ time: Nielsen’s 175 million and change US smartphone users give us a total of 15.8 billion daily app/web minutes, which multiplied by 365 and divided into $14.318 billion dollars of revenue give us: Mobile ad revenue of $0.15 per US (18+) smartphone app/web user hour.
Finally, put it all together…
For each site, take Mb/minute x Avg per/Mb mobile data cost, and weight the average by each site’s monthly unique mobile visitors (so heavier data-using sites get more weight in our calculation) and normalize to one minute of time on each site, for a value ranging from $0.01 to $0.24 per minute. Compare that figure to our average revenue of $0.15/hour = $0.0025/minute and weight the average to get the result:
16.6x more in data costs to the user than mobile ad revenue to these top 50 news sites on average
Footnote:
Web-wide, page size has grown tremendously the last few years according to data from HTTP Archive, more than doubling in 3 years:
The most recent data shows that in September 2015 this has increased to 2,182Kb across all sites they analyze. Of this 354Kb was JavaScript, 1383Kb images, only 63Kb is Flash (down significantly clearly), 71Kb in CSS, 111Kb in fonts(!), and only 56Kb in actual HTML, served from 18 domains on average.
