Eloqua is one of our favorite email marketing platforms – we love using it and we love building extensions for it. Every now and then though, we wish for a feature. At PortQii, we have taken some of those wishes and turned it into products; and thanks to a growing bunch of amazing users, we get some great feature requests. So, if you are one of our regulars, thank you for your ideas and contributions.
Apart from feature requests, there were many tutorial requests – we promise that we are trying to figure ways to bring them to life, but in this post, we would like to list a few common sins we all commit and how we can avoid them.
No matter how careful we are, the Eloqua instance will bloat – and there are two main reasons for this:
One, every member of the team, creates a copy of an asset before making any changes, and copies take up space – in most situations, this is the most common-sensical thing to do. We wouldn’t want to make changes to the original – why not; because the original may still be in use, it may be live, or perhaps someone is planning to use it in an upcoming campaign. These are all very valid reasons and we shouldn’t vandalize someone else’s asset – we are trying to be decent here.
Two, we don’t delete or archive the older assets. We do this for the same reasons – no one is sure about the owners of these assets and there aren’t enough indicators that show us how bad the impact of deleting one of these assets would be. Even if the names of the assets carried some clues, that would have been helpful, but we mostly have nothing of that sort.
What could we do about this ?
One of the things that we can do as an organization-wide standard practice, is that we expect the owners of the campaigns to clean up after the campaign. Bloated Eloqua instances with copies and copies of assets are no fun to work with, because they make the performance of Eloqua lethargic and give us spinner-fatigue. Cleaning up is best done right after the campaign – but at times, we are stuck with campaigns with missing owners. Either the owners have moved on from the organization or have transitioned into a new role.
We could use PortQii’s Asset Dependency Manager (ADM) for such situations. This app can help you clear what’s currently not in use, and what’s safe to archive. It helps you reclaim contact fields for your first-party data journey; remove unused emails, campaigns, forms and other such assets that we no longer need.
Since custom contact fields are in such short supply; we get only limited fields – cleaning them up every now and then helps others who may need it. ADM can help you delete contact fields that are not in use and reclaim the precious contact fields. With these practices, we can make our instance as good as new and users will appreciate the highly responsive instance.
Maintaining versions of an asset instead of copies also makes our instance lean.
Another PortQii app that makes it easy to maintain an Eloqua instance is the Asset Version Control (AVC) – just like Google Drive or Git, the app maintains versions that we can roll back to if needed. This will provide more confidence to team members who are wondering if they can indeed make the changes they need. They can make the necessary changes and rollback to a previous version after previewing what a rollback can look like.
Another thing we can do to make our instance friendly is to use names that represent the asset correctly. The asset starts out as a test_asset or a new_asset and we forget to rename it to something that’s appropriate.
The Oracle Eloqua dashboard gives us real time updates on performance, but the generic names on the graph don’t tell us much. Let’s take this name for example:
It’s mouthful sure, but once named, we can always tell what campaign it is without needing to double-click into it. Having a standard that everyone in the organization follows to ensure that the assets are named uniformly is a good idea, but most organizations have people moving in and out of it frequently. This makes it difficult to maintain a nomenclature – but PortQii’s Asset Naming Assistant (ANA) app can help.
Once we figure out what the name can be made up of, the ANA does the naming for all the new assets. ANA can also rename all our old assets using the same nomenclature – Not only does it rename older assets – it also makes sure that nothing breaks because of the renaming exercise.
Make better use of the customer data
Typically, we import contacts from our CRM and other external systems; And that becomes our segment we communicate with – but that is static data and evolves over time, and changes even before the campaign ends. If there are new interested customers who can benefit from the campaign or there are older customers who won’t benefit from the campaign, CRM can tell us – but our instance is not talking to the CRM in real-time are we?
We should, and it’s much easier to do with PortQii’s External Data Intelligence (EDI) app. Instead of campaigns depending on the static data that was imported at the beginning of a campaign, EDI constantly reads data from the CRM, mainly SalesForce.
Querying Salesforce is way more powerful than querying Eloqua. Not only does this allow us to make the most of the latest data from the CRM, it also allows us to narrow down the segment to only those customers who will really benefit from the campaign.
Keep them apart
One of the best ways and an industry best practice to keep the Eloqua instance organized, is maintain multiple instances. Organizations using separate instances for each geography, product or brand, language, or a plain sandbox find it way easier to manage marketing operations.
Having separate instances brings a new problem, which is: how do we reuse campaigns or assets across instances. If a campaign did well in one geography and we want to import that into another instance, we can’t – at least not without PortQii’s Transporter Sync app. Transporter Sync allows us to move.