Here’s a little background information before I start my rant.
A large number of my clients make use of some sort of one-way e-mail communication with their clients. Some call it an e’zine, some call it a newsletter. These e-mails typically go out to a large number of people - anywhere from 500 up to 2500. Visually, they look like a mini-version of the websites - same color schemes, branding, etc.
Pumping out 2500 e-mails isn’t something that I care to do on my own. I’ve tried to build a system in the past, but it’s a pain in the ass. Why re-invent the wheel? There are several ASPs (Application Service Providers) out there that offer the functionality I’m looking for: the ability to have web site visitors subscribe to a mailing list, to have an administrator compose and send e-mails, to provide some sort of mechanism to track and report on the campaign, and to allow subscribers to remove themselves from the list.
We’ve gone through a trial-and-error process with a few different services, but settled on Roving about a year ago. It’s easy to use, has all the features we need, and pricing is based on subscription levels - the more addresses you have on your list, the more you pay.
From a high-level perspective, you’re simply designing a web page that will be viewed from within an e-mail program. When you start digging into it, though, you find out that there are some very subtle, but important differences. One of the biggest has to be the platform. When you’re building a site, you pretty much have to account for 3 or 4 primary browser platforms. Do you have any idea how many e-mail programs are out there? Not to mention all the people who read their e-mail via a web-based service, ala Hotmail or Yahoo! mail. It’s a nightmare. There’s a great article over at A List Apart that details some of the pitfalls and potential solutions when trying to develop these e-mails.
So, the trial-and-error process extended to the design and production phase, too. Over the last year, we’ve become pretty efficient in creating and sending these newsletters. And the results for our clients have been great.
This week, it all changed. So to speak. Roving’s service - “Constant Contact” - was upgraded to a new version. Their marketing campaign surrounding the changes highlighted that it was now “XHTML Compliant“. Which, I thought, was admirable - but probably premature. The web is just starting to go through a “standardization” process. Web browsers are adhering more closely to the specifications of the WC3, and designers/developers are jumping onboard the XHTML bandwagon (that’s a good thing). I thought it was odd that a company would trumpet the fact that their e-mails were going to be compliant.
After reading through the 51 page user-guide, I discovered a few things. First of all, there are now two methods available to created and edit campaigns. The “classic” version (that seemed to be based on Cold Fusion ( all variables were surrounded by “#”’s), or the “new” version - all variables are converted to XML tags. That didn’t sound too bad.
One of the reasons we use this service is the ability to track clickthroughs. When a reader clicks a links from within the e-mail, they’re sent to a page that records the click, then quickly sends them to the requested page. As administrators, we get very nice report that outlines that activity - which links were clicked, how many times, last click, etc.
In order to insititute that functionality in the old system, we used to wrap the URL in a function:
Now the method used to track click-throughs had changed. It isn’t very well documented, but it goes something like this:
That’s just one of my beefs with the new system. Granted, I am a developer, and I’m used to writing code. But it shouldn’t be *that* difficult to accomplish a simple thing like placing a link on the page.
Comments
No comments yet