What is Locations? It helps your multi-location business better communicate with customers at a local level vs. forcing customers to only have a relationship with a brand, not a store. While people certainly have preferences for brands (“I love In-N-Out Burger. Animal style FTW!”), they have experiences with stores. When you want to buy gas or grab a burger, you don’t buy these things from a brand, you buy them from stores near where you live, work and play.

Based on that, we aimed to create a solution by which the multi-location marketer can allow people to build relationships with the stores they frequent most and subsequently create campaigns that are targeted locally, not nationally. Here’s how it works.

With Locations, you can import all of your stores into Signal based on name, address and any store ID you might have. These stores can then be mapped to Lists, which allows your customers to subscribe to receive information from the specific stores that they frequent.

The real magic happens when you assign attributes to these locations. You’re probably familiar with our awesome segmentation tools, which allow you to target your campaigns based on data you know about your subscribers, such as demographics and preferences. Locations allows you to segment based on attributes of a location, which are unique features that some of your locations might share. For example, if you’re a convenience store business, you may have some locations with an attached car wash and others without one. If you want to offer customers a $5 off coupon for your car wash to drive interest, you wouldn’t want customers who visit locations without car washes to receive that offer. Locations allows you to create a segment of just those stores with car washes and target your campaign to only customers who visit those stores.

Locations segmentation also allows you to group your stores based on geography. For example, if you plan to send a campaign that’s only relevant to your stores in Illinois, you can create a Locations segment for just your Illinois stores, which would prevent people who visit stores in other states from receiving the message.

Here are some more examples of what Locations empowers you to do:

• Target geographic groupings of stores (e.g. send to all locations in Iowa)
• Send messages to stores based on specific qualities they share (e.g. send to all stores with ATMs installed)
• Send messages based upon multiple location-specific attributes (e.g. send to locations with a car wash and are in Minnesota)
• Differentiate your messaging strategy based upon the uniqueness of your individual locations (think global, act local)
• Track customer engagement & marketing ROI at the local level (e.g. Compare locations to determine which ones are having the most success)
• This applies not only to the store level, but by geographic groups of stores such as regions, cities, and states
• Review and manage your locations database in simple way.  Editing and adding locations is easy, as is reviewing existing locations by city, state, or segment

Whether you’re a casual restaurant who wants to target an offer solely to diners of your newly opened Memphis stores, or a convenience store who wants to message subscribers of your stores that carry Bud Light Platinum, Location segmentation will allow the targeting on the geographic (in Dakota) and physical data (has an ATM) required to meet your needs.

Locations opens up tons of interesting targeting & reporting opportunities, such as:

• Deliver a coupon or notification to all people subscribed to locations that have a car wash
• Deliver a coupon or notification to all people subscribed to locations in Indiana
• Send a survey question to all people subscribed to locations in Indiana
• Test effectiveness of content in different locations (same subject line different regions / different message, different cities, same region)

Next Steps: 

Watch the introduction video below, read the KB article and let us know if you’d like access to Locations for your account. While it is obviously advantageous for businesses with over ten locations, businesses with less than ten can usually manage their segmentation capabilities easily as is. We’re excited for the direction of this feature, and look forward to evolving it with you (the users) over the next few months!

Feel free to leave feedback below or shoot me a line julian (at) signalhq.com. For all the latest news on Signal, you should also sign up for our newsletter here.

Click here to view the embedded video.

Here’s a brief overview of building an email template in Signal. You’ll need to be comfortable working with HTML; we built the template editor for those who are familiar with dynamic tags and who can tackle the often-challenging use of tables to control email formatting.

Full documentation can be found in our knowledgebase, along with a demo video (get the popcorn because it’s 20 min, but it really helps illustrate these concepts).

1) Start with a finished email

Your email template will include all the possible types of formatted content you might send. If your email contains latest news, a reminder of upcoming events and links to the five most recent posts on your company blog, you want to start with an email that includes an example of each. Every email you send using this template doesn’t have to include all of those content types, but you want the option to add them as needed.

To illustrate, I’ll templatize our monthly newsletter. Signal Received always includes a letter from the CEO, and can (but doesn’t always) contain product updates, news and tips.

2) Get to know our code snippets

Creating an email template in Signal is a lot like integrating a website into a CMS. You’ll determine which parts of the email need to be editable and repeatable, and use our code snippets to make it happen. There are multiple types, and each is fully covered in our knowledgebase article.

For Signal Received, we’ll use a mix of these code snippets to create editable regions and layouts.

3) Make repeatable layouts & regions

Layouts can be whatever you need. A link to a blog post is a layout. An article with headline, image and excerpt is another layout.

A layout becomes repeatable when you save it as such in the email template builder tab.

To call this layout in your email, create a repeatable region (via code snippet) and assign the layout to that region.

<div data-signal-editable="Maincol" data-signal-content-type="layout"></div>

Create as many regions as you need, and assign different layouts to each one if you’d like. Don’t want the blog post links showing up in your sidebar? No problem.

Each repeatable snippet must have a unique name so you can assign layouts to that region.

For Signal Received, we’ll need just one repeatable region, and we’ll create two layouts: the green header, and the article itself.

Signal Received’s news, product and tip layouts follow the same convention (headline, copy left, image flush right) but layouts can be totally unique. For example, our Spartan template has four different layouts:

4) Add required tags

In your code snippets drawer, you’ll find a set of tags that must be added to your template in order to send the email, including ‘unsubscribe’ and ‘update preferences’. You’ll call these tags in the href of an anchor tag:

<a href="{{unsubscribe_link}}">Unsubscribe</a>

5) Preview your work

Signal Received looks a lot different now that it’s been ‘templatized’. To add content, I click the ‘plus’ button, and the app presents the layouts I’ve assigned to this repeatable region:

Here’s how the email looks after adding a header and an article. Notice that each can be deleted, and more can be added.

Hopefully this gives you a sense of how much you can do with code snippets and layouts to make even the most complex email easy to send with Signal. Again, there’s a whole heck of a lot more in-depth information on this process at the knowledgebase, and the video is well worth a watch.

To bring these concepts to life and show just how quick and easy it is, I created a 3 minute video that shows you how to create 3 customer segments that you can use to target your messaging.

Click here to view the embedded video.

The move to CouchDB went well. Pages in our web application that would occasionally time out were now loading in a couple of seconds. And, our MySQL database was much, much happier. We liked CouchDB so much that we started planning a feature that would make heavy use of CouchDB’s schema-less nature.

And that’s when the wheels came off.

The feature in question is what we now call our Subscriber Profile. The Subscriber Profile feature allows you to collect any information you’d like from your subscribers, and use that data later to send them custom, targeted messages.  We knew that the variety of different information our customers would want to collect was wide.  Understandably, everyone’s needs are custom so we wanted to build a framework that could handle the array of unique information our customers wanted to store. A document database was a great fit for this problem.  The schema-less nature of a document database lets you store anything, allowing one subscriber’s document to be completely different from another’s.

Since CouchDB does not support ad-hoc queries, we used the popular couchdb-lucene add-on to allow us to search the documents. This powered our segmentation capabilities, enabling us to find the subscribers that matched criteria defined by our user.

This approach worked just fine for customers with smaller databases, but struggled to keep up for customers with millions of subscribers. Looking back, there are several reasons why CouchDB and couchdb-lucene were not a good fit for this project.

Why CouchDB and couchdb-lucene Were Not the Right Fit

HTTP is a Very Slow Database Protocol

You can do some amazing things when using HTTP as your database protocol. Anybody who can talk HTTP can be a client (which is pretty much everybody). Load balancing between multiple CouchDB instances is a breeze. And, you open the door to do some pretty innovative things, like allowing your web application to live side by side with your data, and serving it directly from the database to the client without the need for a separate web server (CouchApps).

But, HTTP is incredibly slow compared to a binary database protocol. Consider the simple task of fetching a piece of information from the database. According to our simple tests, fetching a document by ID in CouchDB takes 20ms. Compare that to 5ms when fetching a document from MongoDB (by an indexed field), and 0.4ms when fetching a row from MySQL by ID.

When using CouchDB views, the speed at which CouchDB fetches and returns the pre-computed view results more than makes up for the latency introduced by HTTP. However, when performing many operations on a document by document basis, this latency starts to add up.

MVCC Overhead

MVCC (multiversion concurrency control) is an important part of CouchDB’s design, and a key part of how replication works. Every write to a document in CouchDB creates a new version of that document in the database. The old versions of the document stick around, eating up disk space, until they are cleaned up by running a compaction operation on that database.

Database compactions themselves can be resource intensive and time consuming operations. If you’re not taking advantage of the benefits provided by MVCC, then the work required compact your database, and the extra disk space used by the older versions of the documents, are simply overhead. This is especially true in a write heavy database.

Large Databases Beat Up the Hard Disk

Our CouchDB instances (one primary, and one backup) were running on two 8 core 2.2 GHz machines, each with 32GB of RAM and 6 15,000 RPM hard drives in a RAID 10 configuration. Despite these database servers being fairly capable machines, it was uncommon to see the disk utilization (as reported by iostat) drop below 80%. In other words, CouchDB kept the disks on these database servers very busy.

Although we are not entirely sure what was causing this, we believe it had something to do with the size of our databases and views, and them being constantly swapped in and out of the disk cache (which was set to use almost all of the system memory).

CouchDB is not a Distributed Database (by default)

Apache CouchDB is not a distributed database. It is a stand alone database with powerful replication capabilities. While it is certainly possible to build a distributed solution using those replication capabilities (see BigCouch), nothing like this exists in the base CouchDB project right now.

We were at the point where we really needed a distributed database. The size of our databases and the number of requests they were handling were simply becoming too much for a single machine to handle. While moving to something like BigCouch was certainly possible, it would not have solved the other issues outlined above.

Lucene (used by couchdb-lucene) is not a Distributed Search Solution

Couchdb-lucene is a project that pipes changes made in CouchDB to the Apache Lucene full text search engine. This project is great because it essentially adds the ability to perform ad-hoc queries back to CouchDB. However, our search index had grown to the size where we needed a distributed search solution.

Again, while switching to use ElasticSearch (which integrates with CouchDB nicely) would have addressed this pain point, it would not have addressed the other issues we were facing.

Other General Complaints

We had some other general complaints with CouchDB as well.

First and foremost is that we found CouchDB difficult to develop for. The map/reduce paradigm takes a while to get used to. But, even after you understand how to build views to query your data, issues remain. Like the amount of time it takes to build a view against a large data set. We would sometimes wait days for a view to finish building. And, if by chance you found an error in the view flushed out by some edge case in the production data, you would have to scrap the view and start over after fixing the issue in the map/reduce code. This resulted a slower development process.

Second, databases and views are gigantic on disk. I know, I know…disk space is cheap, right? Well, not for everybody. Because of the size of the views, we had to upgrade to a pair of very expensive database servers that increased our monthly hosting bill by a substantial amount. Also, since the database and views are stored as single files on disk, it dramatically increased the amount of time it took to run our nightly backups. Even if only a single document in your 500GB database changed, you’d have to back up the entire 500GB file.

Third, we even ran into a few problems with replication, which is CouchDB’s main strength. When migrating CouchDB to a pair of beefier database servers, we ran in to a problem where replication would forget where it was in the process. This resulted in CouchDB having to churn through the entire 240GB database in order to determine the sequence number that it should start replication from, a process which took 4 days. This happened on more than one occasion, and was a huge time suck.

The New Solution

We have been playing around with MongoDB for quite some time. We first used it to back our mobile store locator feature. MongoDB has fantastic support for geo-spatial queries. From there, we used it to dramatically speed up the performance of our subscription list reporting capabilities. It had handled these two tasks very well, and after doing some research, we determined that it may also be a better fit for our Subscriber Profile feature.

Why use MongoDB instead of CouchDB for this feature?

• When it came to fetching and updating single documents, MongoDB was considerably faster than CouchDB
• MongoDB doesn’t use MVCC, so there was less overhead to deal with
• MongoDB doesn’t beat up the hard disk
• While using replica sets, MongoDB is more of a distributed database, distributing read requests, and handling fail overs

This left us with one question. How would we go about implementing our segmentation capabilities, or, the ability to find a group of subscribers based on some criteria specified by the user? Unlike CouchDB, MongoDB supports ad-hoc queries. But, like a relational databases, the proper indices need to be defined in order to make those queries fast.

In the hopes of removing the need for a separate full text search engine, we spent some time trying to determine if we could use MongoDB indices to implement the segmentation logic. Despite our best efforts, we were unable to make this work. Since our users can create any number of properties, and search for subscribers based on any of them, we would have had to index every property in every document . This would have required way to much memory.

So, we needed a full text search engine after all. Already knowing that we needed a distributed solution, we took a look at Apache Solr (Lucene’s distributed cousin) and ElasticSearch (also backed by Lucene). Using a Lucene backed search solution meant that we would be able to keep a good chunk of the code that we had already written to segment subscribers based on their profile data. We chose ElasticSearch based on it’s impressive feature set, strong community, and the fact that the project has a whole lot of momentum right now.

What All of this Means For Our Customers

Moving to a distributed solution for holding the subscriber profile data offers the immediate benefit of quicker response times when interacting with customer profile data.  Also, this solution offers a more reliable service moving forward.  You can rest assured that we have the capability to grow our infrastructure as you grow your subscriber base.

In addition, we have already been able to take advantage of our new distributed full text search engine. Shortly after standing up our ElasticSearch cluster, we moved our SMS message search functionality from Lucene to ElasticSearch. This added the ability to search for SMS messages up to a year old (previously you could only go back 90 days), as well as provided the ability to search for messages based on their “type”.

More recently, we were able to utilize ElasticSearch’s Facets API to power the data you see on the People Dashboard.

The future of CouchDB at Signal

As I mentioned at the beginning of this post, the Subscriber Profile was just one feature using CouchDB, and by far the one that caused us the most trouble. CouchDB and Lucene were simply not the right tools for this job.

The fact that we changed this feature to use MongoDB and ElasticSearch does not mean that we do not continue to use CouchDB, or would never use it for anything again. CouchDB views are an incredibly powerful feature. They’re not as flexible as some other options, but they really do allow you to query a large amount of data very quickly. And, CouchDB’s replication capabilities, and it’s ability to run on Android and iOS devices make it a very compelling choice for mobile devices, especially for applications that need to operate without a internet connection.

We are still using CouchDB in other areas of our application. While we have plans to move some of these features off of CouchDB and onto MongoDB, we currently have no plans to move the others.

I would never throw out a hammer because it didn’t help me drive in a screw.

Also, what if your makeup offer is valid everywhere except for Alaska? You know, since those free compacts might just crack in the cold arctic air. Wouldn’t it be great to be able to send a message to everyone in your database that you know do not live in Alaska?  To do this, not only would you need to be able to send the message to people who you know live in the other 49 states, but you’d also want to exclude everyone who you haven’t collected state data for, since those people could live in Alaska and therefore shouldn’t receive the message.

Finally, wouldn’t it be great to easily collect this data upon reply?

I’m excited to announce that you can now make all of these things happen within Signal. We just wrapped up a project to enhance our segmentation capabilities by enabling you to create more sophisticated segments for all of the scenarios above, and more. This will greatly improve your email marketing and mobile marketing efforts. Here are the details:

Learn More About Your Customers With “Absent/Present” Data Segmentation

Some specific improvements around data segmentation on existing, and non-existing data have opened a whole new world of opportunity that was not previously possible.  For example, you can now send a message to everyone on your list that you have a mobile phone number for (ie – they’ve opted in via SMS) but that you do not have an email address for with Signal. This is a great way to gauge interest in your email newsletter and build your subscriber base. This unique ability to message on the lack of data is a great way to learn more about your customers, without annoying those who’ve already shared that information with you. Here are some examples:

• Find contacts who do not have an email address
• Find contacts who do not have a mobile phone number
• Find contacts who do not have a city
• Find contacts who do not have a zip code (helpful for targeting at a local level)

For even more advanced needs you can combine absent and present value filtering. Say you’re a Chicago business in the clothing industry, and want to invite all of your subscribers that live outside the city of Chicago to a special event. You can do this with the Has value and is not filter criteria. This will help you reduce your marketing spend on this campaign by leaving out the unknowns, and focusing on the people you have data for. For example, the following filter would find all contacts that can be identified as having a city in their user profile, but exclude those that live in Chicago:

• Find contacts who have a city present in their user profile, and also where the city is not Chicago

Testing A Hypothesis With “Is Not” Attribute Segmentation

In addition to the benefits of the absent/present value segmentation, you can take advantage of is not or negated conditions. In this instance, you may or may not know if someone is a male, but as long as the answer is not female, you’re willing to send them a message. This type of segment is better for testing a hypothesis and messaging people you know have an interest in something, as well as those you think may be interested in something. For example, you could have collected Diet/Allergy data about your customers and can assume as long as vegetarian is not listed for your contacts, they might be interested in a meat lovers pizza. To set this up your criteria might look like this:

• Only show contacts that meet this criteria: Diet/Allergy: Is not: Vegetarian

While all of our filter methods using “is,” “is in list,” “is not in list,” before, at/on, and after work as usual, we’ve gained new functionality in the arena of absent/present, and is not attributes that can help you learn more about your customers, and test hypothesis.  We’re confident this can help you be a better marketer, and send more relevant content. We’ve even spent time improving the interface around creating segments to encourage this behavior. While this may sound confusing at first, it’s actually quite simple and delightful to use.

We’re really excited about this new functionality and think you will be to. We’ll be putting together a video of this functionality in action for you early next week.

That said, you’re probably also struggling with how to make sense of this emerging space. Lots of providers claim to unify these channels and it’s hard to really understand the specifics of what they mean by that.  It’s also hard to know what to look for – what are the key ingredients a provider must bake into their product in order to offer you a successful cross-channel solution?

Enter Signal. In working with our terrific roster of customers, we’ve seen countless RFPs and been asked the same questions often enough that we realized we could make your life easier by simply publishing what we know.  So, we’ve done just that. 

Our Cross-Channel Marketing Request For Proposal Template gives you the definitive roadmap for what questions to ask potential providers, why those are the right questions to ask and what a winning answer might be. The best part? These questions and insights are all sourced from actual RFPs and questions we’ve received from our customers who are now seeing proven results in unifying their customer data and digital marketing in a single product.

You can download the RFP right now, no strings attached.  No form to fill out or sales pitch to listen to.  We want as many marketers as possible to benefit from the right cross-channel solution, so please spread the word!

Still asking what’s in it for us? Well, we’re obviously confident that Signal has a unique solution to power cross-channel marketing and are comfortable stacking our response against anyone in the space.  Feel free to challenge us by asking us to submit our own RFP response for your business and compare it to other providers your considering. We love challenges :)

As always, please let us know what you think about the RFP, what we could do better and what you think we should write next by emailing us at feedback@signalhq.com.

Why is plain text email still relevant?  A couple reasons:

• Improved deliverability:  It’s well known that some people configure their email clients (and devices) to block HTML.  Also, you reduce your chances of getting dinged by spam filters, as the addition of a plain text option indicates you’re more likely to be a safe sender (spammers are usually lazy and don’t take the extra step).
• Plain text emails work better for certain people and certain situations: Some people find plain text more readable and there is content, such as a simple daily notification, that lends itself better to plain text delivery.  Plain text is also a safer option for mobile email clients, as some still don’t display HTML properly.

With the addition of a plain text option, you now have increased odds that your message will reach inboxes and be presented in a format people can read, no matter their device.  While we don’t require you create a plain text version of your emails, it’s recommended that you take the time to create a plain text alternative.  It’s best practice and we’ve made it very easy to do!  Also, no need to worry that people will get two versions (HTML & plain text) of the same email. Each recipient will only ever get their preferred version of the message, never both.

You’ll find the plain text configuration option on step 2 of our email builder.

You can create the plain text alternative after you’ve created the HTML version. This offers the added benefit of being able to copy  text straight from your HTML version and edit it inline.

It’s also just as easy to send yourself a test message of the plain text version to ensure you’re happy with it’s content.

We hope you’re just as happy with this new feature as we are.  Feel free to let us know how happy, or offer any feedback, in the comments or by sending us a note at feedback@signalhq.com 

Date: January 13, 2012