Challenge
Our client has been using Eloqua for almost a year now and was looking for a new way to leverage their existing database of contacts to introduce the brand to a broader network. So, we decided to attempt the dreaded Refer a Friend (RAF) technique.
The RAF would be aimed towards encouraging existing contacts to introduce their friend to the client’s community, which in this case, it is an actual master planned community.
RAF would be used to invite these contacts to bring a friend to the new cafe with the promise of a free coffee. This offer would be added to a new footer to be used on any relevant emails.
Upon exhausting the Topliners and Cloud Documentation resources, I realised it was quite the feat that we had decided to attempt, with little to no information on the actual process of setting it up… Which is fair enough because it’s generally not considered best practice.
Goals
For the purpose of clarity and brevity, please note the following definitions:
- Referrer: The existing contact in the database who is referring their friend for a coffee.
- Referred Friend: The friend being referred for the free coffee.
- Be compliant (in Australia)
For this particular exercise, we were aware that we would need to be compliant towards privacy and data collection, as well as the Spam Act. Upon some research and legal advice, there were a few things we knew we had to abide by.
- Express consent.
- Disclosure of personal information.
- A prevalent unsubscribe.
So, I needed to find a way to send this initial invitation email, ensuring that the Referred Friend would not receive any further marketing emails, until they registered to receive a free coffee. As such, these are the steps we took:
- Automatically unsubscribing the Referred Friend when their information is first submitted by their Friend.
- Only subscribing them to marketing communications once they have landed on the registration landing page (which includes a privacy disclaimer).
- Create field merges for personalisation
To increase open rates and ensure that the Referred Friend knows why they have received this email, we want to collect the Referrer’s information under the Referred Friend’s contact, so as to create the necessary field merges.
To achieve this, we followed this logic: When the Friend submits the Referred Friend’s details in the RAF form, this will create a new contact, where the Referrer’s information populates hidden fields: ‘Referrer’s First Name,’ ‘Referrer’s Last Name’ and ‘Referrer’s Email Address.’
- Update all relevant fields
We realised that there would likely be Referred Friends already in the database, and as such, we did not want to overwrite any existing data or automatically unsubscribe anyone that was already subscribed.
(More about this in the Steps to Success section but…) We created a field called the Subscription Status (in retrospect, not a good choice), which could be populated with either ‘Registered’ or ‘Not Registered’.
The logic was that when the Friend entered the Referred Referrer’s information, they would stay subscribed if they were already Registered. Otherwise, they would be set to Not Registered and subsequently unsubscribed.
Steps to Success
- Document and benchmark
We noted the following metrics to gauge how well RAF would perform over the months:
- Amount of referrals
- Amount of voucher redemptions
- Referral to voucher redemption ratio
- Conversion rate from Enquiry to Prospect for Referred Friends
- Create new fields and field merges
(REF: Definitions under Goals)
In retrospect, not the best choice of field labels for these, but you live and learn. So, we ended up creating the following fields and field merges:
Fields | Field Merges |
|
|
- Create RAF form with hidden fields
To capture the Referrer’s details and set the Subscription Status to Not Registered, I created hidden fields that I mapped in the following way in order to create a new contact.
Source Field | Target Field |
Friend’s First Name | First Name |
Friend’s Last Name | Last Name |
Friend’s Email Address | Email Address |
Referrer’s First Name (Hidden) | Referrer’s First Name |
Referrer’s Last Name (Hidden) | Referrer’s Last Name |
Referrer’s Email Address (Hidden) | Referrer’s Email Address |
Subscription Status (Hidden) | Subscription Status |
The Referrer information would come through via field merges and the Subscription Status would be populated through a static field merge.
- Create assets (emails and landing pages) with the necessary disclaimers and prevalent unsubscribe buttons
- Set up form processing steps - (update contacts with form data)
Now, this was the tricky part. I spent quite a while trying to figure out the best combination of processing steps to only unsubscribe new contacts by only updating the Subscription Status of the said new contacts.
After hitting a few walls with attempting to only subscribe/unsubscribe contacts conditionally through the processing steps, and using every method under the sun to control who gets subscribed and unsubscribed and which fields get updated, here is what I ended up with:
The idea was that, the Subscription Status only updates to Not Registered if the field is currently blank. And then, (because conditionally running steps was making it bug out) all of the contacts get added to a program where if they are Not Registered, they are immediately unsubscribed.
So this is what we ended up with for the RAF form:
Processing Step | Purpose |
Update Contacts - With Form Data | Create the new contact |
Send Submitter an Email | Send coffee invitation email to new contact |
Add to Program Builder | Unsubscribe anyone who is Not Registered |
Redirect to Web Page | Redirect to confirmation URL |
The Registration for the Referred Friend was a far easier feat:
Processing Step | Purpose |
Update Contacts - With Form Data | Update the contact |
Send Submitter an Email | Send coffee voucher email to new contact |
Subscribe Contacts Globally | Subscribe everyone!!! |
Redirect to Web Page | Redirect to confirmation URL |
- Create prefilling link
As we need the Referrer Friend’s name and email to come through in the hidden fields, we need to add some fancy URL parameters to the landing page URL.
- Create email footer
- Update existing contacts with new field
Of course, creating the new Subscription Status field meant that all of the existing contacts in the system had no status. So, I simply created an update rule for all currently subscribed contacts to have the Registered status.
Next Step
We are currently finalising the strategy for the RAF, ensuring that all the relevant promotions and assets are in place within Eloqua and the cafe itself. We are really excited to get the RAF footer underway. While it is a far less aggressive way to generate new leads, it is very much aligned to the brand of the welcoming, new community.
We are not expecting a huge spike in new leads, but reviewing the efficacy monthly, we will be able to set benchmarks and test a range of offers and opt-ins. We will also be looking into creating an initial nurture stream to qualify the new referred leads.
Overall, we will be able to gain valuable insight on how the community is developing and their levels of engagement.
OMC Courses that Came in Handy
- Eloqua 10: Advanced Editing and Form Processing
- Eloqua 10: Fundamentals of Forms & Landing Pages
- Eloqua 10: Program Builder Overview (WBT)
- Eloqua 10: Personalizing Campaigns