Hi @m-intrigma and @awhite,
Thank you both for getting this information all in one place, and posting here to the forum where I’m able to communicate with you directly. Also, thank you for your patience on this. This issue was notoriously tricky to pin down, with a lot of information from a lot of different sources. I’ve outlined my findings below.
In all of these cases, multiple email identities were merged into a single contact record. Because each record has multiple email identities, the update requests coming in from each email all change the same record in HubSpot. I can disassociate the email identities from each of these (and any other) records, which will result in a new contact record being created for each email address when you run your usual create/update job.
I’ve outlined a few steps you all can take to help mitigate this issue going forward:
- The forms API shouldn’t be used to track logins. Contacts that share a device (i.e. form submissions with different information) can overwrite existing contact information. Because contacts are limited to 1000 form submissions each, using them to track logins can make it difficult (or if you’ve hit the 1000 submission limit, impossible) to track real conversions. If you’re looking to track login information, you should use the HTTP events API (doc below).
- There are a huge number of associated usertokens/vids for each of these contacts. Contacts might have multiple vids if they have multiple devices or they’re clearing cookies from their browser, but the number that exist for these contacts seems to point to something else going on. Are you clearing visitor’s
hubspotutk cookies, or perhaps loading the tracking code in an app that doesn’t persist cookie information? This type of behavior resulting in huge numbers of associated usertokens/vids can lead to association issues and lost analytics data.
- When the one-way sync is made from your system to HubSpot, it doesn’t appear you’re using the batch APIs. Wherever possible, you should batch your contact updates to reduce request volume (doc below).
I’m still working on figuring out exactly how all of these contacts got into this state. It appears that at least a few of these email identities were merged erroneously due to an internal job around July 4th, 2017. In other cases, it appears there was a manual merge of two contact records in the UI. Still others I’m not so sure of. I’ll continue digging into these examples to find where these merged identities came from, and update this thread with more information as I find it.