Skip navigation



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.




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.


  1. 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).


  1. 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.’


  1. 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


  1. 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


  1. 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:


FieldsField Merges
  • Referrer’s First Name
  • Referrer’s Last Name
  • Referrer’s Email Address
  • Referred Friend First Name
  • Referred Friend Last Name
  • Referred Friend Email Address
  • Referrer’s First Name
  • Referrer’s Last Name
  • Referrer’s Email Address

  1. 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 FieldTarget Field
Friend’s First NameFirst Name
Friend’s Last NameLast Name
Friend’s Email AddressEmail 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.


  1. Create assets (emails and landing pages) with the necessary disclaimers and prevalent unsubscribe buttons


  1. 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 StepPurpose
Update Contacts - With Form DataCreate the new contact
Send Submitter an EmailSend coffee invitation email to new contact
Add to Program BuilderUnsubscribe anyone who is Not Registered
Redirect to Web PageRedirect to confirmation URL

The Registration for the Referred Friend was a far easier feat:


Processing StepPurpose
Update Contacts - With Form DataUpdate the contact
Send Submitter an EmailSend coffee voucher email to new contact
Subscribe Contacts GloballySubscribe everyone!!!
Redirect to Web PageRedirect to confirmation URL

  1. 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.


  1. Create email footer


  1. 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

As the Marketing Automation point person at your company, there are usually several projects you can focus on to optimize OMC. From data cleansing programs to email marketing, to deliverability and compliance, there’s not a shortage of work. OMC is probably the most complex of all the Marketing Automation tools out there. As a long time user of OMC, including client side and now as a consultant, I’ve noted 2 items that if implemented right away, have a huge impact on your overall results.


Focus on the Data

When a tool like OMC is implemented, it may be tempting to dive into campaign execution right away, hoping for quick results while simultaneously wading into the waters of automation. Don’t fall into this trap. Spend the first couple of months focusing on the data and implementing data programs.

  1. Before you start, ensure that you have identified your database of record. This is the database that feeds all other dependent databases. This is important, so you know when it is “ok” for OMC to update the database of record and when it is not.
  2. Ensure that you have a documented Marketing Complete Profile (MCP) field set. This is the minimum required set of fields that a Lead must have complete, to be considered ready for the next step in your Lead Management process. Don’t rely on data to come in complete and "ready-to-use" from the visitor. It's a process. Also, collect only what you must get from the visitor, and make those fields required on the form. The fields should make lead management easier, but should not sacrifice user experience either. Create and maintain this delicate balance consistently through all interactions with your prospects.
  3. Now that you know what to collect, implement Progressive Profiling to nudge your records to MCP status. Decide which fields you will ask for during the first visit. A good starter set would be First and Last Name and Email Address. During subsequent visits, ask for other fields like Title, Business Phone and State. Once you have the State, use data programs to populate the Country from State and Region from Country. Ensure you are using ISO standard lists and if possible, use codes rather than spelled out names. This maintains data integrity throughout all databases.
  4. Update your Form Processing Steps to add new form submissions to your data programs. You want your data clean before sharing it with other systems, especially your CRM. 


Implement a Universal Form Engine

If you are still creating unique form engines in OMC for different web forms, stop. Implement a universal form engine working closely with your web developer to ensure that javascript on your corporate web pages can pass the unique values needed to route data to the right place. Examples of these values include Lead Source, SFDC Campaign ID, Email ID for Autoresponder (which will vary based on the web page type), Campaign Step ID (for Webinar Registration Campaign), and other fields that your particular organization requires for Lead Management.


The flow looks like this:


The Whitepaper Request, Information Request and Webinar Registration are all individual web forms sending data to one form engine, which processes data according to the hidden fields submitted. Your web pages will pass in the hidden values, which will then be used in conditional processing steps in the form. A universal form is a must have to save time and improve accuracy due to less manual intervention. If you haven't implemented this best practice, put it on your list today!


OMC Training Classes to Attend

  • Web Profiling (a must attend)
  • Progressive Profiling
  • Advanced Editing & Form Processing



If you are new to OMC, take the focused approach. First, tackle the data piece by mapping out your data flow and knowing when to update CRM, what fields get updated, and in what format. Next, create data programs that standardize and clean data coming into Eloqua. This will allow you to build targeted segments and more personalized emails. Your personalized emails will generate interest and produce the right inquiries, leading to higher qualified leads for Sales.


Additionally, having a universal form will support a cleaner database. By processing all data through one central form, you can easily manage how data gets processed, while ensuring all data is processed uniformly.

Filter Blog

By date: By tag: