Skip to main content
Solved

Why are Does an Updated Email revert to Original Email?

  • October 20, 2021
  • 3 replies
  • 131 views

Forum|alt.badge.img+2

I'm seeing some weird behavior. I’m using nothing at all except identify in js ($email, no $id) and updateProfile on the backend.

 

  1. Create a new user first@email.com. That user is added to Klaviyo via identify in js using $email and not $id.
  2. The user shows up in Klaviyo as expected
  3. Change the email address. I get Klaviyo’s internal id for the user via a search for the email address. Then I call updateProfile with the internal id retrieved and update nothing but the email address, i.e. second@email.com
  4. Klaviyo shows the user renamed to second@email.com
  5. Browse to another page. Identify js passes in second@email.com
  6. Klaviyo creates a new profile for first@email.com
  7. After that, it’s all second@email.com, but first@email.com is still left over as a duplicate from step 5/6.

 

To recap: The updateProfile is working as expected, but the very next js identify is somehow recreating the previous email address even though I’m supplying the new email address to it. It's like the identify call insists on using the old email address just one last time.

 

Any help would be appreciated.

Best answer by Taylor Tarpley

Hi @ryanklav

 

Welcome to the Community and thanks for sharing your question! 

 

It seems that the issue here centers around the email that was originally cookied in your webpage. The webpage you are using is already being cookied as first@email.com and although you are using API to change and update the email, because the browser is first cookied as the first email on the front end, navigating to another page will cause the cookie to follow over and be identified again. This is what’s causing a new profile to be created for first@email.com

 

Thanks for being a part of the Community! Hope this helps understand the issue! 

-Taylor 

 

View original
Did this topic or the replies in the thread help you find an answer to your question?

3 replies

Taylor Tarpley
Community Manager
Forum|alt.badge.img+60
  • Community Manager
  • 2148 replies
  • Answer
  • October 21, 2021

Hi @ryanklav

 

Welcome to the Community and thanks for sharing your question! 

 

It seems that the issue here centers around the email that was originally cookied in your webpage. The webpage you are using is already being cookied as first@email.com and although you are using API to change and update the email, because the browser is first cookied as the first email on the front end, navigating to another page will cause the cookie to follow over and be identified again. This is what’s causing a new profile to be created for first@email.com

 

Thanks for being a part of the Community! Hope this helps understand the issue! 

-Taylor 

 


Forum|alt.badge.img+2
  • Author
  • Contributor I
  • 1 reply
  • October 22, 2021

Thank you @Taylor Tarpley . Immediately deleting the cookie when changing email address seems to work well.


Forum|alt.badge.img+1
  • Contributor I
  • 5 replies
  • February 5, 2025

Hi ​@ryanklav have you seen this issue again or any 409 errors in your logs? 

We recently had the same issue and have deleted the cookie to stop most occurences of this bug, however, we still see it from time to time and I’m trying to work out how it’s still occurring. 

 

For anyone else experiencing this, so far what we have found is that Klaviyo’s JS caches a _ks parameter which they use to identify the user.

If the user’s email is updated via a form being posted to the server with a full page refresh, upon page load Klaviyo will send an “Active on Site” event with the cached _ks parameter as soon as it loads rather than waiting for the new “Identify” call which contains the updated email. Given the server has updated the user’s email via an API call, Klaviyo uses the old email from the cached _ks parameter and as it can’t find a user with this email, it creates an account using the old email address. If the user then tries to change their email back, they will receive a 409 as that email is now being used in the erroneous account.