Our company, like many, publish volumes of content across multiple domains and languages. This content was performing well, and was driving considerable net new contacts. But as a B2B organisation new contacts, while critical, don’t result in revenue on their own. We needed to be able to take these contacts, none of whom were qualified in any way as sales ready, and get them to MQL status, or enter them into what SiriusDecions call Pre-MQL nurtures. Of course, the same approach could be used with any programme really.
We had already streamlined to just four forms across our (non-Eloqua) web domains, so the data was posting to Eloqua. Despite gating valuable content though, we had no simple way to monitor content downloads, or to take a clear action based on that consumption – simply because these four forms were being used for every conceivable purpose, and across a wide array of products.
We needed to know what the contact downloaded, and use this information to very simply pull them into a Pre-MQL nurture. Plus the content team wanted an easy way to determine the performance of content, not just at an item level, but performance for an asset across all language variants and locations hosted.
These two challenges translated perfectly into two key goals that we could use to measure success.
- Could we automatically enter contacts into Pre-MQL nurture
- And could we report on content performance at a global level
Setting the benchmark to measure that success against was simple - with no way to measure, or no scalable way add contacts to campaigns today, if we could do it once a solution was implemented then we had succeeded.
It was clear from the start that writing something to the contact just wouldn’t work, at least if we wanted or needed historical data. And we also needed a 'one to many' relationship, so that we could link every piece of content downloaded back to the contact.
Being well on the way to Luminary, I’d done my Integrating Custom Objects with the Campaign Canvas course. The ‘one to many’ and ‘keeping history’ requirements lead us almost immediately to realising that a CoR was the way to go.
We settled on a fairly simple four field Custom Object as I am a big believer in keeping things simple. We record the email (obviously) plus the SFDC Campaign ID – which for us, as we don’t run Closed Loop Reporting, is a key field for performance tracking, the name of the content and we date-stamp the record too for reporting.
There are lots of posts and articles on Topliners, so you don’t need me to step you through creating a Custom Object. But this is what ours looks like, and the fields it contains.
Great – we know had our CoR but how were we going to write the data to it? Obvious really when you’ve done your Eloqua 10: Advanced Editing and Form Processing course! Use form processing to write to the CDO.
We went back to one of our famous four forms and updated the form processing step on this to write back email, SFDC Campaign ID and the Content value. We already had a content field on the form, it was just never consistently used, sometimes with a form name in it, sometimes with a URL, but usually blank. It seems a forward thinking colleague had anticipated our need.
So it was time to test. And test we did. And then scratched our heads. The form submission was writing the required information to the Custom Object, but it was overwriting the value every time. So instead of multiple entries, it was overwriting the value. We were puzzled, at least for as long as it took us to search Topliners to see where we were going wrong. This post on Topliners was from someone that had exactly the same problem we did, and there in the comments, the answer, posted by Kelly Cohen, with the Eloqua support advice “on the processing step we leave the Select the Key Field blank and on the CDO itself we have the Unique Code Field as None.” Not exactly obvious. Changes made, back to testing, and hey presto, multiple records per contact -- and over 60,000 records in 3 months. That’s a lot of new contacts we can easily pull into campaigns.
So how do you get from a CoR to the Campaign? It’s all in the Segment. All we need to do is build a Segment that looks for contacts that have entries in the Custom Object that correspond to the relevant piece of content.
Let’s assume we create and name a global piece of content ABC_GL_PDF_MyGreatContent, then the local versions will follow similar formats ABC_GB_PDF_MyGreatContent for the UK and ABC_FR_PDF_MyGreatContent for France. Now I can build a simple segment that looks for any contact with a Custom Object Record that contains MyGreatContent.
I now know that no matter where, or when, the content is published, once the form has the content value populated properly, we will be able to always pull the contact into a segment and ensure they go through the best programme designed to get the contact to the magic MQL stage. No more updating segments continually, adding criteria, chasing field marketers, or worrying that something new next month won't point at my programmes.
The key to this approach working is to have a clear naming convention that is used and followed by everyone. A typo in the content name can result in contacts for that entire asset simply failing to route into the correct campaigns. We’ve been working with a wider group of colleagues to validate the naming convention and tool we built to make sure it meets all of the reporting needs, as well as aligning with the content team to support them with their reporting requirements.
As to the reporting challenge – well we now have 60,000 records on the CoR and are having great fun with the analytics. Lots of data driven decisions now being taken.