Eloqua for regional and country marketing teams
A global instance with a central Ops team and thirty countries asking for email is the most common Eloqua setup there is and one of the hardest to run well. Eloqua has the controls to carve the instance up and they are good ones. They take care to set up and they still leave every local marketer either waiting on Ops or working in Eloqua.
Updated
In short
Eloqua gives a global team four tools for regional teams in one instance: security groups per region, business units to separate assets and data by brand or division, contact security labels so each group only sees its own contacts and email groups per region or language for subscriptions. Set up well they let a country team work in Eloqua without seeing the rest of the world. They also mean every local marketer needs a license, a security group and training, local sends still bypass approvals when they are simple campaigns and brand consistency depends on templates being protected everywhere. Most global teams either keep building every local campaign centrally or let regions in and absorb the mistakes. Campaign Launchpad gives each region wizards with local choices, local approvers and locked templates, with Ops administering and reporting on every region and every instance from one place.
The shape of the problem
A global company runs one Eloqua instance because the alternative is worse: separate databases, separate unsubscribes, a contact in two systems. Corporate marketing sends from headquarters. Thirty country and regional teams need to send too, in their languages, to their contacts, on their schedules.
Central Ops can build all of it and the queue stretches to weeks, with Ops in one time zone and requests arriving from twelve. Or the regions can be let into Eloqua and the first time a country team sends a global segment a product update in the wrong language everyone remembers why they weren’t.
Eloqua has a set of controls for the second option. They are worth understanding whichever option you take.
Eloqua’s tools for one instance, many regions
Security groups per region
Everything starts with security groups. A regional team gets its own group with its own licenses, interface access, action permissions, asset creation rights and default asset permissions. That is how you give the DACH team the ability to create campaigns and emails but not segments or email groups and keep them out of Settings entirely.
Business units
Business unit membership lets administrators “support separate brands, divisions, and lines of business by categorizing users based on their business unit.” Members get access to the assets and data within their unit. For a company that is organized by brand or division rather than by geography it is the primary split; for a regional company it layers on top of regional groups so that, say, the industrial brand’s APAC team sees the industrial brand’s APAC assets. It is included in the Standard and Enterprise trims.
Contact security
Business units and asset permissions govern what a user can open. Contact security governs which contacts they can reach. You define label categories, Region is the usual first one, assign labels to each regional group and build a label assignment program on the canvas that labels contacts as they arrive. After that “security group members can then only access contacts that have the same labels as their security group.”
For regional teams this does three useful things. A regional user’s segments only count their contacts so the all-contacts segment is their all-contacts segment. A campaign “inherits the labels of the user who activates it,” so a regional send can only ever reach the region. And contact-level reports in Insight are filtered the same way. Oracle recommends starting with two or three categories at most and giving the administrator group every label so somebody can still process the whole database.
Email groups per region or language
Subscriptions are regional too. Most global teams create email groups per region or language, each with its own header, footer and subscription pages so a French contact sees French choices on the Subscription Management Page and a Japanese newsletter has its own opt-in. Email groups also carry defaults for the emails sent through them which is a quiet way of keeping regional footers and legal text consistent.
Protected templates and shared assets
Brand consistency across regions comes down to templates. Protected templates and locked blocks let the central team decide which parts of an email a region can change and asset permissions that leave regional groups with View on the shared templates stop anyone saving over them. Shared content and dynamic content do the same for legal footers and address blocks that vary by country.
Insight folder security
For reporting Insight folder security lets administrators give each region access to its own folder of reports and dashboards within the Company Shared folder, with contact security already filtering the rows.
Where the setup needs help
Set all of that up and you have an instance where a country marketer can log in and only see their own world. It is a real achievement and it has costs that show up over the following year.
Every regional marketer is an Eloqua user
They need a Marketing Platform license which is finite, a seat in the right groups and enough training to use the canvas or at least the simple email campaign without hurting anything. Regional teams turn over. The training is never done.
The controls govern access and nothing after it
Contact security stops the DACH team emailing France. It doesn’t stop them emailing all of DACH with something meant for a hundred people. Asset permissions stop them editing the global template. They don’t stop them picking the wrong one, or writing a subject line that would never have passed brand review. Permissions are a fence around the instance. Policy is about what happens inside the fence.
Simple sends skip approvals
The campaigns regions send most are single emails and campaign approvals can’t be applied to simple email campaigns. Where approvals do apply they are one global workflow with named individual reviewers which doesn’t fit an organization where each country has its own approver.
Templates drift
Regional teams have real needs that global templates don’t anticipate: a longer legal footer in Germany, right-to-left layout, a different date format. The central team either builds every variation or lets regions improvise and improvisation is how an instance ends up with two hundred templates and a brand that looks different in every country.
Regions reach the same contacts
Key accounts are global. A contact at one of them belongs to a region, a brand and corporate at once and each sends within its own rules. The sum is more email than anyone intended which is a frequency problem that no single team can see from where it sits.
Data quality fragments
Every region uploading its own lists means every region making its own mapping decisions, with country values in local languages and consent recorded six ways. The central team cleaning it up afterwards is the hidden cost of letting regions in.
Central Ops loses the picture
Once regions build their own campaigns the central team no longer knows what went out, to whom or how it did without going looking. Reporting across regions means building it in Insight with an Analyzer license. If some regions run their own instances for legal reasons, the picture splits again.
Which is why most global teams in practice end up somewhere uncomfortable: regions have access on paper, central Ops still builds most of the campaigns to be safe and everyone is unhappy with the turnaround.
Giving regions self-service that holds
The teams that have made regional self-service work haven’t done it by finding a better permission. They have changed what a local marketer is asked to do. Instead of a login to the platform the region gets a set of guided paths for the campaigns it actually runs, with every regional decision that can be made in advance made in advance.
Campaign Launchpad is built for that. Marketing Ops creates wizards for the campaign types regions run: a product update, an event invitation, a newsletter, a list upload. The region is a choice inside the wizard rather than a login. That choice does a lot of work:
- It picks the templates offered so each region gets its layout and its legal footer with everything else locked.
- It limits the audiences the marketer can choose to the region’s lists and validates any uploaded file against the rules Ops set for that region.
- It names every asset by your convention, with the region, country and language in the name.
- It routes approvals to the right people. A regional marketing manager can approve first and central Ops second, or the other way round and an internal send can skip both.
- It decides the sender, the email group and the tracking values without showing them.
The local marketer never opens Eloqua so there is no license to find, no security group to audit and no training beyond the wizard itself. Central Ops keeps the templates, the rules, the record and the queue. When a regional campaign needs something the wizard doesn’t cover, Launchpad hands that step to Ops with the request and the conversation attached and a deadline on it so the exception is handled without opening the gates.
Reporting comes back to the region per campaign and Ops sees every region’s campaigns broken out by campaign, template and sender. One Launchpad account covers every region whether they share one instance or run several, on Eloqua, on Marketo or both.
Several of the teams using Launchpad describe exactly this situation. Omron uses it to let country organizations send their own email on the central Eloqua database and subscriptions. Ingram Micro’s country teams send from templates the central team built. At 3M, regional teams send 120 to 200 campaigns a month through it, on brand, with the central team no larger than before. For Marketo instances the equivalent setup with workspaces and partitions is covered in its own guide.
Frequently asked questions
- Should each region have its own Eloqua instance?
- Usually not. Separate instances mean separate databases, separate unsubscribe lists, separate templates and separate integrations and a contact who deals with two regions becomes two records. Most global companies run one instance and separate regions inside it with security groups, business units and contact security. Separate instances make sense when regions are separate legal entities with separate data obligations and then something has to administer and report across them.
- How do I stop a country team in Eloqua seeing contacts from other countries?
- Contact security, Oracle’s label-based access control. Create a label category such as Region, assign labels to each regional security group and run a label assignment program that labels contacts as they enter the database. Members of a group then only see contacts carrying their label, segment counts reflect only those contacts and any campaign a regional user activates only admits contacts they can see.
- What are Eloqua business units for?
- Business units categorize users by brand, division or line of business so that members of a unit have access to the assets and data in that unit. They are configured against security groups under Settings and are included in the Standard and Enterprise trims. They separate what users can open; contact security separates which contacts they can reach.
- How do regional teams handle subscriptions and languages in Eloqua?
- With email groups. Many global teams create email groups per region or language, each with its own header, footer and subscription pages so the Subscription Management Page shows contacts the choices that apply to them. The guide on Eloqua subscription management covers how email groups work.
- How do you keep regional emails on brand in a shared Eloqua instance?
- Protected templates and locked content blocks, with the Manage Templates and Manage Blocks permissions held centrally so regions use templates but can’t change them, plus asset permissions that leave regional groups with View on shared templates. It has to be done for every template every region can reach and it governs the email, not the audience or the send settings.
- Why do regional campaigns in Eloqua end up over-emailing contacts?
- Because each region’s campaigns check their own rules and nothing sees the whole. A contact who belongs to a global account hears from several regions and from corporate, each within its own limits. The Email Governor guides on frequency limits cover holding every campaign to one cap across teams.
- How does Campaign Launchpad support regional teams?
- Ops builds wizards for the campaigns regions run, with the region, country, language or business unit as a choice that drives the naming convention, the templates offered, the audiences available and the approvers. Local marketers run the wizards without an Eloqua login. Approvals can include a local manager and central Ops. Results are reported per campaign, template and sender and one Launchpad account covers every region whether they share one instance or run several on Eloqua and Marketo.