Archive for category Administrivia
While you won’t get my patter, you should get the general idea: for reasons unknown to me, I’m the go-to guy for water heater repairs.
So much for my solid modeling and 3D printing and suchlike.
Two readers recently complained of auto-playing, non-mute-able video advertisements on these pages. As I mention over in the right column, down near the bottom, WordPress controls the number of ads, their placement, and (somewhat) their content. They call it the “WordAds” program, which is distinct from Google’s “Adwords” program, and I have opted into the WordAds program to get a cut of the revenue.
Here’s what my advertising revenue amounted to over the last six years:
|Period||Earnings||Ad Impr||$ / 1k|
[Edit: Update headings, get decimals right.]
To save you the trouble, the second column adds up to $2200: I’ve been raking in $1/day.
In recent years and very round numbers, this blog gets 650 visitors and 1000 page views per day, for about 1.6 page views/visitor and 30 k views/month.
You can clearly see the collapse of online advertising starting in early 2016, where the revenue fell off a cliff.
Until the last few months, the eyeballometric average of 15 k “ad impressions” / month amounts to either half an ad per page view or half of the visitors running ad blockers. I strongly doubt the latter, so maybe WordPress showed ads only on the first page view. The month-to-month variations suggest WP tinkered with the ad quantities and placement; I have no visibility into nor control over any of those machinations.
Early last year, WP apparently began pushing video ads, because the revenue per ad doubled, tripled, then jumped to nearly 30¢/impression, all from the same number of impressions.
September seems to be when WP went from one ad per view to three, with at least one of them being an aggressive video ad. The per-ad revenue dropped by a factor of two, though, suggesting the additional (non-video?) ads have no value, video ads aren’t as hot as they used to be, or creative rearrangement of WP’s (unknown) revenue sharing ratio.
So I had a brief exchange with the WP Happiness Engineers on the subject (edited for conciseness, with additional commentary):
> Can you provide a little more detail, please?
In recent weeks, two readers have posted disturbing comments:
Is there a secret to avoiding the auto-play video ad that ignores the “mute button” and refuses to let you scroll away?
I really enjoy your blog posts … but the hijacking by the video causes me to not view as often as I used to …
They obviously didn’t (and surely can’t) give me the URLs for those video ads, but they’re obviously not isolated events.
My rule of thumb says one person reporting a problem means ten had a similar problem and another hundred just walked away.
1) I can pay WP to suppress all the ads. That feels a lot like blackmail from this side of the exchange, particularly with aggressive video ads.
2) I can turn off WordAds and forego the ad revenue. That neither reduces the ad load nor improves their quality. It seems to only give WP even more incentive to monetize my IP.
I’ve suggested to all my readers that they should be running an ad blocker, because the next step after WP presenting crappy video ads from sketchy ad brokers will be shoveling malware from outright thugs. If malware can happen to ads from, say, the NY Times, it can definitely happen with WP.
Kill the scummy ads!
This would be nice:
I’ve asked our team if we can disable the video ads on your site. I’ll get back to you as soon as I hear from them.
Apparently they can’t kill all the video ads.
I find it frustrating when successive help-desk contestants don’t read the actual trouble reports and ask for information I obviously can’t provide:
I wanted to get a bit of clarification from you on the ads which are causing trouble on your site so we can pinpoint them and help to remove them.
There are two different types of video ads, can you let me know which of these two you are referring to?
Standalone video ads in a big placement below posts.
In-banner video. This is your standard banner ad placement and type except that there’s some video auction in the banner.
Having already told them everything I know, there’s little more I can add:
Two readers took the time to comment about them and I must assume the ads have pissed off many more people, but I have no further information on the ads.
Frankly, if you can’t identify the ads from this description:
1) “the auto-play video ad that ignores the “mute button” and refuses to let you scroll away”
2) “hijacking by the video”
Then WP definitely has lost control over the WordAds program.
Ads like that cheapen the WP brand. Why would WP want their blogging platform associated with aggressive crap?
It seems WP has definitely lost control:
We certainly don’t want ads that hijack the browser to show up in our network, any more than you do.
Unfortunately, bad-acting advertisers manage to submit ads to our network that violate our policy on this. We do our best to block them, but no filter we can put in place is fool-proof, and they submit new ads as quickly as we can block them.
This is a problem that advertising networks are facing industry-wide, not just on WordPress.com.
There are tens of thousands of ads in our network at any given time, so in order to identify which advertiser is placing the ads, we need more information to look them up in our logs:
Your device’s browser and operating system.
Your IP address (you can go to whatismyip.com to find this)
The exact URL of the page/blog post where the ad was shown.
The URL of the page that the ad takes you to.
If possible, a screenshot of the ad that hijacked the browser.
If you’re getting reports from site visitors, they can also send us that information by filling out this form:
But I’ll say it again anyway:
> they can also send us that information
That’s expecting entirely too much effort from people, so it’ll never happen.
I’m mildly surprised anybody bothered posting a comment, but I suspect it’s because they think I’m responsible for the crappy ads.
Of course, I can pay WP to not run ads.
> a problem that advertising networks are facing industry-wide
Which is precisely why I recommend using an ad blocker.
Basically, WP has outsourced both of our reputations to untrustworthy companies. We then say we have no responsibility for any problems, because those thugs over there did it, not us.
I understand why it happens and share some of the blame: I’m using a “free” blogging service and expecting it should Just Work.
Question: would paying WP to “Remove WordPress.com Ads” eliminate all ads from my blog?
The wording of “Allow your visitors to visit and read your website without seeing any WordPress.com advertising” suggests WP can show ads from other sources, so I’d like to be sure.
Which turns out to be the case:
To clarify, that means that the advertisements that WordPress.com places on your site (including ads from other sources) will be hidden if you upgrade to a Personal, Premium, or Business plan.
Spinning up a VM somewhere, setting up a WordPress instance, adding a comment spam suppression system, keeping everything updated with the latest patches, repairing the inevitable breakage, and maintaining the infrastructure isn’t anything I want to do. Basically, all I want is a place for my shop notes and doodles, not an unpaid sysadmin job.
The least awful alternative seems to be paying WP a few bucks a month to suppress all the ads, have them (continue to) do all the maintenance, and eat the costs.
From what I read, Patreon (et. al.) funding programs don’t actually produce any revenue, so the subscription model won’t be worth the effort.
Page views for 2017:
Plumbing and car troubles continue to plague folks in Search Engine City.
If I could monetize my broom handle thread IP, I’d be rich, I tell you, rich.
Some interesting (and rounded) numbers from the ads you (presumably) don’t see, because adblocking.
The blog gets just under 30 k page views/month, call it 1 k/day. Because most of the traffic arrives from search engines, each viewer looks at only 1.6 pages. Dividing the two suggests 18 k viewers/month.
WordPress now shows 90 k ad impressions/month. Dividing 90 k impressions by 18 k viewers gives 5 ad impressions/viewer, which is about what you’d expect from the three ads appearing on the main page and each post seen individually: 3 ads/page × 1.6 page views/visitor = 4.8 ads/visitor.
Before the big WP advertising push, they reported 15 k ad impressions/month for roughly the same 30 k page views/month and 1.6 pages/visitor. At one ad per page (which I don’t know for sure, but it seems reasonable), 30 k views should produce 30 k ad impressions. I can’t account for the discrepancy.
Those of you using ad blockers (which I highly recommend!) don’t know what you’re missing.
Onward, into the New Year …
For reasons not relevant here, I was called upon to open a bulletin-board lock with a complete lack of keys:
It’s obviously not the highest security lock you’ve ever seen. Armed with a small screwdriver and an old darning needle, this took the better part of 30 seconds:
Actually, I devoted a few minutes to verify none of my collection of random keys would suffice.
Replacing the lock not being within my remit, I improvised a simple retainer from available materials:
Yes, the nylon cable tie will surely pull out of the latch:
And I admit the installation’s security has taken a definite downward step:
Some day, I’ll tote a wrench to the site, remove the lock, and improve the improvisation.
Replacing the lock seems mired in an intractable budgetary wrangle. Similar locks being five bucks on Amazon, I’m tempted to just make it happen, but doing so would apparently roil the decision-making stratum. I’m perfectly happy to remain an on-call techie devoid of political ambition.
The recipe for incrementally copying media files since the previous blog backup works like this:
grep attachment_url *xml > attach.txt sed 's/^.*http/http/' attach.txt | sed 's/<\/wp.*//' > download.txt wget -nc -w 2 --no-verbose --random-wait --force-directories --directory-prefix=Media/ -i download.txt
-nc sets the “no clobber” option, which (paradoxically) simply avoids downloading a duplicate of an existing file. Otherwise, it’d download the file and glue on a
*.1 suffix, which isn’t a desirable outcome. The myriad (thus far, 0.6 myriad) already-copied files generate a massive stream of messages along the lines of
File ‘mumble’ already there; not retrieving.
--no-verbose will cut the clutter and emit some comfort messages.
There seems no way to recursively fetch only newer media files directly from the WordPress file URL with
-r -N; the site redirects the
http:// requests to the base URL, which doesn’t know about bare media files and coughs up a “not found” error.
Page views for 2016:
That works out to a bit under 1000 page views/day of purely organic traffic.
As always, way more people than I’d expect come here with plumbing problems. On the upside, much of the bedbug saga has fallen off the trailing edge of the wedge; life is good!
Recent news about Dropbox removing its Public folder feature reminded me to do my every-other-month blog backup. Wordpress provides a method to “export” the blog’s text and metadata in their XML-ish format, so you can (presumably) import your blog into another WordPress instance on the server of your choice. However, the XML file (actually, ten of ’em, all tucked into a paltry 8 MB ZIP file) does not include the media files referenced in the posts, which makes sense.
Now, being that type of guy, I have the original media files (mostly pictures) tucked away in a wide variety of directories on the file server. The problem is that there’s no easy way to match the original file to the WordPress instance; I do not want to produce a table by hand.
Fortunately, the entry for each blog post labels the URL of each media file with a distinct XML tag:
Note the two leading tabs: it’s prettyprinted XML. (Also, should you see escaped characters instead of
>, then WordPress has chewed on the source code again.)
While I could gimmick up a script (likely in Python) to process those files, this is simple enough to succumb to a Bash-style BFH:
grep attachment_url *xml > attach.txt sed 's/^.*http/http/' attach.txt | sed 's/<\/wp.*//' > download.txt wget --no-verbose --wait=5 --random-wait --force-directories --directory-prefix=/where/I/put/WordPress/Backups/Media/ -i download.txt
That fetches 6747 media files = 1.3 GB, tucks them into directories corresponding to their WordPress layout, and maintains their original file dates. I rate-limited the download to an average of 5 s/file in the hope of not being banned as a pest, so the whole backup takes the better part of ten hours.
So I wind up blowing an extra gig of disk space on a neatly arranged set of media files that can (presumably) be readily restored to another WordPress instance, should the occasion arise.
Memo to Self: investigate applying the
-r option to the base URL, with the
-N option to make it incremental, for future updates.