Centralized leads: why the same person lives in five systems and how to bring them together
The lead came in through the form, became a contact in the e-mail tool, showed up as a buyer on Hotmart, replied on WhatsApp and clicked an ad. Five records, five identifiers, no timeline. Centralizing is not importing everything into one place: it is deciding who is who.
Try it with one of your customers. Take the e-mail of someone who bought last week and look for it in every system the company uses: the e-mail tool, the CRM, the payment platform, the sales WhatsApp, the launch spreadsheet. The same person will show up in almost all of them — with a phone in one, an e-mail in another, the name spelled two ways, and dates that do not talk to each other.
That is not disorganization. It is the natural result of each tool having been hired for one job, and each keeping the piece of the person it needed. The problem appears when the question crosses the pieces: “who clicked the ad, filled the form and did not buy?” has no owner.
Centralizing is not importing
The first attempt is usually to put everything in a spreadsheet or a database. It works for a week: the export is a snapshot, and the next day it is stale. The second is to wire tool to tool with automation — the form sends to the CRM, the CRM sends to the e-mail tool. It works until the third tool, when the wires become a web nobody understands anymore.
What works is a place that RECEIVES from every source continuously, decides which records are the same person, and keeps a timeline per person. That is the definition of a CDP, and the hard work is not receiving — it is deciding.
Who is who: the identity rule
Every source delivers some identifier: e-mail, phone, a browser cookie, a customer id. The rule that joins two records into one person needs to be explicit, because the two mistakes are expensive in opposite directions.
| Mistake | What happens | How it shows up |
|---|---|---|
| Merging too much | Two people become one (shared device, company e-mail) | The buyer “already bought” three times; the journey makes no sense |
| Merging too little | The same person becomes five | The lead who “never bought” has a purchase under their name in another record |
The rule that works in production is asymmetric: a strong identifier (e-mail, validated phone) merges; a weak identifier (cookie, device) only ties the anonymous to the identified and never merges two identified people with each other. We detail the decisions in when to merge and when never to.
A centralized database without an identity rule is just a big database. The value is in the rule.
What changes when there is a timeline per person
- The salesperson opens the profile and sees the ad that brought them, the form they filled, the previous purchase and the overdue installment — before calling.
- The campaign gets the right event back: the Lead with identity, and the purchase with attribution, through the Conversions API.
- An audience can be “whoever watched the video, opened checkout and did not buy within 7 days” — three sources in one rule.
- The AI answers questions that cross sources, because the sources are in the same table.
Where to start
- 01List the sources through which a person enters: site pixel, forms, payment platform, CRM, e-mail tool, ads.
- 02For each one, note the identifier it delivers. If one only delivers a name, it will not match on its own.
- 03Connect the sources with ready connectors first (payment, ads, pixel). Your own CRM comes in through a webhook.
- 04Check the identification rate: how many leads have an e-mail or phone? Below 10% on the pixel is normal; below 90% on purchases is a sign of trouble.
- 05Only then build the first audience or the first report. Before that, it is disconnected data under another name.
In CrazyLeads each source comes in through a connector — Hotmart, Meta Ads, Google Ads, pixel, forms, Zoom, ActiveCampaign, database or webhook — and every event goes through the same identity resolver before entering the timeline. The lead profile shows the whole person; the rest of the product reads from it.