How Co-Signal computes an overlap

Two companies say they have overlapping customers. Somebody usually finds out the hard way, comparing spreadsheets on a call, three weeks after the partnership already needed the answer. Co-Signal exists to make that comparison instant, privacy-safe, and always current. This post walks through the mechanism end to end: how an account gets in, how two accounts from two different CRMs get recognized as the same company, how a population becomes the unit two partners actually share, and what each visibility level actually returns.

Getting accounts in

Every workspace connects its own CRM independently. Salesforce and HubSpot connect over OAuth; a CSV import covers any CRM that does not have a native connector yet. Nothing about ingestion depends on the partner: a company can connect its data, define its populations, and set its sharing defaults before a single partnership even exists.

Every account, whether it arrived through a Salesforce sync, a HubSpot sync, or a CSV row, is identified by its domain. Domain identity is what lets Co-Signal recognize that "Acme Corp" in one company's CRM and "Acme Corporation" in another's are the same account, even though the two CRMs never agreed on a name. A CSV row with no usable domain is rejected at import time, with the specific row flagged, rather than silently accepted and left to produce a false negative later.

Matching: exact first, fuzzy second, a human decides the rest

Once both sides of a partnership have connected data, Co-Signal runs a matching pass over the two account sets. The first pass is a straight domain join: two accounts with the identical registrable domain are an exact match, full stop, no ambiguity. Domain matching is deliberately the first pass and the highest-confidence tier, because a shared domain is about as strong a signal as company identity gets.

Everything that does not join on domain moves to a second, fuzzy pass: name similarity, checked against a couple of thresholds and, where useful, corroborated by a shared contact or account email domain that did not happen to match cleanly on the primary domain field. Corroboration matters because a bare name-similarity score, on its own, is not a strong enough signal to promote automatically. A name score that clears the highest threshold is treated as strong on its own; a score in the middle band is only promoted to strong when something else corroborates it; anything below the floor produces no candidate at all. This is a precision-biased design on purpose: it is worse to tell a partner two unrelated companies overlap than to leave a genuine but ambiguous match sitting in a review queue for a person to confirm.

That review queue is the third layer. Matches below the automatic confidence tiers, and any tier a partnership admin wants to double-check, sit in a queue where a real person confirms or rejects the pairing. A confirmed match counts toward the overlap from then on, even if a later recompute would not have produced it automatically; a rejected match never counts again, even if the underlying data looks similar next time. The matching pass runs again on a schedule and after CRM changes, but a human decision, once made, survives every future recompute.

Populations: the unit two partners actually share

An account overlapping is not, by itself, useful information. What two partners actually want to compare is a segment: our customers against their customers, our open pipeline against their prospects, and so on. Co-Signal calls that segment a population: a saved filter over a company's own accounts, built from fields like account type, domain, and open opportunity status. Every workspace starts with three default populations, customers, prospects, and open opportunities, and can define as many custom ones as it needs.

A population is what gets shared with a partner, not an account list and not raw CRM data. That distinction matters for the sharing model below: sharing is set per population, per partnership, so a company can share its customer population at one level with one partner and a completely different level with another, without those two decisions ever touching each other.

The matrix: the read model both sides see

Once populations exist on both sides of a partnership, the matrix is the grid where every population from one side is compared against every population from the other: rows from one company, columns from the other, one cell per pair. A cell reports how many accounts land in both populations, drawn from whatever matches passed the confidence and review process above.

The matrix recomputes whenever the underlying match data changes, but the sharing rule that governs what a cell displays is evaluated fresh on every read, not baked in at recompute time. That ordering matters: if a company tightens its sharing setting for a partner, the matrix reflects that immediately, on the very next load, rather than waiting for the next scheduled recompute to catch up.

What each visibility level actually returns

Every population, in every partnership, carries exactly one of three visibility levels, set independently by the population's owner and never by the partner viewing it.

Level	What the other side sees
Counts only	A number: how many accounts overlap. No names, no identifying detail. The starting level for every new partnership.
Overlapping accounts	The names of the accounts that overlap, nothing else about them.
All accounts	Full account detail for the overlapping accounts, including whichever optional field groups (open opportunity value, contacts, and so on) the owner has separately opted in.

A partner never sees more than the level its counterpart chose, and a counts-only cell whose true number is small enough to identify a specific account is suppressed rather than shown as an exact digit. That suppression rule, and the server-side enforcement that makes it real rather than cosmetic, is its own subject, covered in the companion engineering post on this blog.

Why this design, not a simpler one

It would be simpler to let two companies just export their account lists and compare them directly. It would also mean either company could see the other's full customer roster the moment they connected anything, with no way to share only a count first and decide later whether to share more. Co-Signal's mechanism, ingestion, matching with a human backstop, population-scoped sharing, and a matrix that reflects sharing changes instantly, exists specifically so two companies can start a partnership cautiously, see real value at the counts-only level, and open up further only when they choose to, one population and one partner at a time.