There are times you would require additional customisation and dynamic capability in your campaigns. There are campaigns that are not your standard day-to-day campaigns that demand high levels of customisation and we would often end up rejecting them due to technical capacity. Luckily for us tech-marketers, we are in this new era of APIs, that if rightly used you can achieve any levels of customisation that you can possibly imagine. This article will explain with help of a campaign, on how to set up your own data layer, integration layer and use them in your campaign.

 

Overview

Sage is a corporate partner of the Invictus Games 2018, had a pool of free tickets to give away for its exclusive customers, partners and employees. And we decided to run a campaign in Eloqua to invite people to claim their allocated tickets. We needed to balance the ticket deliverability and enhance the customer experience.

 

Problem

Although this sounded like a regular Roadshow event there are details that are critical which added to the extra challenge that made this campaign fun to work with. The problems/ challenges are as follows;

  1. A portal to allocate and manage tickets to customers.
  2. The process must allow for different events and ticket quantities for each contact.
  3. Variable ticket count can be allocated to customers for different events.
  4. It should be scalable, that is, the process must allow the addition of new ticket allocation at any point within the lifecycle of the event.
  5. Making the setup reusable for any such ticket distribution in the future.
  6. May not be able to use Eloqua’s default Custom Data Object (CDO), as it would be complex to provide an additional interface for the Events to handle the data.

 

Solution & Implementation

Like every other online application, we need 3 layers to achieve this.

1. Presentation Layer (Eloqua)

This is none other than the campaigns that the customers interact within the form of a Landing page or Marketing Email.

 

2.  Data Layer (Eloqua CDO / Google Spreadsheet)

This is where all the ticket allocation happens. The customer and their respective tickets allocated to them are placed here. This could be your CDO or a Google spreadsheet. If you are going by the CDO approach, it might be challenging to provide access to the CDO to the events team directly because (a) they might not be provided with Eloqua access. (b) the events personal can find it difficult to manage this data in CDO. In either case, they will have to rely on Marketing Automation.

 

However, by managing the ticket allocation data in a Google spreadsheet will give a great advantage to the Events team, in terms of usability and the flexibility.

 

3.  Integration Layer (Rest API, Custom JavaScript / Zapier Automation tool)

This is vital to communicate between the Eloqua landing page where the customer will claim their tickets and the data layer where the ticket is placed. In case you decided to use Eloqua CDO to place your date, the integration is readily done. But if you have chosen a 3rd party such as Google spreadsheet, then we need to use one of the public JavaScript libraries called tabletop.js. (https://github.com/jsoma/tabletop). You can find detailed instruction on how to implement this JavaScript in your HTML page (Eloqua landing page). Note tabletop script can only fetch the data from your sheet and not update them back.

 

For communicating back to the sheet in order to update the claimed count and the statuses, you might have to use a REST API or a Zapier integration tool. I am not going to get into the details of it in this blog but, in my implementation, I used Zapier simply because it was available to our organization.

 

  

Fig.1 High-level execution plan of the ticket allocation implementation

 

One more key consideration you must be aware of when using the Google sheets as your data source is that you must try to avoid feature sensitive data such as email address in the spreadsheet considering the data security policies. However, if you can store the Eloqua ID for each contact, and then use a web data lookup to identify the customer, would be an ideal scenario.

 

 

Fig.2 Detailed implementation flowchart of the ticket allocation process.

 

 

Results:

  1. Delivered free tickets over 200 customers.
  2. Allocated over 1000 tickets for 8 different events.
  3. Each customer would receive a unique set of tickets to the events that they are allocated with.
  4. The events team were able to set a deadline for claiming tickets.
  5. Good visibility of allocated vs claimed tickets.
  6. 100% ticket utilization.
  7. The same technique and solution were used to achieve other solution such as managing bookings for multi-webinar series. And therefore, the solution is reusable and scalable.

 

Key takeaways

The potential, the depth and the level of complexity of campaigns can be hugely extended by strategizing a solution where one could mobilise data across various components of Eloqua, JavaScript and 3rd party tools.

The following Oracle University courses are key to drafting this solution:

Develop & Design

Prioritize & Process

Convert with Custom Objects