Lead source codes: why 3 systems give 3 answers on where a lead came from
In short
A lead source code is a controlled value in the dealership CRM recording who delivered the enquiry, set at the moment the lead record is created. It is an operational label used for routing, follow-up and vendor accountability — not marketing attribution, which is why it will never reconcile with website analytics or a campaign report, and should not be expected to.
Key takeaways
- Source answers who delivered the enquiry, not what the shopper clicked or which campaign paid for it.
- Three systems measure three different things, so nominate one as the operational answer rather than reconciling them.
- Set source once at record creation and never overwrite it; put later activity in a separate last-touch field.
- Map incoming sender strings to a short canonical list. Auto-creating a code from a sender name is how a list reaches 200 entries.
- If a code cannot answer "who do we pay" or "who works it", it is a reporting artefact and should be deleted.
A lead source code is a controlled value in the CRM recording who delivered an enquiry: a named marketplace, the dealership website, a phone call, a walk-in, a service customer, a referral. It is set when the record is created and drives operational things — which queue the lead enters, which follow-up runs, which vendor is held to account at month end.
It is not attribution. That confusion is why a store can hold 3 reports on the same 40 enquiries, get 3 answers, and spend a management meeting deciding which is lying. None is. They measure different things.
Three questions, all of them called "source"
| The question | System of record | Typical answer | What it is good for |
|---|---|---|---|
| Who handed us this enquiry? | The CRM, from the lead's provider field | A named marketplace, the website, a phone call | Routing, response accountability, vendor performance |
| What did the shopper interact with? | Website analytics and session data | Organic search, a paid ad, direct, a referrer | Shopper behaviour before the form |
| Which spend produced it? | The ad platform or the vendor invoice | A campaign, an ad group, a listing package | Budget allocation and cost per enquiry |
Each is correct in its own frame. A shopper searches, clicks a paid ad, browses, leaves, returns 2 days later through a marketplace listing and enquires there. Google Analytics sees paid search, the CRM sees the marketplace, the invoice sees both. Nothing is broken. What is broken is asking 3 systems to agree.
Set once at creation, never overwritten
The commonest corruption of a source list is not a bad taxonomy, it is a good one being overwritten. A salesperson re-opens an old record when the shopper returns, an import updates existing rows, or a merge takes the newer value — and an enquiry a marketplace delivered in March becomes a walk-in in June. Historical reports change retrospectively, and nobody notices until a vendor disputes a count.
- Keep source immutable. Write it at creation from the incoming lead's provider field, then make it read-only.
- Add last_touch as a separate field if you need recency. It changes freely because nothing financial depends on it.
- On a merge, keep the earlier record's source and store the other as secondary. Duplicates with conflicting sources are the mess in three salespeople texting the same shopper.
- Record floor traffic the same way. A walk-in is a source, and the store's own log is its system of record — with the caveats in what an up log is and what the digital version loses.
How to stop the list reaching 200 entries
Source lists rot by accretion. A provider renames itself, a vendor sends a slightly different string, someone adds a code for a one-off event, and within 2 years the report carries a long tail of near-duplicates nobody can interpret. The fix is a mapping layer between what arrives and what you store.
- Define the canonical list first, small enough that every value maps to a budget line or an operational route. Most single-rooftop stores need fewer than 25.
- Map inbound sender strings to canonical codes in a lookup table, not in code. Several strings to one code is the normal case, not the exception.
- Never auto-create a code from an unrecognised sender. Route unmapped leads to a quarantine value, work it weekly, add the mapping deliberately.
- Version the mapping with an effective date, so a rename does not rewrite history when you report on last quarter.
- Audit quarterly by counting leads per code. Anything with a handful of records is either mis-mapped or should not be a code.
This is ordinary controlled-vocabulary hygiene, solved long ago on the parts side with structured attribute standards — which PIES segment holds an attribute is the same discipline on product data. A shared list works only when exactly one place can create a value.
What a source code cannot tell you
It cannot tell you what happened to the lead — that is a separate vocabulary, in disposition codes an automated follow-up can branch on. It cannot tell you whether the enquiry was good, because volume and quality are different measurements and the highest-volume provider is rarely the highest-converting. And it cannot tell you what the shopper did beforehand, which lives in analytics.
Source is an operational field that people try to use as a financial one. Decide which it is in your store, write that down, and hold every report to it.
The taxonomy is what makes everything else in lead response and follow-up measurable, because routing rules and cadences branch on it. It is usually a small piece inside a larger build — the sort of thing we scope as an MVP and product build across the systems we build for dealerships.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
Should the CRM source match Google Analytics?
No, and expecting it to wastes a lot of time. Analytics measures the session preceding a form submission on your own site; the CRM records who delivered the enquiry, including channels analytics never sees — marketplace leads, phone calls, walk-ins. The gap is largest for stores with heavy third-party listing spend.
How many lead source codes should a dealership have?
Fewer than 25 for a single store is a good working ceiling. The test is that every code maps to something you pay for or route differently. Codes existing only so a report can be sliced a particular way accumulate fast, get applied inconsistently, and make the report less trustworthy rather than more detailed.
What should happen when a lead arrives from an unrecognised provider?
Create the lead, assign it a quarantine source value, and review those weekly. The alternative — auto-creating a new source code from the sender's name string — is the single most common way a list grows to 200 entries, because providers change their sending names more often than anyone expects.
Can one lead have two sources?
One immutable original source, plus as many other fields as you find useful. Model it as original_source, which never changes, and last_touch, which does. Storing multiple simultaneous sources in one field makes every count ambiguous, and that surfaces in the month a vendor invoice is challenged.
- lead source
- attribution
- CRM taxonomy
- reporting
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- The ADF lead: every field a CRM receives, and the three that decide routingADF is the XML format most third-party enquiries arrive in. The spec is old and loosely honoured, so a parser has to treat almost every element as optional — except three.definition
- Disposition codes: 'no answer', 'not now' and 'not a buyer' differA disposition is not a note about the call. It is the instruction for what happens next, and a value naming no single action and owner cannot be automated.definition
- The marketplace says it sent 40 leads and your CRM has 31A vendor's lead count and your CRM's lead count disagree for four different reasons, and from inside the CRM all four look identical. Here is the reconciliation that tells them apart.diagnostic
- What an up log is, and why the software version never matches the floorThe up log is a dealership's floor-traffic record, not a CRM record — and because the person who fills it in has usually just lost the sale, the number it produces is a floor, not a total.definition
Related across the site
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation