How to Guarantee Consumer Data Security During an Omnichannel CampaignRESOURCES

How to Guarantee Consumer Data Security During an Omnichannel Campaign


Two new features in Circle to help you guarantee security during your omnichannel campaigns.

I recall seeing my first cross-media campaign and personalized website 15 years ago when I first encountered XMPie. Of course, the underlying property of every personalized website is the “personalized URL”, or “PURL”, and it’s the key to identifying who the recipient is. At that time, marketers would use a PURL like

For a long time that was how it was done. Invariably the customer’s name was featured in the URL because it gives the recipient a strong indication that the URL is for them, and marketers wanted to maximize the chances of the customer clicking on it.

But because the URL was the ‘key’ to accessing personalized landing pages, it was a problem if it contained personal information. You don’t have to be top security code-breaker to second-guess someone else’s URL!

Up until a few years ago, data security wasn’t at the forefront of many minds – let alone commercial printers and service providers putting campaigns together for clients. But we cannot say the same today! We now live in a post-apocalyptic – sorry, post GDPR world – in which data security and privacy have become paramount to planning any online activity.

We need to respect consumer privacy and protect data, while simultaneously creating deeply personalized communications and campaigns for our clients. How can we deliver the later while ensuring the former?

There are two new features in Circle and XMPie’s omnichannel toolset that both address these challenges and ensure that PURLs are harder to guess and lockable. These follow on from our other new features that were deployed as part of our commitment to GDPR Compliance.

Secure ID

SecureID is an optional mechanism to help protect PURLs from being guessed.

Now when you upload data to a campaign, and if that campaign uses PURLs, you have a simple choice:

  • Use one or two of the data fields as the recipient key or
  • Ask XMPie to add a unique ID for each recipient in the database

This second option generates a 32-character identifier for each recipient. It also checks for duplicates and inserts them directly into the data for you. (Even though there’s probably more chance of being hit by a meteorite while riding a unicycle and winning the lottery than finding a duplicate!) You can also include the same recipient in different campaigns, all with different IDs! The great thing here is also that the ID does not relate in any way to the recipient – there’s no mention of their name, their email – so trying to second guess a recipient is highly unlikely!

It is true that with secure ID the URL has now become more ‘unreadable’ and perhaps not attractive enough to print on a postcard, but we can’t have everything. And in any case, this is where the humble QR Code can make a welcome return to the frontline, hiding the longer secure URL behind a simple scan.

There also may be times when you don’t need a 32-character identifier, and this is fine; you can simply generate your own and flag that as the ID when you import the data. As with most things, we don’t restrict how you do it, we give you a choice and make it as easy as possible.

The value proposition here is that the ‘key’ has just become almost impossible to guess – so the recipient’s data is secure.

Secure URL

And what if your brand needs an extra level of security and protection? For example, a QR code on a Direct Mail piece will bring the recipient to their unguessable PURL, but anyone can scan it.

In this scenario, we need to protect the data on the PURL with a lock; the customer must authenticate themselves before any personal data or information is displayed, and this is where our second feature comes into play: Secure URL – or SECURL as it is now known.

SecURL was introduced into Circle back in December at the same time as secure HTTP support, as the two features are very much interlinked with each other. There’s no point in locking the door when you can simply walk around it to get in! SecURL is implemented inside Circle on a ‘project’ basis and works with both managed websites – those sites hosted on your own servers – or custom sites hosted elsewhere and not under your direct control.

Once again, we have designed this feature to be as flexible as possible, and you have the option of requesting a password OR using a username and password. Why? Because in many ways the SecureID can act as a unique username or identity, so why require an additional level of identification? In most cases you just need the user to validate themselves to access their data – and a single password would be sufficient. However, Circle gives you a choice.

With regards to the passwords, again you control the action. We allow both hashed passwords and cleartext passwords, and while clear text passwords are not generally acceptable in some cases, they may well provide enough security. For example, in a particular event registration campaign, you want to send out invitations to known recipients who are already in your database. On their Personalized URL, you want them to confirm their details and add their car registration and dietary requirements. Now, while SecureID provides a level of security, you also want to ensure that the users feel protected about their data. Here is where SecURL comes in. Each user needs to confirm their postcode or account number as a way of verifying who they are before presenting any data. This way you are using existing, ‘known’ data as a password, as this is a self-contained campaign where recipients have not self-registered. Or you may already have a ‘hashed’ or encrypted password stored for each customer in the data – and in such cases, you can use that and then SecURL will use the hashed password to check again.

In the event of a campaign with self-registration, where unknown consumers are self-registering to attend, registrants can enter a password themselves (which is then encrypted and stored in the database) along with their randomly generated ID. Any subsequent access to their URL or data would then need their password to be validated.

You can find out more about these features and see them in action in this recent webinar I presented. Here I share our latest security and integration updates, especially within trans-promotional or enterprise applications.