I will henceforth refer to my hand as a "Galaxy Shield"
Let us know if you have any interesting and attainable new year’s resolutions here.
Even if you’ve never heard of retargeting when it comes to online ads, it’s likely that you’ve still experienced it. Here’s how it works.
A person visits your site. They browse around and check out some of your products. Your site drops a little cookie in their browser that tells other sites they’ve been to your site.
Now they visit another site—one that has ads on their site. And these ads are delivered by a retargeting service. Including an ad for your site.
So now that visitor is on another site, but since they’ve been to your site before, they see an ad for your site—reminding them that they had previously checked you out and subtly (or not so) suggesting that you head back there.
It seems almost like magic the first time you notice it. Especially if you visited a site you normally don’t. I visited a site for my wife—to help her look up something sewing related. Later, every site I went to offered me sewing patterns and more. Strange.
But it’s been demonstrated to be somewhat effective. So you might think this is the smart way to do ads. After all, the normal banners don’t seem to really work too well, right?
As I thought about how I would want to do ads, and where I would want to do them, I decided I wanted to do something like Brian Krogsgard does on Post Status. One single ad. Not a ton of them.
But I didn’t want a static one. And I didn’t want a random one.
Yes, I’m picky that way.
What I really wanted was a targeted ad based on behavior. You know, based on what someone had done on my site—the pages and posts they’d visited and read.
Here’s what I imagined.
A user navigates my site and visits and reads certain posts. I track that behavior. And when they hit a certain set of posts (all of a similar topic—like membership plugins for WordPress), I wanted to tag the anonymous visitor as someone interested in membership sites.
Then, whenever they came back, I’d want to show them a single ad for a membership plugin that I liked. But only to them. Everyone else would see my site without an ad.
I thought of it as a targeted ad. And to do it, I would need to be able to design the rules of what posts needed to be viewed before tagging the visitor. And then I’d need a conditional display in my widgets to show the ad only to tagged visitors.
With the specific ideas in place, I called a friend—Erik over at ORBTR—and we spent some time talking about it. (If you’ve never heard of ORBTR, you may want to check it out; they’re truly amazing.)
Erik and I talked about it at length, and over a set of releases, he put it all in place. First he created orbits (groups that could be populated by rules related to page visits and more). Then he created a conditional widget that would be driven by whether a person was in an orbit or not.
I sponsored some of this development because I believed it would be something others would use. And I hoped it would work. And then we set it up on my site.
Whenever you do something like this, you can only tell how well it’s worked by comparing it to a baseline of data. That’s what I’d collected for several months.
On average, I was sending 30 folks a day to a membership plugin’s site. This had been constant for months.
Then I created the orbit and the conditional widget with an ad for the membership plugin—only to be seen by specific people who had visited specific posts (within a specific period of time).
And the results were fantastic. Over the quarter that I ran the ad, I saw an increase of 120%. Daily.
I would have been fine if the experiment hadn’t worked, or if the sponsored development hadn’t paid off. I love products and product development, and it was worth it just for that reason alone.
But it did work out. And I’m thrilled to be able to tell you that you now have an alternative option beyond retargeting which lets you do smarter ads on your own site, rather than paying to have your site’s ads plastered all over everyone else’s sites.
Anybody else experimenting with targeted ads? What works for you?
WP Remote provides a great resource for those who have multiple WordPress sites to maintain. Created in 2010, this evolving web app allows users to monitor and update all of their WordPress sites in one place, saving time and effort for those who manage sites for clients.
Since announcing “The New WP Remote” on October 4—which marked the launch of their new premium features, a redesign, and the public release of their powerful API—the folks behind the scenes at WP Remote have been working hard to deliver even more improvements to the interface, all rolled out in the past week.
I had the chance to chat with the lead engineer on the recent release (and all of the updates since), Daniel Bachhuber, who took me through the latest changes. Among these are more durable backups for larger sites, integration with premium plugins and themes, and new API endpoints.
Also, along with being able to view the history across all of your sites at once (which is super helpful), users now have the ability—as of yesterday—to download this data as a CSV file. If you manage a bunch of sites, this could really come in handy for organization, documentation and client communications.
Some hosts kill PHP processes after 90 seconds, which was creating issues, so WP Remote built an implementation of their backup system that gets around that. What it does, basically, is divide the backup into many small parts and then performs the process one by one. And if the process ever gets killed, there is a restart mechanism.
WP Remote now integrates smoothly with Gravity Forms, BackupBuddy,Pagelines, and a few others. They are currently working on Easy Digital Downloads Add-Ons and Advanced Custom Fields Add-Ons.
Any plugin or theme that implements the ManageWP update mechanism, or hooks into what WordPress core does for updates, will work seamlessly with WP Remote. Also, users are encouraged to email WP Remote at to request testing of a premium plugin or theme integration.
WP Remote is one of the few complex applications build exclusively on WordPress. Since its inception, it has been known as the interface that you come to in order to perform management actions. But what the WP Remote team at Human Made has really spent the majority of their time and efforts on is making their API more robust.
The application is built entirely on top of an API. This means that there is a corresponding API endpoint for any action that you perform within the application, that you can then build on top of on your own.
Daniel envisions that “the future of WP Remote is this API that gives you the opportunity to do lots of things.” He explained that users can “build different user experiences based on top of our API” and/or “take our API and run with it, using it for what they want.”
This past week Daniel and WP Remote pushed out some additional API endpoints that are content management endpoints, offering the ability for users to manage their posts, comments, and users.
One such use case for the API is a command for WP-CLI. WP-CLI is a command-line interface for WordPress. The WP Remote WP-CLI command enables you to run many WP-CLI commands against a remote site. Say, for instance, you have a site with a web host that doesn’t permit SSH access, and you subsequently install WP-CLI. With the WP Remote WP-CLI command, you can work around this restriction and perform many WP-CLI commands against a remote site from your local machine.
Part of why WP Remote is useful is that it provides a history of all the actions you’ve performed across all of your sites, called a “global view.” What’s more, as I mentioned earlier, you can now download this information as a CSV file, which is easily sharable with clients.
Along with all of these changes, inevitably, comes new price points:
• 1 Site for $5/month
• 25 Sites for $79/month
But if any of you are interested in trying out the app, just enter the code “torquemag” for 1 month free.
Anybody use WP Remote to monitor and update your sites? Tell us your thoughts in the comments below!