Subscribing to EXM Email: How do you manage multiple contacts using the same computer?

Question

We are currently working on a project, where we implemented a registration process using WFFM, EXM and Engagement Plans. We are facing one specific issue, regarding the contact identification with EXM. Before giving you the concrete issue and technical details, I would like to provide some context, by making a use case:

Use case

A married couple is sharing one device for surfing the web. The wife is registered on OurWebsite and is currently logged in. Her husband is fascinated by OurWebsite and would like to register too. His wife is logging out and then husband is using the registration form to register as a new user, inside the same browser window which his wife used before. He is sending the registration form and an email with a confirmation request is being send to his email address (wife and husband have different email addresses). He clicks on the confirmation link inside the email and is being redirected to OurWebsite, where he is now able to log in, with his newly created user credentials.

Implementation

1. WFFM Save Actions are used to: Create and disable a user | Update the contact details | Load the contact into an engagement plan.
2. The engagement plan is used to: Send the EXM Standard Message, which contains the confirmation mail | Enable the user, which is related to the contact, when a goal is triggered on the opt-in page for the contact | delete the user, when the goal is not triggered after 24h

Issue

Up until the point, where the email is being send, the process seems to work fine. But when the visitor is being redirected to OurWebsite the current contact may be the wrong one or two contact with different identifiers are being merged, since the contact of the current session is still identified to the wife. In the end, the triggered goal is not registered for the contact, which relates to the newly created user and the user is not being enabled.

Questions

We haven't investigated the issue to the smallest detail yet, but are facing three questions and hope that any of you could share some insight with us:

1. With the usage of EXM and Engagement Plans we are heavily relying on contacts and the relation from contacts to the user. Are contacts suitable for such a process?

We are asking this especially with the thought in mind, that since we do so, we are expecting a 1:1 relationship of contact and user. We are not sure, if we are supposed to use contacts in this way and if our approach is the "Sitecore way" to implement such a process.

2. Now that we are already this far in the implementation, what is "the best way" of solving our issue?

We are thinking of adding a step before the Sitecore.EmailCampaign.Cd.Pipelines.RedirectUrl.IdentifyContact processor, where we would abandon the current session or release the current contact, if the current contact is already known and the identifier does not match the identifier, which is proposed by EXM.

Another possibility would be to work around, by passing custom parameters through the email and catch them later on to assure the success of the registration process (probably without engagement plans).

3. What exactly happens internally, when a contact is already known for a session and is being identified again with another identifier?

Further information

Probably relevant is, that we are following the WFFM standard way to identify the contacts. Identifier = {Domain}/{UserName}, UserName = Email.

Also, we are working with Sitecore 8.2 Update-1 and EXM 3.4.0.

I am already very thankful for help and insight, that you may provide on this topic. If you would like to have any further information, please let me know.

Answer 1

This is a pretty complex issue and question, but you have broken it down excellently to allow me to attempt and pinpoint the issue. I believe the issue you are suffering from is what I have called "The Library Computer Problem"

Question 1

With the usage of ExM and Engagement Plans we are heavily relying on contacts and the relation from contacts to the user. Are contacts suitable for such a process?

There is no hard line relationship between a User and a Contact. Let's break that down a bit. However, EXM and Engagement Plans can ONLY utilize Contacts and not users. Therefore, contacts are the correct object to use.

What is a User?

A USER is an authenticated account residing in the .NET Membership Database or other Federated Authentication service. Users are typically bound to a domain such as sitecore, extranet, or other configured domain in Sitecore. A user typically has a Profile (ASP.NET Membership Profile) associated with the account that can store various values. The default structure of a username is in the format of domain/username.

What is a Contact?

A CONTACT is a marketing term identifying a visitor to the website. A contact record and associated ID always exists for a visitor on the browser. There are primarily two types of Contacts: an Anonymous Contact and a Known Contact.

Contacts have Facets that provide a place to store Contact information, like Personal Information (name, surname, birthday, gender, etc), Contact Street Addresses, and Email Addresses. The Contact model can also be extended to store custom contact data.

Sitecore personalization can be used to read information from the contact facets for various personalization rules and List Segment Conditions can also be created to automatically create Contact Lists based off of facet information.

The difference between the two types of Contacts is that the visitor has provided some sort of identifying information that allows the site to programmatically identify a contact with some tangible and unique identifier. The most common types of identifiers are Email Addresses and Usernames.

Contacts are stored in Session during the visitor's visit to the website via a cookie. One a visitor leaves the site, during the SessionEnd() process, the contact, any contact information, and interaction tracking information is moved from the session to the Mongo DB (or xConnect Collection). From there, the xDB Processing role of Sitecore will process the Mongo/xConnect Collection and move the information to the Sitecore Analytics index and the Reporting database.

The cookie persists past the visit so that the Contact, upon coming back, can continue to add visit information to the interactions. This cookie CAN be manually reset back to anonymous contact record by forcing both the visit to end and the Session to be abandoned.

Tracker.Current.EndVisit(true);
HttpContext.Current.Session.Abandon();

The code above ends the visit and invalidates the cookie. Secondly, it forces the Session to end and immediately writes data to Mongo via the EndSession() process.

Is there any relationship between a User and a Contact?

There is NO relationship in Sitecore, xDB, or xConnect that associates a User to a Contact. Any such relationship has to be done manually by use of identifiers and even then the application has to maintain that relationship. It is completely plausible that somehow a single logged in user might actually have two contact id's or 1 contact id could somehow be used on two different users. It is up to the custom application to maintain any type of relationship.

Question 2

Now that we are already this far in the implementation, what is "the best way" of solving our issue?

To really answer this, requires us to break down the Use Case above.

Breaking Down the Use Case

A married couple is sharing one device for surfing through the web. The wife is registered on OurWebsite and is currently logged in.

The currently known contact is the Wife's and because she is logged in, and making assumptions that you have identified the contact as a Known Contact, then any interactions taken will be on this contact id.

Her husband is fascinated by OurWebsite and would like to register too. His wife is logging out and then husband is using the registration form to register as a new user, inside the same browser window which his wife used before.

Unless you are specifically clearing the contact cookie, the Wife's cookie remains after she logs out. When the husband continues browsing, he is doing so on the known contact id, which is the wife's. When the form is registered, even though the husband is creating a new user, the existing wife's contact id will be utilized through EXM. I believe this is where the root issue is occuring.

He is sending the registration form and an email with a confirmation request is being send to his email address (wife and husband have different email addresses).

EXM uses the contact id that was associated to the engagement plan, and therefore when EXM dispatches the message, the URL parameters used in the link contained in the email include the wife's contact id.

He clicks on the confirmation link inside the email and is being redirected to OurWebsite, where he is now able to log in, with his newly created user credentials.

Because the click is associated with the wife's contact id's, I'm assuming nothing happens, and thus doesn't enable the contact as stated in the issue.

Possible Solution

I believe that a possible solution to this issue is to force the Sitecore Analytics Tracking Visit to End, invalidate the cookie, and then end the session when the user performs a LOGOUT function. This will reset the contact cookie to an Anonymous contact so that the next user will have a clean and anonymous contact record to work with.

Question 3

What exactly happens internally, when a contact is already known for a session and is being identified again with another identifier?

When a Contact is being Identified, internally the MergeContact() method is run. This is an important function because it merges any anonymous interactions and contact information with a Known contact record. If no Known contact exists, then a NEW contact id is created, marked as a Known Contact, and the old Anonymous contact is killed off. I say it like that because in code Sitecore calls the two different contact id's the dying contact and surviving contact.

However, if the current contact id is a KNOWN contact, and you are identifying against a different identifier which will call up a different KNOWN contact id, then no data is merged to the "surviving" contact and simply the cookie is updated to reflect the most recently identified contact.