The unified contact timeline

Most organizations already have plenty of information about the people they work with. The difficulty is where that information is kept: the same person may appear in five different places, and those places do not agree. This guide explains what a unified timeline is, why contact history becomes split across tools, and what it takes to build one.

What a unified contact timeline is

A unified contact timeline is one record for each person, in date order, containing every interaction with them, whichever tool produced it: a door knock, a text reply, a chatbot conversation, an email open, a donation, or a note somebody typed after a phone call. Everything about one person is in one list, in the order it happened.

The most important feature is easy to miss. The tool that recorded an event is a detail of that event, not the place where it is stored. When records are split, "she replied to the text" is stored in the texting platform, because that is where texts are kept. On a unified timeline, the reply is stored on her record and labeled with the texting platform as its source. That choice decides whether you can ask "what is our history with this person" or only "what did this tool do".

For the same reason, a unified timeline is not the same as a set of integrations (connections between tools). Two tools copying data to each other give you the same information in two places, each still arranged around its own activity. A timeline is arranged around the person.

Businesses often call this a single customer view. Our post on what a single customer view is explains it for small business teams, from website chats to field visits.

Why contact history fragments

No one chooses to split their records. It happens by default, because each tool stores the interactions it produced under whatever identifier (a phone number, email address or name) it happened to collect.

• A texting platform stores a phone number. It may never have been given a name.
• An email platform stores an email address, and treats two addresses as two people.
• A canvassing app stores an address and a name, and often no contact details at all.
• A website chatbot stores whatever the visitor typed, which might be a first name and a mobile number.
• A spreadsheet holds whatever the person who made it decided to put in the columns.

These identifiers are different kinds of information, so nothing connects them automatically. The same person appears several times under several identifiers, and each tool's version is accurate but incomplete. The problem often appears at the worst time. For example, somebody who already asked you to stop texting them receives another text, because the sender was working from a list that did not include the request.

Split records make reports less accurate, but the larger problem is judgment. Every decision about a person, such as whether to call, ask again or refer the matter to someone senior, is based on the history you can see, and with split records that is only part of the real history.

For more detail, read why the timeline is the spine of a product suite, and what changes when several tools write to one record.

What belongs on a contact record

A contact record has to hold two different kinds of information, and mixing them up is a common design mistake.

Attributes are the facts that are true now, such as name, phone, email, address, stage, tags and custom fields. They are replaced when they change. You rarely need the history of somebody's phone number; you need the current number.

Events are things that happened, such as a door knock, a reply, an email open or a stage change. They are never replaced or deleted, because an event that can be removed proves nothing. If a record's history can be quietly edited, you can no longer rely on it for decisions, and in regulated messaging such as texting it can no longer serve as proof of consent (permission to be contacted).

This distinction leads to a simple rule: soft-delete people, never delete their history. A soft-deleted contact is removed from active use and stops appearing in lists and mailings, while the record of what happened stays intact. Permanently deleting a person destroys the evidence that they asked you to stop, which is exactly the record you would need later.

Matching: how two records become one person

Everything above depends on being able to tell that two events are about the same person. This is called matching. The order in which you check identifiers is an important decision, and it has lasting consequences.

Phone first, then email. A phone number is more likely than an email address to belong to one person. Shared inboxes, general addresses like info@, family accounts and forwarding all mean one email address can cover several people. If you match on the weaker identifier first, you combine people who should have stayed separate.

The order matters because the two possible mistakes are not equally bad. Failing to merge leaves two records for one person, which is inconvenient but visible, and can be fixed later. Wrongly merging combines two people's histories into one record, and separating them means deciding which person each event belonged to. The first mistake can be undone; the second usually cannot.

For the same reason, matching should be cautious and normalization (storing each value in one standard format) should be strict. Phone numbers in one standard format compare reliably. The same number written five ways does not, and a system that guesses at unclear input is guessing about somebody's identity.

Normalization has to happen when data is first saved, not when it is compared. If records are stored as typed and standardized only at comparison time, every future comparison has to account for every formatting style ever used, and the one that gets missed produces a duplicate nobody can explain. Storing one standard format means the rule is applied once, when the data arrives, where it is easiest to get right.

What to do when there is no identifier at all

Canvassing (going door to door) often produces this situation: a name, an address, a result, and no phone number or email address. There are three reasonable options and one that should be avoided.

You can create a new record and accept that it may later turn out to be a duplicate, which can be fixed. You can attach the interaction to the address rather than a person, which is accurate but limits what you can do with it. You can queue it for review, which works at small volumes but not at large ones. What you should not do, although some systems do, is match on a name and an approximate location and treat the result as one person. That is the mistake that cannot be undone, made automatically and in large numbers.

Merging, when it does happen

Duplicates are a normal result of cautious matching rather than a sign of failure, so merging needs to be a planned process, not an afterthought. A merge that keeps only the remaining record's events defeats the purpose of merging. The events from both records have to end up on one timeline, in order, with their original sources intact. The record that was removed should also leave a forwarding reference, so that anything still pointing to it reaches the merged record instead of a dead end.

Receiving events without losing or doubling them

A timeline that receives events from several products needs a way for those products to send them. That process can fail in two ways, and preventing one makes the other more likely.

Losing events

If the sending product waits for the timeline to confirm each event, then whenever the timeline is slow or unavailable, the sending product is too. No one accepts that for the sake of reporting, so sending has to be fire-and-forget: the sender passes the event on without waiting for a reply. The text goes out, the knock is recorded, and the report to the timeline never holds up either one.

Doubling events

Fire-and-forget sending relies on retries (sending again if a delivery may have failed), so the same event can arrive more than once. The solution is idempotency, meaning a repeated event has no further effect. The sending product supplies its own identifier for each event, and the timeline checks for that identifier before saving. A duplicate is discarded, not added.

This check contains a problem that is easy to get wrong and hard to notice. The identifiers are created by the sending product, so events from two different customers can carry the same one. If the duplicate check is not limited to each account, one account's event can block another account's event without any warning. No error appears; part of the second account's history is simply missing.

To test any system that claims to offer a unified timeline, ask what happens when the same event is delivered twice, and what happens when two customers produce the same identifier in the sending product. If nobody can answer, the timeline is collecting errors that no one will ever notice.

The types of events on a timeline

The phrase "every interaction" is easy to say but vague, so it helps to be specific about the kinds of events involved. CoreCNX recognizes more than 90 event types. They include door knocks and canvass results; text messages (SMS) sent, received and opted out of; chatbot sessions and captured leads; emails delivered, opened, clicked, bounced and unsubscribed from; appointments booked, confirmed and missed; donations; stage changes; tags; enrichment (adding missing contact details); imports; and notes.

The exact number matters less than the benefits of having a defined list of event types. Each type has its own summary template, so the timeline reads as plain sentences rather than as rows of raw data. Each event also records the source that produced it, so you can filter the timeline to a single channel when you need to, or read it as one complete history when you do not.

It also means a new source can be added without designing a new data structure. Any product that can describe what happened using those event types can add to the timeline, which makes the timeline a shared layer rather than one more separate store of data.

The list also requires a deliberate decision about how detailed an event should be. If events are too general, the timeline says only "email activity" and answers nothing. If they are too detailed, it fills with technical entries nobody reads, and the events that matter are buried. A practical rule is to record anything a person would mention if they were describing what happened. "She opened it twice and clicked the donate link" deserves two entries; each step the mail server went through in delivering it does not.

The other decision is what an event includes besides its type. Two things are worth including: the source, so the timeline can be read one channel at a time, and a few specific details, so the summary can say which link was clicked or what happened at the door, not just that a door was knocked. Beyond that, extra fields tend to be added for one report and never removed.

Data quality: why a timeline depends on its identifiers

Matching depends on identifiers, so contact data quality affects the whole timeline and is more than a housekeeping task. A record with no phone number cannot be matched by phone, so the next interaction with that person starts a second record and their history splits in two.

This is the strongest reason to use enrichment (looking up and adding missing contact details), and it is different from the usual reason, which is having more data to market to. Adding a missing mobile number makes the record possible to match, so that tomorrow's text reply is recorded on the same person as today's door knock.

The same applies to compliance work (following the rules on who you may contact). Checking numbers against do-not-call lists and verifying an email address before you send are usually treated as risk controls, but they also keep the timeline accurate. An address that hard-bounces (is rejected as undeliverable) tells you nothing about the person, and a number you should not have called adds an interaction you would rather not have on the record.

The costs of these checks vary, and the cheapest ones are the ones most often skipped. Verifying an email address before sending and checking a number against a do-not-call list cost roughly a tenth as much as adding a missing mobile number. Cost and good judgment lead to the same conclusion: the checks that stop you from contacting somebody you should not contact are cheap enough to run on every record.

This does not mean you should enrich every record. Adding data to records that nobody will ever contact spends money to make a list larger without making it more useful. Before any enrichment, ask "what would I do differently if I had this information", rather than simply "what is missing". A field that does not pass that test is not worth buying.

Building a unified timeline, step by step

Common questions