Question

Duplicate Profiles & Customer IDs

  • 16 April 2021
  • 2 replies
  • 39 views

Badge

Firstly, the API doc says:

If you choose to use your own unique identifier with the $id key, you take on the full responsibility of identity management within your Klaviyo account. You must ensure that all calls are made mapping the right $id value you're setting to the right $email. If you send some calls with $id only, these profiles will exist without any associated $email. If calls then come in for the same person, but only $email is part of the request, a permanent duplicate profile will get created for the same person. Given the complexity of ensuring $id and $email are mapped correctly with every call across all data sources, we recommend exclusively using email address to identify individuals.

 

Because of this I originally planned to NOT give our internal ID information to Klaviyo.  However, I was unable to figure out how to update a customer email address without creating a new account (preserve order/browse history) if I didn’t have the unique ID.

Therefore, I inserted the $id into customer profiles ALONG with $email.  Now I can update email address and keep profile data.  Works fine.

I do not have the $id always declared, but, I always have $email declared so events are still associated with the correct profile.  Klaviyo figures it out.

:::::UNTIL:::::

If I update a customer email address using the $id field, the email address updates correctly.  HOWEVER, if I then make a call using just $email the event causes a duplicate profile to be created, it does not update the original profile.

Because the behavior of $email only vs $id and $email calls is different AFTER an $email update, I *think* this is a bug.  I cannot find any other examples of duplciate profiles being created except AFTER submitting a change to their email.

 

Has anyone else run into this?  Have you found a solution?

 

 


2 replies

Userlevel 4
Badge +3

Hi @cdetdi,

Thank you for sharing this information with the Klaviyo Community.

Correct me if I am wrong, however, your description of events sounds like the scenario described in our documentation “If calls then come in for the same person, but only $email is part of the request, a permanent duplicate profile will get created for the same person.” You mention you are making the call using just the $email field which is causing a duplicate to be created, if this is correct this would be the expected behavior. If I am misunderstanding, perhaps you can provide an example with more detail. If you choose to do so, please ensure to redact any sensitive information from your example like any legitimate email addresses.

Thank you.

Badge

For background - we submit $id for any API calls but do not submit ID for javascript tracking.  I don’t want internal ID information available on the front end.

Certainly confusing, I will try to break it down more:

For this sentence you quoted:

If calls then come in for the same person, but only $email is part of the request, a permanent duplicate profile will get created for the same person.”

 

The sentence before is:

“If you send some calls with $id only, these profiles will exist without any associated $email. “

 

To me, these sentences together mean that if I create a profile via $id WITHOUT $email the profile will be created with $id but without $email.  Later if I make a call with $email without $id a new profile will be created.  This makes sense to me and I have no problems with that flow.

I’m talking about after a profile is properly created with $id AND $email.  Future calls that have just $email will be associated with the correct profile.  This is as documented in the API and is how my install is working currently.  Works great.

My issue is that this seems to break down if the $email in the profile is updated.  Steps to reproduce

  1. create profile with $id and $email (works)
  2. Run track API call with $email alone to confirm correct profile updated (works)
  3. change email by making API call with $id and new $email (works)
  4. Check on Klaviyo to see that profile has updated with new $email (works)
  5. Run API call with new $email (broken)

I was able to replicate this behavior yesterday but today #5 seems to be working as expected.  I will retest and examine.

 

 

Reply