Say you want to stop showing opt-in forms when subscribers or customers return to your website…
Where would you even begin?
Or, put more directly, how would you get your website to recognize when someone on your email list is visiting your website?
Most websites don’t do this. And it’s obvious. How many of us have received an email newsletter, clicked a link in it that led to the website, and was subsequently hit with a giant pop-up asking for an email address?
The good news is that it’s actually pretty straightforward to get your website to be aware of when a subscriber is back on it.
In this short guide, I dig in to how you can make your website “subscriber/customer aware”. While we’ve built this functionality into RightMessage, we want to share with anyone who will listen how you can do the same – regardless of what you’re using to build your email list. After all, a more personal, more relevant Internet is better for us all.
The first thing that needs to happen is to figure out whether someone on your website is or is not already on your email list.
Using this, you can make pretty straightforward but effective changes:
If you go to Facebook.com on a public computer, it’s not going to be logged in to your Facebook account. There’s no way for Facebook to know that you are you. For Facebook to know this, you need to first log in to your account. Once you log in, Facebook writes a cookie to the computer you’re on that links this device (or, more appropriately, the web browser you’re using) with a specific Facebook account.
Browser’s don’t really care if they’re on Facebook or your website. So the same rules are going to apply in order for your website to identify a returning subscriber.
There are two quick and easy ways to pull this off:
When someone opt-ins to a form, you’re probably sending them to a page that tells them to check their email or click a confirmation link.
If someone views this page (say it’s yoursite.com/thanks), you simply drop a cookie on their computer that says this person’s a subscriber. While someone could just go directly to this page and get that cookie, it’s unlikely – especially if you’re hiding the page from being indexed by search engines.
Some opt-in form tools, like Sumo, can be configured to hide forms when a specific cookie is found. Have it look for this cookie, and – 🎉 – anyone who’s opted in to your list won’t see opt-ins again. At least until they’ve cleared their cookies!
If you use RightMessage, we automatically remember that someone who submits one of your opt-in forms is a subscriber, and we also remember their unique ID (more on this in a second.)
When you send an email to someone that links back to your website, include a URL parameter that indicates that this person is a subscriber.
For example, if you’re linking to your latest blog post tack on a parameter exclusively for subscribers. Instead of linking to yoursite.com/my-new-post/ instead you’ll link to yoursite.com/my-new-post/?subscriber=true
Then you can configure your opt-in form software to not show if subscriber=true is in the current URL.
This becomes problematic if someone then goes to a different page. Should someone read your latest blog post and then go to a different blog post, the subscriber=true parameter won’t be carried over, causing your opt-in forms to start showing again.
The best way to do this is to cookie someone whenever a page has subscriber=true, and then determine whether to show opt-in forms based on whether that cookie exists or not.
Note: You’re also going to want to make sure you strip out your URL parameter after cookie’ing. Why? Because if someone shares yoursite.com/my-new-post/?subscriber=true on social media, you don’t want anyone who visits your site from that share to not see your opt-ins.
While it’s not much coding, you’ll need to know how to write a cookie. This can be done by writing a bit of JavaScript that looks for either /thanks or a URL parameter and then sets the right cookie.
One of the reasons we built this functionality directly into RightMessage is because we know marketers don’t want to be told that “hire a coder” is the solution!
In the above example, we gave your website the ability to know whether someone IS or IS NOT a subscriber. While not foolproof (ahem, incognito mode), it works really well.
But the above approach is pretty… well, dumb.
It doesn’t actually know who this subscriber is. It has no idea if they’re a customer, and if they are a customer what they’ve bought. It doesn’t know how they’re segmented or who they are or what they need.
To get access to the individual, we need to change our approach a bit. Rather than including subscriber=true in our links or cookie’ing anyone who visits our confirmation pages, we instead need to pass along unique subscriber IDs.
A few tools will do this automatically (ConvertKit and Drip), but most won’t. You’re going to want to use your email software’s templating to inject the unique subscriber, or contact, ID of the person on the receiving end.
For example, with Infusionsoft you’d link to yoursite.com/my-new-post/?subscriber_id=~Contact.Id~, which would replace ~Contact.Id~ with a unique identifier.
Then, on your website, you’ll need to not only cookie subscribers (like I detailed above), but you’re also going to need to remember their unique ID and create an API link between your website and your email marketing database.
(I can already hear the collective sighs of all the non-developers reading this!)
This will let your website effectively say, “Hey Mailchimp! Subscriber #12345 is currently on our website. What do you know about them?” And then your website will get back any and all data about that subscriber.
Once you get this data back, you can then start to really personalize your website. Maybe you replace your opt-in forms and pitch different products to different types of customers? Or you personalize sales pages based on interest or even the subscriber’s name? The sky is the limit!
But this will require, once again, coding out a custom bridge between your site and your email marketing database. We built RightMessage because we know no one wants to be bothered creating these bridges and maintaining them.
Frankly, it’s difficult enough for a software company like ours to maintain stable connections with email marketing software APIs (but it’s part of the job for us, and something we take very seriously.)
There are ways to sorta pass along segmentation information, like customer status and interests, to your website without creating a bridge.
To do this, you’ll want to include in your URL parameters the segment data you care about. For example, here’s how you could pass along someone’s customer status and their industry using ConvertKit:
yoursite.com/my-new-post/?subscriber=true&customer={% if subscriber.tags contains "Customer" %}true{% else %}false{% endif %}&industry={{ subscriber.industry }}
…which would result in URLs that look like:
yoursite.com/my-new-post-/?subscriber=true&customer=false&industry=retail
As you can probably see, this is really tedious. The cookie’ing code you write will need to handle all the possible segments you want to track (subscriber?, customer?, industry) and it won’t be real-time. If someone turns into a customer and you change their segmentation in your database, your website will really only become aware of it when they next interact with one of these special links you send out in a future email.
(Did I mention the “holy crap, we’re now talking about a lot of code” thing yet?!)
A lot of us want to store data we learn about someone on our website back to our email marketing database.
Whether it’s:
…We want this data to be synced up to our email database, allowing us to send more personalized emails.
To do this, you’re going to need to ensure that you’ve built an API bridge between your website and your email database – and that you’re sufficiently comfortable writing a lot of code that not only can pull segmentation data down, but also sync data up.
Doing this right, and being able to delivery truly unique experiences to your subscribers and customers is going to either require you to roll up your sleeves and get comfortable with coding or invest in software like RightMessage.
We wanted to write this guide for two reasons:
Hopefully you have a better understanding now of technically how website personalization and email database synchronization happens.
And no matter if you’re a RightMessage customer or happily content with what you’re doing now, our goal is that by dispelling the hype around website personalization and breaking everything down into clear and to-the-point guides like this, that you’re able to not only improve as a marketer – but that your audience is more appreciative of the time you’ve put in to delivering better experiences.
