Using Email Address as Identifier

Insider does not always use email addresses to identify, track or update users, but checks if users have the em (email) attribute to query and select them. If users have this attribute, they will receive emails. Architect also selects and sends users following the same method. All frequency capping and duplication controls are executed over email addresses but not identifiers. We use user ID's for tracking and updating users. 

Below are the cases involving identifiers:

• Promotional and Architect Emails
• Delivery
• Events
• Frequency Capping
• Duplication Control [not applicable to Architect]
• Unsubscribes

Delivery

For deliveries, we use email addresses along with identifiers. If users have an email address associated with the “em” attribute, we will deliver the email. This is valid both for both promotional and Architect emails. This means that it does not affect the delivery if the email address is not an identifier. 

Events

For both promotional and Architect emails, we use “insider_id” to register user events and update user attributes. Therefore, the correct profile will be updated.

Frequency Capping

Frequency capping will be applied using the user's email address and updated based on their Insider id. This is valid for both promotional and Architect emails. In a case where two users with the same email address are sent, if the first one does not meet the capping criteria and the second one does, the first one will be delivered and the second one will be capped. The delivered profile will be updated with the appropriate user ID, the second one will be updated with its user ID. This means that it does not affect the frequency capping if the email address is not an identifier.

Duplication Control

This case is only applicable to promotional emails. In a scenario where two users with the same email address and different identifiers are set to receive the same email, the first one will be delivered with the correct profile being updated, and the second one will be dropped with its user being updated in Insider's Unified Customer Database (UCD).

Unsubscribes

For unsubscribe events, promotional and Architect emails have different behaviors. When we consider a scenario where two users with the same email address receive an email at different times and one of them was previously unsubscribed, the first one will be marked as an unsubscribe and the second one will be dropped with an unsubscribe reason. Currently, we do not take any action when the event is dropped and the reason is unsubscribe, but we handle the “Invalid” case. We also might want to unsubscribe the second user as we have a filter that filters unsubscribed users for promotional emails. If we update the user attribute, we will ignore them the next time we send a UCD request. The same is applicable for Architect emails. As we have two data points to rely on, Sendgrid will drop the user even if UCD has no knowledge of the user being unsubscribed.

Caution List

• Customers that do not use email addresses as an identifier will not be able to upload customers to the global unsubscribe list. They will be prompted with a message stating that their email attribute is not an identifier at the moment and they should update it via Identity Resolution Management.
• Customers cannot use the subscription/resubscription services as these features are dependent on the email address as an identifier. 
• If a customer uses Upsert User Data API and sends a global unsubscribe attribute as 1, we do not sync the SG side. The SG services should be triggered also manually without interfering with the panel.
• If the customer resides in Turkey, IYS will not work accurately.