Hi @dargelies 

Identity resolution in Amplitude is currently based on just the device id / user id. I don’t think it will work based on just email and phone. If these are user properties stored on an user in Amplitude, I would :

• reconcile the email and phone user properties and associate the user_id if applicable.
  • if all attendees of this webinar are using your app with an assigned user id, you should have a 100% coverage here. If not, the non user attendees will be anonymous users
• create an event for the webinar attendance with the appropriate ingest schema and attributed to the correct user_id

Hi Saish,

Thank you for the reply. Yes, I’ve tested this and Amplitude does not reconcile based on just email and phone number.

The users are not in our system and do not have a user id. They are leads. We don’t believe it’s a good practice to create a user in your database for every lead that happens to show some interest in your product (consider every person that lands on your website). We create them after they’ve followed through with the intent to become a customer. Then it makes sense to create a user in our database and assign an ID to them.

From what I understand the non-user attendees are not created as anonymous users in Amplitude. They cannot be ingested at all, because there is no device ID or user ID associated with them. The entire S3 integration fails. I believe they should be created as anonymous users in Amplitude and then reconciled when they become identified users at the conversion event based on their deterministic matching identifiers: email and phone number.

Am I understanding that Amplitude is not capable of reconciling users when given deterministic matching identifiers? If so this seems like a pretty large gap in the functionality of a CDP, this blog post discusses how Amplitude uses deterministic identifiers for reconciliation.

Hi @dargelies  - apologies for the late reply but wanted to make sure you got an answer. Amplitude does indeed use deterministic identifiers for resolution. You may have noticed in this article that we merge on user ID only. Unfortunately that means that unless you are willing to set phone number or email as the “user ID”, users will remain anonymous (and unmerged).  However, you can hash the email and set it as device ID, if you do not want to set email as user ID, and have the phone number and email as user properties. This will require you to add another column to your CSV but should solve your problem.

A consistent hash will allow for anonymous behavior to stay merged (say if they attend 3 different webinars). This approach will also allow you to maintain consistency with your internal systems and not assign a true User ID until they follow through. 

Hope this helps!

Hey @audrey.xu thanks, interesting solution here. If we use a solution like this, we’d just need to be able to consistently generate the same hash when we’re identifying the user to associate those previous anonymous events with the recently identified user. I’d assume we could also do the same with just phone number as we may just have phone number for some of these sources. Tactically does this just mean that when we do finally call identify that we’ll call it several times? Consider the following example:

• User is anonymously browsing on our website with Device ID assigned by Amplitude as a UUID in cookies
• User attends an off platform webinar event with Device ID assigned as hash of email
• User makes an off platform inbound call with Device ID assigned as hash of phone number

When this user now completes the signup flow on the website we will:

• Call identify with our identifier as the User ID and Device ID assigned as the Amplitude UUID
• Call identify again with our identifier as the User ID and Device ID as the hashed email
• Call identify a third time with our identifier as User ID and Device ID as the hashed phone number

Will this then merge these three Amplitude users into a single user so that we capture all on-platform and off-platform events? Which user will they be associated with (by Device ID)?

Would we need to continue calling identify three times afterwards e.g. on login to associate off platform events that have occurred since the last login or would this initial linking keep associating these “device IDs” to the same Amplitude user? E.g. user attends another webinar post signup flow by the email hash Device ID, does that get associated to the same Amplitude user as the initial identify call on signup?

Hey @dargelies !

In the scenario you listed, correct, you’ll call identify 3 times for the 3 disparate device IDs to associate them with the same user ID. They will now be keyed primarily off of the Amplitude ID + user ID (and all previous Amplitude IDs will be associated with it) but you’ll be able to see the device ID change if you look in the user stream. You will not need to call Identify again, those device IDs will now be linked to the user ID. To your point, if the hash is consistent then you will not need to continuously call Identify, once the device ID is associated to a known User ID it will remain so until you force it to be associated to another User ID. This would be done by passing the device ID and a new user ID simultaneously together in a subsequent call. It doesn’t sound like you would run into this scenario though!

@audrey.xu thank you. That’s very helpful. We will try this approach. I don’t know how, but I’d love to update the “best answer” to  your response as it actually works around the issue I’m facing. Thanks again.