Using dynamic data in marketing emails is a standard, at this point in 2022.
Blog posts and articles are saturated with practices about it, and virtually everyone in the industry uses some type of personal dynamic information associated with their contacts to provide better communication and to improve the quality of the user experience.
It’s a given and we at iPost, like so many others, have been using it for decades.
That’s why today we want to take the discussion a step further: using real time dynamic data in your emails to fuel business growth and improve your email messaging.
What Real-Time Dynamic Data is (and what it isn’t)
Dynamic data, sometimes also known as transactional data, is defined as information that is periodically updated, often in an asynchronous way.
Surely most of us marketers have a program set up that runs every night and imports into the mailing platform the latest data about customers, orders, preferences.
Sometimes Dynamic Data is confused with Real-Time Data, even though it’s a separate concept: Real-Time Data is data that is “delivered immediately after collection”.
Often it doesn’t even get saved, but it’s analyzed to produce some type of report.
The confusion between the two arises from the fact that we often think of our data is up-to-date, fresh, current. Except that, most often than not, it isn’t.
How fresh is your data?
The easiest way to include personal data in your marketing sends is to have it available inside your platform.
At iPost, to make it even easier to replicate the data structure you might have externally, we give you the option to use a MySQL relational database, with the ability to write and run queries against any tables: both the ones you create and the ones containing system information.
One of the reasons why we decided to build these functionalities is that often the data you need or want to use in your marketing campaigns is sitting in separate places.
You might have order information inside your e-commerce, while customer data is in your company database. Email preferences might live only within your email platform, but loyalty or membership information might be in a whole different place.
Some companies set up direct connections that keep the data synchronized between their system and the ESP.
We know that, because we implemented it for some of our clients, but it’s not an easy process. Most platforms don’t even support it and, when they do, there aren’t resources that have the time or capability to work on the integration.
That’s why we come back to our nightly processes from the beginning of this article: automation, imports, queries, files, custom integrations.
But is that data up-to-the-second or even up-to-the-minute? Likely not.
That’s one of the reasons why we built a Webscrape function.
Web Scraping in Emails
This time we’ll refer to the Techopedia definition for the term: “various methods used to collect information from across the Internet”.
It’s a broad definition, so let’s make it clearer what we built, specifically: a function that you can use in the code of your email to send data to an external resource (a website, an FTP, an API endpoint) and collect a response, when available.
You see where I’m going with this, right?
Our function will let you:
- Call a service that contains data that might be fresher (“Real-Time”) than what you have in your ESP or just information that you were not able to sync
- Specify parameters so that the response will be personalized for each contact (“Dynamic”)
- Retrieve a response, process it, and combine it with other data available to you
- Insert it in the email
Process and insert Real-Time Dynamic data.
And you can do this at send time, for each recipient.
Sounds great, right?
Yeah, we agree!
But if instead, it’s still a bit obscure how that works, let me give you a real-life example of how we implement web scraping in emails for one of our clients.
Real-Time Dynamic Data Use Case
There are many scenarios where one could use these combined functionalities.
You could use it to notify an external system that a send is happening to specific email addresses.
Or you could insert weather information for the locations where each recipient lives, getting the data available right at the time of sending.
The use case I want to present to you is different but equally interesting.
A client of ours had a loyalty program and wanted to insert the loyalty points in their emails.
They figured it was too complicated and expensive to create a custom integration just to retrieve the latest point balance using the loyalty program API.
Fortunately for them, we proposed to use the Webscrape function inside their emails.
With a few lines of code, we were able to call the loyalty API for each subscriber, passing the contact’s identifier to retrieve the current balance.
Then we inserted the output in the HTML.
The thought of “I am not sure it can be done” never enters our minds here at iPost.
And that’s not just a fluff marketing phrase.
Our team gets excited when there are unique use-case needs that we haven’t solved before.
And we work together with our clients to figure out the solution that would be best in terms of business goals, budget, timing, expertise.
And when we do find a solution that we know other clients might benefit from, we act accordingly:
- We make it available to other clients
- We add it to our set of functionalities
- We document how it works
- We explain use cases in which it might be useful.
- And maybe write a blog post about it to spread the word ;)