When implementing Eloqua, there were 3 challenges made clear :
1. Email address was the only unique key to be used for each individual contact, mainly coming from our CRM, SalesForce or as we all call it SFDC.
2. There is a 1 to 1 relationship between each contact and an account
3. However, we realized our contacts database was composed for about 30% of duplicate contacts based on email address and that we had a bunch of contacts linked to multiple accounts.
Why ? --> Indeed our CRM was built in a way that allowed creation of contacts with the same email address, to allow for example :
- an firstname.lastname@example.org contact to be shared accross branches of a big account. Say your info@ contat would be linked to 5 different local branches of a supermarket chain
- unfortunately allow a email@example.com to be created once with a certain role "consultant" for company A and "sales" for company B and so on ...
2 years of SFDC growing data was going to have hard consequences on the CRM and we needed a quick fix because it was having hard consequences on marketing campaigns as well: the ASCIIbetical merging of duplicates via the CRM sync was mixing ALL of the data up ! Think wrong personalization, wrong segmentation, wrong data overall !
SO the goal became this : getting ALL contacts in the Eloqua DB without any merging of data ! That way we could at least segment and personalize correctly until we found a long term solution to fix the data modeling between Eloqua and our SFDC set up
HOW we did it :
1. Obviously, first we need to have a SFDC integration. We're using the out-of-the-box Cloud to Cloud connector built by Oracle with SFDC.
2. Built the first "Get Contacts" auto sync that will bring a "winning contact" from SFDC into the standard Contacts in Eloqua. That winning contact is flagged in SFDC following a scoring logic : the more complete, clean, recent contact gets scored the highest compared to all other contacts sharing that same email address and gets the flag Master Marketing Contact = True
The "Get contacts" auto sync is using an advanced filtering in our case, in which we included our winner filter "Winning contact."
Then we need the "secondary contacts" meaning the duplicates to also be included in the Eloqua DB without merging ! Thus we created a second Get Contacts - Secondary auto sync for this.
This auto sync actually brings in all contacts including the winning contacts and the "secondary" duplicate contacts.
That auto sync adds data cards to a CDO called "Contacts - Secondary". Make sure to use SFDC contact ID as unique identifier and email address as a link with Contacts.
The creation/modification of records by this auto sync triggers a program :
This program makes sure that only "winning" contacts are in the standard Contacts object and "secondary" duplicates stay in the CDO.
The resulting duplicates in the CDO "Contacts- secondary" linked to the winning contact :
This allows us for example to segment correctly based on all contacts including duplicates :
How we make sure that we have cleaned up correctly :
1. Check amount of contacts with "Winning contact" = True in both systems is the same
2. Take a random sample of contacts to check data in both systems, using the SFDC contact ID
Now we are able to :
- not use bad data to segment, like job titles for example
- keep the relationship if a contact is linked with multiple accounts
- personalize correctly to a certain extent
- for specific needs like legal communication or operational communication where every account needs to receive communication, we are able to confirm that they received it even though we have 1 contact for multiple accounts.
This is an example of how you can fix relatively quickly and with very low consequences on your CRM if you have a lot of contact duplicates that accumulated. Of course there are better ways. Our SFDC has been set up for stand alone use 2 years prior to Eloqua implementation. So if you are about to set up a CRM integration with Eloqua, do your home work and start a data & modeling audit to see how it fits together !
Some other ways we could have achieved this include :
- merging contacts (wouldn't work for us for numerous reasons short term)
- using the 1 to many accounts relationship in SFDC using the "Secondary Account" relationship (tutorials available online)
- switching the unique key from email to another field (not recommended by Oracle)
So if you're looking for a short term solution and this one suits your needs, holpe it helped you out !