Hurry up and Wait: Delayed Gratification for Autoresponders

FeedBlitz has offered comprehensive, multi-step autoresponders for years now. They’re great for saying thanks, delivering incentives, or offering multi-step courses. Couple an autoresponder sequence to other lists using FeedBlitz’s triggers, start a signup with a parser, and you’ve got a very capable automated email marketing solution.

A typical autoresponder sequence starts immediately. You sign up for a list, and your incentive is delivered right away. You make your purchase, et voila! A thank you missive is en route, toute suite. It’s what people expect to happen.

But what if you have a fixed sequence that you want to send, but instead of starting immediately, you want to delay until next Thursday, say, regardless of when the subscriber took the action that got them onto the autoresponder in the first place? Tough to do with an autoresponder series that always starts instantly, no matter what time of day (or night) the subscriber joins.

Enter a new feature here at FeedBlitz: The ability to delay an autoresponder’s start. If you go to your autoresponder’s dashboard, or enter its article sequence edit page, you will see that, by default, it is defined to begin immediately. Click the “immediately” link, and you can choose the day and time the autoresponder should actually start. Simple.

Want the best of both worlds, i.e. an immediate “thank you” and then a delay? Well, you can do that too. First, create both your autoresponders (the “ASAP” one and the delayed one). From the ASAP autoresponder’s dashboard, on the “Subscriber Management” tile, click “Triggers” and then add a “Completion” trigger to add the subscriber to the delayed sequence. ASAP does what it does right away, and then hands the subscriber off to wait for the start of the delayed sequence.

So long, Zombie Google Reader

We all know how to stop a zombie, right? Get it in the head. Fine in the movies or “The Walking Dead,” but it’s not so simple for zombie products or technologies.

Case in point: Google Reader. The product was “killed” by Google in the middle of 2013, and it was no longer available to end users. So it was dead and buried, right?

Wrong. It was a zombie. The back end of Google Reader kept on plugging away, checking feeds, dutifully reporting how many subscribers it was polling on behalf of. Like the Energizer bunny, It kept on going and going and going … until sometime on November 13th, 2014, when some plucky soul at Google finally whacked the Google Reader back end firmly enough in the head to stop it for good.

Yes, for nearly a year and a half, the back end of Google Reader apparently didn’t know that it was dead.

After its nominal demise, last year, we made a decision to continue to report Google Reader subscriber numbers while we still saw them. So if your RSS stats changed dramatically on November the 14th, the first full day without Zombie Google Reader (ZGR), that’s why.

It’s weird and odd that ZGR was left running for so long; makes me wonder what happened to make someone finally turn it off. Maybe that famous pink marketing bunny took its batteries back.

For the Fallen – We Will Remember Them

They shall grow not old, as we that are left grow old:
Age shall not weary them, nor the years condemn.
At the going down of the sun and in the morning
We will remember them.

From “For the Fallen” by Robert Laurence Binyon

For the benefit of my mostly US audience, in the UK and many other countries we buy paper poppies around the 11th to commemorate those who served and those who fell during the World Wars. The poppies specifically memorialize the killing fields in France and Belgium during WWI where the “lions led by donkeys” on both sides killed each other in unimaginable numbers. Day in, day out. Only the Spanish Flu of 1918 outkilled the machine guns, mustard gas and barbed wire.

Today, then, is a noteworthy day in Europe, where the slaughter of the horribly misnamed “Great War” mostly took place between 1914 and 1918. Today, entire countries largely fall silent at 11am on November 11th to remember the wars, their dead, the valor of those who served and the bravery those who still do. It’s a day of respect, retrospect and introspection.

In churches and schools, at services, memorials and cenotaphs in the cities, towns and villages, the stanza from Binyon’s poem, quoted above, is often spoken as part of memorial services and readings. The focus back in Britain is markedly different today – a day that’s somber, one of mourning not celebration – than Veteran’s Day is here in the US, my adopted home. It has always been this way: Armistice Day has never been a celebratory day off. It’s not a day to celebrate the military like it is here in the States (which is not to say it is necessarily better; it’s just a different perspective).

In that spirit then, no matter what your politics, no matter where you live today, no matter what else you are doing or celebrating this November 11th, I would ask only this: Please take a moment today to remember the Fallen and their sacrifices, no matter where they fell nor for what cause.

Let us make it so that, for today at least, we will remember them.

They shall grow not old, as we that are left grow old:
Age shall not weary them, nor the years condemn.
At the going down of the sun and in the morning
We will remember them.

Resolved: Overnight click-through issues

Although feeds were being served and email sent OK, some publishers experienced click-through issues overnight; the problem has now been resolved. We’re sorry for any inconvenience. Any subscribers seeing an error message now need to simply refresh the page.

Today, job 1 is to update our monitors to better detect this kind of issue, which unfortunately went undetected by our automated system health tracking.

The One Easy Gmail Tip for Tracking and Testing

We recently sponsored the slightly-awkwardly-named-but-totally-worthwhile Type-A Parent Conference in Atlanta, and so naturally the topic of email came up (surprise!), especially in relation to testing email forms with different email accounts. It can be a real pain to create yet another email address for your site, and so we all have only a few addresses to go around. Right?

Wrong! If you have a gmail account – and who doesn’t? – you effectively have an infinite number of email addresses. And I was surprised how few of the experienced bloggers and content marketers I met on this trip knew this great gmail tip. Hence, this post…

The trick’s really simple. Say your gmail account is All you have to do is add a plus sign after “yourname” and then any regular email friendly text (no spaces, commas, etc) before the @ sign, and voila! As far as any third party site is concerned, you just created a new, unique, custom email address. It will still be routed to your regular gmail inbox, where you can then build filters to send these inbound emails to different folders if you want to.

For example, is a perfectly valid email address that will reach my gmail inbox, but will by definition be spam (since it will only ever appear in this blog post) and so I can simply route it to junk.

Practically speaking, you can use <yourname>+<sitename> to uniquely track individual subscriptions, purchases, registrations from any web site. With this technique, you can see which sites are selling your email address, for example; or which perhaps have been compromised, because now you can use a unique email address for every site you interact  or register with.

Want to test your email subscription form or popup? <yourname>+<test1> (etc.) will do the job nicely.

With gmail you effectively have an infinite reservoir of unique email addresses you can do almost anything with. It’s pretty neat. Meanwhile, if you’ve some good email tips, we’d love to hear them in the comments.

Feeds, Clicks and DNS Problems

If you or your subscribers have been frustrated trying to get to a FeedBlitz feed (or click through to a link in a FeedBlitz feed) in the last 24 hours or so, the reason is because some third party DNS servers have been returning the wrong results for The net effect is that although FeedBlitz is up and your feeds are being served, some subscribers are being sent to the wrong servers, and getting errors as a result. Update: We’ve routed traffic from the “wrong” server to one of the “right” ones, so even folks affected by this should now get correct data

Here’s the explanation.

DNS, or the Domain Name System, is the thing that translates web host names, like, to machine IP addresses, such as, which allows the traffic to get between your computer and the correct server.

Yesterday morning, some DNS services, (notably Google’s public DNS server, which is used by many people, services and organizations), started to return not only inconsistent results, but demonstrably incorrect results.  In short, they redirected traffic to the wrong servers for much of the day.

Now here at FeedBlitz we have an enterprise DNS provider. Misrouting traffic is clearly a major issue and we woke people up yesterday morning to try to (a) correct the situation, and (b) determine what went wrong.  As far as we can tell, our authoritative DNS entries were all fine, but thanks to DNS caching and inconsistent results being returned for much of the day yesterday by Google’s servers, traffic for feeds for some people and services ended up in the wrong place, at a server not expecting nor designed to handle feeds traffic, returning errors.

Despite our best efforts, we couldn’t get Google to return consistent and correct DNS results globally until yesterday afternoon, US eastern. At that point, new DNS lookups for will have been successfully sent to the correct servers.

The problem is, however, that DNS lookups are cached – stored temporarily – by the machine making the DNS request. So while Google’s DNS finally got its act together yesterday afternoon, all the queries that were bungled before that were – and are – being cached by the machines that requested them. Those caches are held for a duration known as the TTL – time to live – time. That time may be many hours, and so requests being made to now may still being routed to the wrong server, because of incorrect data cached yesterday, if the machine in question, or its upstream DNS provider, got that incorrect data.

We know this is incredibly frustrating for everyone affected, but the cause appears to be downstream from our DNS provider. Our DNS records are correct. As far as we can tell, all major DNS providers are returning the correct results now too. That’s the good news.

While we’re trying to figure out what happened, unfortunately we can’t control downstream DNS caches and third party DNS providers. The ugly truth is, if you’re having problems, unless you’re running your own DNS architecture which you can refresh, all you can do is hang around for your DNS cache’s TTL to expire for the record; in other words, hurry up and wait. That stinks, I know.

Still, if you’re on windows, you can run this command from a command prompt to see if you’re affected:


As I write, you should get four IP addresses back.  If you do, all is well. If not, you have stale and incorrect DNS data. On windows, you can clear your local DNS caches with this command:

ipconfig /flushdns

If you now re-run the nslookup command from further up, you might get the correct results. If not, that means a DNS cache upstream from you is stale and has the incorrect data. At this point, unless you control that upstream DNS server and can fix it, you have to wait for that DNS cache to expire and the correct DNS data to be served.

We here have done all we can to diagnose and address this issue. Our DNS records are correct and are being correctly and consistently returned by downstream servers.

I understand and appreciate the frustration. I hope this helps explain what’s gone on and how little we can control it.



Today I Learned: How to Enable Flash Developers

Not having Flash development experience in-house, we were puzzled recently when we received a support request from a Flash guy wondering why a file we’d never heard of (crossdomain.xml) was giving a 404 file not found error when he requested it. Because it wasn’t there, obviously.

Thankfully, the developer in question was kind enough to throw us a link about why that file was needed for Flash, and a few minutes later we had everything we needed to know. Thanks, Chad!

So if you’re a Flash developer, crossdomain.xml is now available on our servers to permit you to use FeedBlitz-powered RSS feeds in flash apps hosted on your domain. Neat.

New: RSS Image Enclosures Now Visible

A funny (peculiar, not haha) thing about major media site RSS feeds is that not only are the feeds often little more than a plain text (and so kinda boring) sentence, but also that their RSS feeds tend to include thumbnail images as enclosures. Enclosures are the part of a feed typically used for podcast media files, and the problem with stashing an image as an enclosure is that most people won’t see it, since the picture isn’t part of the main content. As a result, the feed and downstream feed usage (e.g. email subscriptions) are much less engaging for us carbon based life forms, and so the feed produces less traffic back to the publisher’s site than it otherwise might.

We like engagement. You like engagement! Everyone likes more of the right kind of traffic.

So we have fixed this for FeedBlitz publishers.

From now on, if FeedBlitz finds an image enclosure in a feed and there are no other images in the main content, it will bring that image up into the main content (just above the social sharing icons) to make it visible to people. This will make the feed much more engaging, and encourage click throughs.  FeedBlitz will leave the enclosure as it found it, however, in case there are downstream apps that expect and need that image file to be in the feed as an enclosure element. Or, in other words, the change is backwards compatible with the way the feed XML was formatted before.

Too many words? Perhaps an example will help. Here’s a feed whose images are now visible to mere mortals because of this new capability:

The FeedBlitz API: Workflow for Building a Plugin

The goal of this example is to show you what API calls to make so you can programmatically add a subscriber’s email (and other information) to a list at FeedBlitz. Let’s assume you’re developing a plugin for WordPress; any WP plugin developer should be able to integrate with FeedBlitz! The example below isn’t limited to plugins, of course; it can work with any web site, product or service you can extend programmatically.  You use simple Web requests, so it’s pretty easy for a web developer to do.


The user of your plugin will need:


Once you’ve validated the pre-reqs, you:

  1. Get a list of the publisher’s active lists from the REST API.
  2. Optionally get a list of custom fields and tags the publisher already has in FeedBlitz.
  3. In your configuration UI, the publisher:
    1. Picks a list that your plugin will subscribe visitors to.
    2. Optionally selects the custom fields to use, or specifies new ones using your UI.

When a visitor uses your plugin to join a list, you then:

  1. Present your UI, performing any necessary validation;
  2. Call the FeedBlitz Simple API to create the subscription
  3. Assuming all is well, FeedBlitz starts the dual opt-in process to add the subscriber.

In Detail

All URLs below are simple HTTP GETs (see, I said it was easy!)

Get a List of Active Mailing Lists

Use a quick call to the REST API as follows<api_key>&summary=1

The returned XML will contain one or more <syndication> elements, one for each active list. Grab the <id> and <name> elements within each. You will need to persist the <id> that the user selects. Add “text/xml” to your Accept-Type header to make the REST API work.

Get Active Custom Fields

If the publisher has custom fields defined in their account, it would be nice to offer those on your UI, right? Right! Here’s the REST API call:<api_key>

The returned XML may contain or more <field> elements. Grab the <name> and the <id> and the <uihidden> elements. FeedBlitz allows publishers to create hidden custom fields; publishers can use hidden fields to track campaigns, referring pages, etc.  Hidden fields should not be displayed to end users (i.e. not shown to site visitors or potential subscribers); it’s obviously ok to show them to the publisher during set up. If there are no custom fields defined, you can also offer your own (e.g. “Name”); FeedBlitz will add them when you send the data to FeedBlitz at subscription time. Again, this a REST API call, so be sure to add “text/xml” to your Accept-Type header before accessing the resource.

Save the relevant information and use it to build the user interface you want to present to site visitors.

Subscribe a visitor

Configuration all done, potential subscribers will now be using your user interface on the publisher’s web site. Based on the saved configuration and user-supplied data, and making sure as best you can that the visiting user agent is not a bot (recommended to prevent spambots: use <script> to generate your UI on the fly, and make sure there’s a valid referrer header); call the simple subscription API as mentioned last week with the correct parameters:<api_key>&email=<email>&listid=<listid>

 Optionally add tags and name / value pairs, again as mentioned over here.


It’s that easy. Two calls to assist in configuration, and one per new subscriber. FeedBlitz handles the entire dual opt-in process from there on, as well as all subscriber management such as bounce handling, unsubscribes etc.

The FeedBlitz REST API

The REST API is an XML-based API. It is, like FeedBlitz itself, complex and at times may be challenging to use. For simple use cases, such as integrating a FeedBlitz subscription mechanism into your site or service, we recommend using one of the APIs I’ve already covered this week, or a plugin / widget that has already done the work for you.

If you’re building such a plugin, widget or tool, then depending on your use cases you may need to delve into the REST API in some depth.

Programming Required: Yes
API Key Needed: Yes
Best suited for: Web developer, plugin developer
Skill level: Intermediate to Advanced
Good for: Programmatic control over almost all FeedBlitz capabilities

The REST API has lots of features relating to detailed list settings, subscribers and more, so plugin developers can use it to discover a publisher’s lists and custom fields, for example. Although the REST API is rich and complex, these basic tasks are fairly easy to do, especially if you’re only reading data, since that requires nothing more than the ability to parse basic XML and send a simple HTTP GET request in your code.

The full API is documented in a PDF, available for download from