Attribute observations

Some fields in features describe the person, not the activity: a first name, a city, a date of birth. Those are declared with class attribute in the catalogue and the processor turns each into an observation: at time ts, on activity X, the identifier with role Y was said to have attribute A with value V, with weight W.

The observation is stored exactly as typed, and the field leaves features. Which value is right for a person when observations disagree is the CRM's decision, from the weights and the times; the ingest service never picks a winner and never corrects a value.

What the catalogue declares

Each attribute field says which canonical attribute it maps to, its weight class and the role of the identifier it is observed on:

Canonical attribute	Observed from	Weight
first_name, last_name	the buyer on completed_order	50
first_name, last_name	the holder on personalised_ticket	80
city, postal_code, country, date_of_birth, gender	the buyer on completed_order	50
the same	the holder on personalised_ticket	80
language	the buyer's locale on completed_order	50

A higher weight is a stronger source: what a ticket holder says about themselves outranks what the buyer typed for them.

Rules

• A value that is not a plausible instance of its attribute is dropped and counted (a country that names no country, a date_of_birth that is not a date). The activity is kept.
• Without any identifier on the activity there is nobody to observe against; the field is dropped and counted.
• city, postal_code and country are also what the geo block places; the block, not the attribute, is what the processor resolves into a place. The observation keeps the text as typed either way.
• Erasing an identifier deletes its observations.

The CRM resolves a person's attributes from these observations.