First-party data and event tracking: personalisation using actionable signals

Distinguish between first-party and zero-party data

First-party data is generated through your direct relationship with your customers, for example through an order or the use of your shop. The term ‘zero-party data’ is often used to refer to preferences that have been deliberately shared. This distinction describes the origin of the data; it does not replace an assessment of the purpose, information and required consent.

Klaviyo’s guidance on Data collection distinguishes events, profiles and catalogue data, among other types. Start with a specific message: which content would become more helpful with additional information? If you cannot answer that question, collecting more data is not a useful next step.

Events and profile properties serve different purposes

An event documents a process at a specific point in time. A profile attribute describes a value associated with a contact. ‘Placed Order’ and ‘Interest: Hiking’ are therefore not interchangeable. The Guide to custom properties explains the profile level.

An example: An outdoor shop asks customers to select ‘Hiking’, ‘Camping’ or ‘Everyday use’ as optional choices in a form. The value determines the initial selection prompt. A subsequent order for a tent may trigger a camping usage tip. This should not override the explicitly stated preference without verification. An order placed as a gift is a plausible counter-example.

A brief data plan prevents conflicting values

For each required field, define the name, data type, permitted values, source and usage. Also specify who is authorised to update the value. If a form submits ‘Camping’ and an import submits ‘camping’, a rule may treat the values differently. Such differences often only become apparent upon dispatch.

For events, note the triggering action, time, profile assignment and required properties. Test a real-world sequence in a test profile: how many events are generated, and which profile receives them? A duplicate signal from two integrations may trigger a flow more frequently than intended. A smart dashboard does not necessarily detect this error.

Check identification and consent separately

A browser cannot be assigned to any known customer profile simply because someone visits a product page. Technical identification depends on the login, click or integration path. Check the documented behaviour of the shop integration and tracking used.

Furthermore, an existing email address does not automatically constitute consent to receive communications. Keep profile data, channel consent and tracking decisions separate. In the event of a withdrawal of consent, the process actually affected must be stopped or adjusted. The Data Protection Audit Plan helps to clearly allocate responsibility between marketing, technical teams and legal review.

Check for missing and contradictory data

• No interest specified: the general message remains helpful.
• ‘Interesse’ has an unknown value: a safe default version applies.
• The order is a gift: the content does not imply any personal use.
• Two integrations trigger the same event: the workflow does not send it twice.
• Profile and browser are not identified: no fictitious personalisation is created.
• Consent is withdrawn: the next mailing will take this into account.

When doing so, document not only the visible message but also the values that led to the selection. It is precisely this information that will enable reliable troubleshooting later on.

Evaluate personalisation based on a decision

Start by testing a small, clearly justified adjustment. In the model shop, this could be an interest-specific selection tool instead of a general product range link. Monitor relevant clicks, unsubscribes and subsequent purchases over the agreed period. A higher open rate is not proof that the additional data collection justifies the effort involved.

If the difference remains unclear, simplify the rules. A well-worded general message may be the more reliable solution for many contacts. The scope of the data should stem from a useful decision, not from the mere possibility of storing additional fields.