Discussions
Merge two Contact Records
Comments
-
I cannot comprehend how this is not possible in Eloqua. Pardot can merge records in a few clicks. Not having the ability to merge contacts is creating problems for us.
Hi Chris,
Give us more details on how you would like this to look? Are you selecting 2 different contacts and merging them? Is there something programmatic happening that is identifying that the contacts look alike?
Thanks,
Aly
-
This woul be an amazing feature if it gets implemented. It's a real issue of ours as well at the moment.
I would like to know more details about this. What exactly are you looking for here to help merge the contacts and how would you identify the 2 different contacts?
-
Hi Chris,
Give us more details on how you would like this to look? Are you selecting 2 different contacts and merging them? Is there something programmatic happening that is identifying that the contacts look alike?
Thanks,
Aly
Aly, if I may, here is what I propose could be a series of events to take place if in the future Eloqua allows the merging of two contacts;
1. Either use higher ASCII method of field merging exactly like occurs when you upload two duplicate rows anywhere into Eloqua to perform the merge, "update if blank" method (pick the "winner" by email address), or create a new interface to allow for more advanced field merge/replace/updates.
2. Merge all activity data - everything from form submits and website visits to campaign and program history. (Basically merge all entries of the Marketing Activity back-end Eloqua table, replace the key field with the "winner" email address if required.)
3. If both duplicates exist in the same shared list(s), keep the winner by email address, remove the other.
4. Any linked custom object records would maintain their mapping to the "winner" of the merge, the Email Address field if defined in the CDO should be updated to reflect the address of the "winner" of the merge.
5. Roadmap a new canvas step that will automatically perform the merge provided you configure the match criteria and the method of merging, make it clear who the "winner" will be.
6. Run lead scoring on the new "winner".
7. Optional - add to program canvas if doing the merge manually and not through #5 above.
-Alexander Huzar
-
How can a simple "Merge Contacts" functionality not exist on Eloqua? This is supposed to be the pinnacle of marketing automation. Every other marketing automation tool and CRM has this. The biggest issue in managing data is duplicates. Eloqua doesn't have what I would consider a pretty rudimentary functionality?
-
Bump. This is becoming a real problem now. Duplicates are tying up sales reps' time and creating a bad image for the org as two people try to talk to one lead. When we deduplicate, we simply pick a winner and it's always the one with the non-personal email address. Unfortunately, in Eloqua this means that by deleting the duplicate, we lose visibility on any of the activities seen in Profiler (e.g. person registers with Gmail, attends with their corporate email).
Our current work-around involves using match rules to identify duplicates and then a form submit app step that writes the most recent campaign information to the primary record and sends it instead of the duplicate through integration. The only issue with this is that historical campaign responses are not written over to the primary record - architecting a solution for this is possible, but it would be very convoluted and would involve CDOs (representing campaign responses) writing to the contact, then sending that contact through a program that writes that campaign info to the primary record while simultaneously clearing out that same info in the CDO(s) of the duplicate. Rinse and repeat until all CDOs mapped to the duplicate are blank.
We need a merge contacts step for program canvas or match/dedupe rules. The amount of time this saves when you think about it in terms of employee work-hours, this can be applied to re-invest into Eloqua or wherever else that's required.
-
Bump. This is becoming a real problem now. Duplicates are tying up sales reps' time and creating a bad image for the org as two people try to talk to one lead. When we deduplicate, we simply pick a winner and it's always the one with the non-personal email address. Unfortunately, in Eloqua this means that by deleting the duplicate, we lose visibility on any of the activities seen in Profiler (e.g. person registers with Gmail, attends with their corporate email).
Our current work-around involves using match rules to identify duplicates and then a form submit app step that writes the most recent campaign information to the primary record and sends it instead of the duplicate through integration. The only issue with this is that historical campaign responses are not written over to the primary record - architecting a solution for this is possible, but it would be very convoluted and would involve CDOs (representing campaign responses) writing to the contact, then sending that contact through a program that writes that campaign info to the primary record while simultaneously clearing out that same info in the CDO(s) of the duplicate. Rinse and repeat until all CDOs mapped to the duplicate are blank.
We need a merge contacts step for program canvas or match/dedupe rules. The amount of time this saves when you think about it in terms of employee work-hours, this can be applied to re-invest into Eloqua or wherever else that's required.
Hi Alex,
We are having similar issues and we spend alot of time manually managing this issue. We too also have a program that can identify the duplicates but merging is manual and time consuming. A merge feature would be great.
-
I'm not sure this will work - if a contact forwards a college an email they will be merged with the original's contact.
If a contact forwarded the email to someone , We would be able to see this in reports.
-
If a contact forwarded the email to someone , We would be able to see this in reports.
Correct. The activity is linked to the VISITOR and not the contact. The visitor may or may not be yet linked to an existing Eloqua contact. Either way this shows up in reporting.
This gets tricky for emails because on there are two things - a tracking pixel and all hyperlinks contain the recipient ID.
Tracking pixel - "downloading" the pixel is associated with the IP address of an individual. If a contact already exists that has a visitor (cookie) that has an IP address matching the current IP used for the open then a direct association is made. If it's opened by an IP address that's not a corporate location (i.e. more than one visitor from same IP) AND if there's a visitor linked to that IP address then there's a high likelihood (algorithms get run here) that this visitor will get the association instead of the contact wo whom the email was supposed to have been sent to. This influences the :likely forwarded" metric.
Recipient ID - this is the ?elq=1234567890*** query string that Eloqua generates. It is a unique code per email per email send per contact. Sending the same email twice to the same person even in a short period of time will always generate a different recipient ID. When you forward an Eloqua email to someone, of that person does not already have an Eloqua cookie, by clicking that hyperlink it will tell Eloqua to drop a cookie and associate it to the contact to whom the email was destined to. 99% of the time this creates profile confusion where that recipient will start clicking on other things and go on web pages where all those metrics will be incorrectly associated to the recipient of the email. Long story short - DON'T EVER FORWARD ELOQUA EMAILS!!! Nothing good will ever come from this. Train your staff to never fill out forms on behalf of clients or anyone else as in my experience this is where the majority of profile confusion comes from.
Visitor-contact association hierarchy - there is a hierarchy of events that can take place that can cause Eloqua to remap a visitor (cookie) from one contact to another. IP-based association is among the lowest priority association possible (you browser websites without filling out a form, then view an email and download the tracking pixel - the dropped cookie gets associated to the IP address used to download the tracking pixel and if no other visitors came from that IP then eventually Eloqua will make the association). Next is the recipient ID - if you don't have a cookie and you click through an email sent to you from Eloqua or was forwarded from someone else, when you land on the web page Eloqua immediately drops a cookie and associates it to the contact to whom that recipient ID and email are destined to. Next is form submits - if a form is configured to map form fields to contact fields and Email Address is mapped, if you have profile confusion with enough form submits (and possibly other activities) Eloqua will re-assign the visitor and the past 2 weeks' worth of activities to the contact with the email address you've been using on the form submits. Finally at the very top of the hierarchy there is the API-based cookie-contact association. I'm not quite sure how this works and under what scenario, but I know for a fact that this exists (thanks to @Nelson Ng-Oracle) and is at the top.
Summary:
-Don't forward emails
-Forwarded emails have a good chance to shop up in reporting as forwards
-Profile confusion can self-correct in some cases, especially if eventually a form is submitted with an email address at least once along with other activities (just one form submit will not do, there needs to be more)
-When a visitor profile (cookie) is reassigned to another contact, only the past 2 weeks' worth of activities are reassigned and anything older stays behind on the original contact.
-
Totally agree that this is something Eloqua needs to explore, especially since many people sign up with personal email addresses when using LinkedIn etc. So if we want to plug apps like LinkeIn Campaign Manager into Eloqua and gather these form submits, we should be able to merge records for a more effective campaign and experience to database as well.
-
It seems like this FR has been languishing. Is there an app in the Cloud App Marketplace that can reliably merge contacts?
Dedupe rules can delete duplicate contacts but this is very risky - one slip in here and you could literally wipe out your entire database with no backup. And anyway this is only available to those who have purchased that Tier. This should be core functionality.
-
It seems like this FR has been languishing. Is there an app in the Cloud App Marketplace that can reliably merge contacts?
Dedupe rules can delete duplicate contacts but this is very risky - one slip in here and you could literally wipe out your entire database with no backup. And anyway this is only available to those who have purchased that Tier. This should be core functionality.
In our view, a merge would constitute the consolidation of everything a sales rep can see within Profiler, all custom object records where the "mapped contact" is the merged contact" (Email Address field can remain the same). To simplify, we need a true, "real" merge where everything a contact is associated with, be it a field value, activity, another table/object, campaign, program, etc. all need to take into account that the two contacts are now one and the same.
For more complex things like two contacts on one shared list where the contacts become merged, the contacts on the list must also be merged (instead of showing up as duplicate entries).
For where two contacts exist on the same canvas where it is not allowed to have multiple instances of the contact simultaneously on the canvas, perhaps a validation screen can be shown explaining where the "roadblock" exists and any theoretical automation steps that would merge contacts would throw an error that can be used by the error handling option of app steps for example. I think this would be the only wrinkle in an otherwise seamless merge process that is an out of the box standard feature in other platforms like Marketo and Pardot, e.g. https://docs.marketo.com/display/public/DOCS/Find+and+Merge+Duplicate+People. This may, perhaps, be possible thanks to more direct Marketo<-->SFDC integration (which is not necessarily a good thing), but it's still an API call at the end of the day, one that can be replicated line by line in Eloqua.
Post edited by Unknown User on -
It would be a nice feature but would still recommend perform merge on the CRM side.
-
It would be a nice feature but would still recommend perform merge on the CRM side.
If someone submits a "request contact" form with their work email and then submits a survey with their personal email, when you deduplicate in the CRM what results is a winner and loser and the losert syncs back to Eloqua as a "deleted" record and with a default setup all you do is clear out the CRM ID, but you won't delete it from Eloqua and it won't merge. If you delve into the mechanics of merging and see how it's possible for the CRM to "tell" Eloqua that there's been a merge, you'll realize how limited you are in terms of data and being able to action on said data and why this isn't a solution. The form submission data from the example survey submission will not ever merge (edit: you need to put yourself into the shoes of people who use this data - sales reps who use Eloqua Sales Tools like Eloqua Profiler who look at form submits). Also, we qualify Eloqua contacts before they get created as leads, so we perform deduplication in both systems in different scenarios. For this reason we still really need the Eloqua-side solution.
Post edited by Unknown User on -
Aly, if I may, here is what I propose could be a series of events to take place if in the future Eloqua allows the merging of two contacts;
1. Either use higher ASCII method of field merging exactly like occurs when you upload two duplicate rows anywhere into Eloqua to perform the merge, "update if blank" method (pick the "winner" by email address), or create a new interface to allow for more advanced field merge/replace/updates.
2. Merge all activity data - everything from form submits and website visits to campaign and program history. (Basically merge all entries of the Marketing Activity back-end Eloqua table, replace the key field with the "winner" email address if required.)
3. If both duplicates exist in the same shared list(s), keep the winner by email address, remove the other.
4. Any linked custom object records would maintain their mapping to the "winner" of the merge, the Email Address field if defined in the CDO should be updated to reflect the address of the "winner" of the merge.
5. Roadmap a new canvas step that will automatically perform the merge provided you configure the match criteria and the method of merging, make it clear who the "winner" will be.
6. Run lead scoring on the new "winner".
7. Optional - add to program canvas if doing the merge manually and not through #5 above.
-Alexander Huzar
Update: I was just reading the Marketo merge duplicates documentation and there they state:
"When merging people, if the losing person has a Marketo custom object, it will not get re-associated to the winning person. Please re-parent the custom object prior to performing the merge."
My $0.05 - When Eloqua implements a merge feature and if they automate the remapping of custom object records to the winner they will actually be a step ahead of Marketo and call them out on this. I think this is an example of the false information that can lead to the proverbial "death by 1,000 cuts" where what you think is true is just lipstick on a pig. Marketo only appears to be an iPhone-like system that's easier to use and ticks all the checkboxes of comparison charts, however it's easier to use because, like an Apple product, there's less you can actually do with it and thus through brute force it's "easier" to use and even your grandma can use it. I think that Oracle Eloqua needs to go out on a campaign and directly target Marketo to dispel all the myths and plain wrong "facts" (fake news) and how Marketo does not compare to Eloqua, never has and probably never will. I know of one enterprise company that switched to Marketo and within a month their entire marketing team (6+ senior Eloquans) quit because they couldn't do even 1/4 of what they were doing with Eloqua because their leadership bought into the Marketo hype. It's not enough to show off cool Eloqua features alone or what's upcoming (this is merely an expectation rather than a bonus in this day and age of 2018 going into 2019). At this point I think it's important to win the "hearts and minds" of people and help them separate fact from fiction, but we really need help from Oracle to do this!
-
Update: I was just reading the Marketo merge duplicates documentation and there they state:
"When merging people, if the losing person has a Marketo custom object, it will not get re-associated to the winning person. Please re-parent the custom object prior to performing the merge."
My $0.05 - When Eloqua implements a merge feature and if they automate the remapping of custom object records to the winner they will actually be a step ahead of Marketo and call them out on this. I think this is an example of the false information that can lead to the proverbial "death by 1,000 cuts" where what you think is true is just lipstick on a pig. Marketo only appears to be an iPhone-like system that's easier to use and ticks all the checkboxes of comparison charts, however it's easier to use because, like an Apple product, there's less you can actually do with it and thus through brute force it's "easier" to use and even your grandma can use it. I think that Oracle Eloqua needs to go out on a campaign and directly target Marketo to dispel all the myths and plain wrong "facts" (fake news) and how Marketo does not compare to Eloqua, never has and probably never will. I know of one enterprise company that switched to Marketo and within a month their entire marketing team (6+ senior Eloquans) quit because they couldn't do even 1/4 of what they were doing with Eloqua because their leadership bought into the Marketo hype. It's not enough to show off cool Eloqua features alone or what's upcoming (this is merely an expectation rather than a bonus in this day and age of 2018 going into 2019). At this point I think it's important to win the "hearts and minds" of people and help them separate fact from fiction, but we really need help from Oracle to do this!
There are things you can do in Marketo but you can not do in Eloqua. You can merge duplicated contacts and you can select the winner manually. its one of the good features in of Marketo. After 5 years in MA ( 3 years in Marketo and 2 years in Eloqua, consultancy and client side) I would say depending on the organization I would recommend different platform.
You can do more in Eloqua but you need set of skills to be able to do it. In Marketo its easier to achieve what you need with some limitations.
-
It is good idea, nice if Eloqua provides this feature in upcoming releases.
-
It is good idea, nice if Eloqua provides this feature in upcoming releases.
"For future consideration" is a nice way of saying "probably never".
-
"For future consideration" is a nice way of saying "probably never".
@Devon Guerrero It actually means we are considering it. We've done investigation and created a list of requirements and are looking where to prioritize it on our roadmap.
-
@Devon Guerrero It actually means we are considering it. We've done investigation and created a list of requirements and are looking where to prioritize it on our roadmap.
@Thamina Christensen-Oracle do you know if the team has included merging the activity data like form submits as a part of this? This is very valuable to our team of 400+ Eloqua Sales Tools users (Profiler/Engage). Sometimes they need to make notes that a duplicate exists because the data on the duplicate is important. For example, someone registers for an event with their corporate email and includes things like dietary restrictions, then they submit a survey with a list of their current vendors/products and request to be contacted with their Gmail email. We would need to keep both sets of data, ideally under one merged record.
-
@Thamina Christensen-Oracle do you know if the team has included merging the activity data like form submits as a part of this? This is very valuable to our team of 400+ Eloqua Sales Tools users (Profiler/Engage). Sometimes they need to make notes that a duplicate exists because the data on the duplicate is important. For example, someone registers for an event with their corporate email and includes things like dietary restrictions, then they submit a survey with a list of their current vendors/products and request to be contacted with their Gmail email. We would need to keep both sets of data, ideally under one merged record.
Yes we have explored merging activity data as part of this.
-
Seeing as this was posted on Jul 16, 2015 4:04 PM I am wondering if you can give us an update on whether this has made any headway at all or if its still "For future consideration"?
-
Seeing as this was posted on Jul 16, 2015 4:04 PM I am wondering if you can give us an update on whether this has made any headway at all or if its still "For future consideration"?
Hi @ThomasWalsh,
The idea was posted in 2015 but the status of "For Future Consideration" was only changed recently. So yes we are making headway on this idea.
Cheers,
Thamina
-
Hi @ThomasWalsh,
The idea was posted in 2015 but the status of "For Future Consideration" was only changed recently. So yes we are making headway on this idea.
Cheers,
Thamina
@ThomasWalsh - @Thamina Christensen-Oracle is just awesome and she always gets things done and properly at that. I'm really quite happy knowing she's on this!
-
Yes we have explored merging activity data as part of this.
Thanks for the update!! I'm excited.
-
Glad to hear this feature is finally getting some attention. Now that the responsive email and landing page editors have been implemented, this is the only other major function missing from the platform that other competitors have. Will finally make Eloqua an top tier solution. Thanks guys.
-
@Thamina Christensen-Oracle Awesome! Exciting times ahead with this getting some attention!
-
A work around that I have used in a similar situation is by using two forms to do the following:
1. Create and use the first form to look up the contact's current email
2. Create and use the second form:
- Pre-populating the contacts current email address, first name, last name, company etc. as read only fields
- Add a field for the new email address
- Add the following from processing step to change the email address to the new email address.
Suggestions
Create a field in the contacts record to capture the email address before the change
According to your needs you may want to capture the submission in a CDO as a backup.
-
A work around that I have used in a similar situation is by using two forms to do the following:
1. Create and use the first form to look up the contact's current email
2. Create and use the second form:
- Pre-populating the contacts current email address, first name, last name, company etc. as read only fields
- Add a field for the new email address
- Add the following from processing step to change the email address to the new email address.
Suggestions
Create a field in the contacts record to capture the email address before the change
According to your needs you may want to capture the submission in a CDO as a backup.
That's not a merge. This will fail if a contact with the "new" email address already exists in the same way that "Modify Lead/Contact Email" autosynchs will fail if the "new" already exists. When these fail, no one knows and it's not possible to notify anyone that this failed - because the autosynch itself was successfully run. You can configure the form processing steps to do something different if the "new" email address already exists, but you won't be able to differentiate success versus failure unless you have just one single form processing step or a convoluted system using a control field to indicate that the first processing step actually ran (first step = write a "1" into a control field conditionally if "new" email address does not exactly match contact field "Email Address" - indicating no contact already exists with the "new" email address). Your suggestion can only work to change the email address, it will never work to merge anything. If, perhaps, you're trying to describe a system of pre-populating values for a user using their current email address as linked through the cookie and then when they hit submit it changes the email address, then you'd have to retroactively do this to all the forms in your instance and multiply that by however many landing pages those forms are found on. For us, we're on form ID 1768 - multiply that by multiple landing pages each - that's the amount of work that would need to be done to implement this work-around, a mechanism that does not and cannot account for a scenario where the "new" email address already exists. This is not realistic and what we gain from this does not compensate for the months worth of work required to implement.
Finally, there are scenarios where it's not desirable to merge the data so if you attempt to do this automatically with every form submit you will be cross-contaminating data, you cannot possibly be compliant with GDPR and other regulations.
-
Yes we have explored merging activity data as part of this.
Will activity data merging be included? Otherwise merging would be quite pointless.
-
Will activity data merging be included? Otherwise merging would be quite pointless.
This has been clarified...
Thamina Christensen-Oracle 1-Aug-2018 3:13 PM (in response to Alexander Huzar)
"Yes we have explored merging activity data as part of this."
