What counts as a change to a field?
Re-saving the same value is not a change, and replacing a placeholder such as Unknown with a real value is the field being filled in rather than overwritten. This article gives the exact rule, how the thing that made each change is identified, and what a tool's history can and cannot show. If a first-touch field is the one being replaced, Stop HubSpot overwriting first touch has the fix.
What counts, and what does not
| What happened to the field | Counted as a change? |
|---|---|
| A real value replaced by a different real value | Yes. This is the thing being measured |
| The same value written again | No. Repeats of a value are collapsed before anything is counted, so a nightly job re-saving the same source adds nothing |
| A blank written | No. Blanks are dropped from the run of values |
| A placeholder such as Unknown replaced by a real value | No, when the placeholder was the field's first value. That is the field being filled in, and the count of those is printed separately in the evidence |
| A change made by the tool itself to its own reading of a field | No. Your team did not do it and cannot stop it |
| A change made by a person, a workflow, a form, an import or a connected app | Yes |
The placeholders treated this way are the usual ones: Unknown, Other, N/A, None, Null, Unspecified, “not set”, “not provided”, the to-be-decided shorthand, Test, the literal a script writes when a value was never set, and values that are nothing but dashes, dots or question marks.
Why the placeholder rule matters
Without it, every enrichment tool in the market would read as an overwriting problem. A field that goes from Unknown to Paid Search on day two is working. A field that goes from Paid Search to Direct on day ninety is not, and only the second is counted against it.
What the changes are counted over
The denominator is the records checked, not the records whose field changed. A field that never changed on a record still counts in the denominator, with its present value read as its one and only value. Counting only changed records would turn every share into “of the records where it changed”, which is always high and never useful.
- A field is judged only with history on at least 20 records. Below that it is listed as understood but not tested.
- The value a field held before its first logged change is recovered from that change's own “old value”, and counted as the field's first value.
- Shares are of the records checked. The “at least” figure quoted for the whole database is the cautious end of a 95% range, never the sample share projected flat.
- A finding lists up to 200 example records you can open in your tool.
What makes a field a finding
A field is read as set-once, rolling, forward-only, written by a rule, or a forecast date, worked out in your workspace from its own name and label, its type, its picklist and the fields beside it. No list of field names is built in, so a custom field is read the same way as a standard one. What counts as a fault then depends on that reading.
| Finding | What it takes |
|---|---|
| is being replaced after it is first set | A set-once field replaced on at least three records checked, and on 2% or more of them. It is a fault rather than a risk at 10% and five records |
| Two things are fighting over it | The record's last six changes to the field alternate between no more than three values, at least four of them, with at least two different writers among those six — and that shape holds on at least three records checked. Always a fault, except on a field MarqIQ reads as rolling, where replacing the value is what the field is for |
| is holding its first value | A set-once field that was not replaced. Reported as sound, with the count it rests on |
The evidence on a replacement finding prints five things: how many records of how many, typically how many times each, who did the replacing with a count beside each name, how long after the first value the first replacement typically came, and the month of the most recent one. A replacement inside the last 90 days is labelled as still happening.
How the thing that made each change is named
Every change carries a writer, in one of seven kinds: a person, an automation, a form, an import, a connected app through the API, the tool itself, or a source the tool does not name. The writer is named as your tool names it — the workflow's own name, the form's own name, the integration user's own name — so you can go and find it.
| Tool | What it tells you about the writer |
|---|---|
| HubSpot | The source of every property change, including the workflow or form that made it, resolved to its name |
| Marketo Engage | The Change Data Value activity, with the smart campaign behind it |
| Salesforce | Which Salesforce account made the change, and never whether a flow or an integration made it under that name. An account name that reads as an integration is labelled as one |
| Pipedrive | The change source: a workflow, an import, the API, a web form, the app, or Pipedrive itself. A bulk edit is named as one |
| Zoho CRM | The timeline source, with the workflow rule's own name where one made the change. A mass update is named as one |
| Microsoft Dynamics | Whichever Dynamics account the audit record names. A flow running under an account is reported as that account, and the page says so |
Take care
Read the Salesforce and Dynamics rows before you act on a name. Both tools record which account the change ran under, not what ran it, so an automation running under an admin login reads as that admin. Check the field's writers against your automation list before anybody is asked about it.
What each tool's history can show
| Tool | How far back, and over what |
|---|---|
| HubSpot | Every value a property ever held. Properties nobody can write are dropped before any history is read |
| Marketo Engage | About 25 months. A change made before that cannot be seen, and a field with no recorded change is taken to have held its present value throughout |
| Salesforce | Only fields an admin switched Field History Tracking on for, up to 20 per object, kept for 18 to 24 months. Deal stage, amount and close date are always testable, because Salesforce records those on every opportunity regardless |
| Pipedrive | The per-record change log, read one record at a time |
| Zoho CRM | The per-record timeline, read one record at a time. How far back it goes depends on your Zoho edition |
| Microsoft Dynamics | Only columns with auditing switched on for the organisation, the table and that column, read one record at a time |
Where a field carries a purpose and its history is not switched on, MarqIQ names that field and gives the path to switch tracking on — and states that history starts from the day you do, not before it. That sentence is itself something an admin can act on.
How many records are read
- HubSpot and Salesforce: up to 600 people and 600 deals, an even sample spread across your whole database.
- Marketo Engage: up to 600 people, on the same even sample. Marketo syncs no deals, so there are none to read.
- Pipedrive, Zoho CRM and Microsoft Dynamics: up to 60 people and 60 deals, because each record costs a separate request. The page states that smaller sample rather than hiding it.
- The sample is spread across the whole database and not only the newest records, because older records have had more time to be overwritten. Reading the newest would understate every finding here.
Note
A field that only your tool itself has ever written is left out altogether, and the method note counts how many and names a few. The tool keeps them, so there is nothing for your team to break or to fix.
What a snapshot cannot tell you
A tool with no per-field change history gives a snapshot: what each field holds today. From a snapshot you can see that a field is blank, that it holds a catch-all value, or that one channel is spelled five ways. You cannot see that it held something else last month, who replaced it, or whether it is still happening.
That is why Field discipline cannot run for Pardot (MCAE), Mailchimp, Salesforce Marketing Cloud, Adobe Campaign and Adobe Journey Optimizer. The tab is still in the row on the tool's own page, drawn in grey with a dashed border. Open it and the analysis is replaced by a card headed Not something this tool can do. The sentence under it reads “This tool does not expose a record’s change history, so there is nothing to hold a field to.” Where the analysis is left out altogether is any list built from what a tool can feed: the tool's card on the Analysis screen, the card grid on its own Overview tab, and the tool listing MarqIQ gives an assistant. None of the three draws a Field discipline card for these five. The gap is stated as MarqIQ's limit and the tool's, never as something you failed to set up. Source truth covers the part of the same ground a snapshot can answer.
Nothing on the tab changes anything in your tool.
If it did not work
A field you know is overwritten daily shows no finding
Why: The same value is being written each time, and a repeat is not a change.
Fix: Nothing to fix. A rule re-asserting a value it already holds costs an API call and changes no report.
The count is lower than the number of changes in your tool
Why: Repeats, blanks, placeholder fills and the tool's own writes are all left out, and only a sample of records is read.
Fix: Read the method note for the sample size, and the evidence for the count of placeholder fills held out. Compare like with like before quoting either figure.
“There is not yet enough change history to test them”
Why: Fewer than 20 records carry history for those fields.
Fix: Widen the Created range so more records are read, or, on Salesforce and Dynamics, switch history on for the named fields and come back once it has accumulated.
Every writer reads as one person
Why: On Salesforce and Dynamics an automation runs under an account, and the tool records that account.
Fix: Check that account against your flow and integration list. Where it is a service account, the writer is the automation running under it.
A field carrying a clear purpose is missing from the table
Why: Its history is not tracked, or only the tool itself has ever written it.
Fix: Look for it in the coverage note, which names untracked fields and gives the path to switch tracking on, and in the method note, which counts tool-owned fields.
Next steps
Related articles
Was this article helpful?