Profiles

Firstparty does not try and maintain a 1:1 relationship between a Profile and a person. Instead, Firstparty thinks of a Profile as a representation of a person in a specific context.

Suppose David Rose runs a small business and purchases items from your website using his phone or work computer for his retail small business. Later, he purchases something for his home from your website using a different device, such as a personal laptop or mobile phone.

If your website uses Firstparty to collect customer Events, Firstparty may create two different Profiles for David - one representing David as a business-owner, and another representing David as an individual customer. This allows you to market differently to David as a business and David as a consumer, meeting the needs of each role.

Like Events, Profiles may have a set of Properties that define that Profile. Unlike Events, Properties on a profile are mutable - you may update them with any value at any time.

A Profile's Properties are not version controlled - in other words, Firstparty does not maintain a historical record of Property values on a Profile.

Profile Properties should be used to describe a Profile with information that changes infrequently, or information that is appended or incremented in a single direction. Properties such as a name or email address that are rarely changed, or Properties like lifetime value are great for Profiles. Lists, such as all of a customer's purchases, or activities the Profile has performed should be represented by Events, not Properties on the Profile.

Firstparty will automatically try and merge two Profiles who share an Identifying Property. When Profiles are merged, the Property values stored on the Profiles will be combined based on the settings of each individual Property.