Why HubSpot attribution data goes missing without an error: 4 failures to test

Dashboards draw whatever data arrives. If a link never identifies the visitor, the click still lands in the email stats and the report still draws its bar. It just draws that bar from fewer records than you think.

That is why these failures look like reporting problems first. On recent engagements, several of the failures below first showed up as a complaint that the numbers felt low, or that credit was landing on the wrong team, and turned out to be plumbing faults that no one had been alerted to. Debating credit rules while the signal is broken is expensive. Verify the signal first, then argue about the model.

Content platforms and email vendors often generate tracked links that carry a record ID, so HubSpot can look up the contact when they click. In one case the vendor's link builder wrote the personalization token with the plural object name, contacts, where HubSpot expects the singular, contact. The plural is the name of the API collection. The singular is the name of the object. HubSpot never resolved the token.

Nothing errored. Clicks still appeared in the email statistics. But no identity attached to the click and no company was created, so no enrichment ran. One character, contact versus contacts, was the whole bug, and it survived because everything around it kept working.

The tell is in the email editor preview. A correct record ID token visibly changes into a merge tag. An unresolved one stays plain text. Check that before anything else, because it takes ten seconds.

A related choice sits underneath. An encoded link carries only a record ID and does a read-only lookup, so no personal data travels in the URL. A standard link works but exposes personal data. If a team has quietly fallen back to standard links, ask whether the encoded version ever worked.

Many vendors write activity back to HubSpot, such as content views and CTA clicks, through a form that is published but not public. The vendor submits to it through the Forms API and keys on email address. Nobody sees that form on a page, so nobody thinks to open it.

If that form has required fields, the vendor's system cannot satisfy them on every event, because it does not populate every field every time. HubSpot rejects the submission with a missing-required-fields response, and the activity never syncs. Your public forms and landing pages keep working, which is exactly why no one looks.

The fix is dull. Make every field on that form optional. Make the field internal names match the vendor's mapping table exactly. Paste the form ID into the vendor's integration settings, and confirm any tracking-code toggle on their side is switched on. As the consultant on that engagement put it, if we require fields, their system can't fill out everything every time, so it fails the moment it hits a block.

One more trap: this path usually fires only for known external contacts. A test from an internal company email will not trigger it, and you will conclude it works.

This one looks like a deliverability issue on its face. It belongs here because the silence is the same and the habit that catches it is the same: confirm that the thing you assume is running is running.

In one portal, the workflow that should switch hard-bounced contacts to non-marketing was sitting unpublished. A previous admin had turned off a number of workflows and no one had audited the list since. Bounced contacts stayed marketable and synced to Salesforce that way. Reps kept emailing addresses that had already hard-bounced.

Branch order added a second fault. HubSpot evaluates if/then branches in order, and the customer-exclusion branch sat last, so every earlier branch had already acted by the time it ran. It belonged first. Marketing contact status also syncs in both directions between the two systems, and the most recent change wins. A status someone corrects in HubSpot can be undone by the next update from the other side.

Compare your bounced list against marketing contact status. If any bounced contact is still marketable, the workflow is not doing its job, whatever the dashboard says.

Paid social is the quietest of the four. A browser pixel only reports conversions that the browser lets it see. For a small, expensive audience, every missed conversion starves the ad platform of the signal it uses to optimize, and your attribution report undercounts the channel at the same time.

On the account where this came up, the consultant's read was that the pixel alone was missing the conversions that mattered, and that spend should wait until a server-side conversion API was in place. That sends the event from your own systems instead of relying on the visitor's browser. The principle holds for any channel where each conversion is rare and costly: instrument the server side before you scale spend.

Most bad tests produce a false pass. Your own browser session already carries an identity, so a click from it looks identified whether or not the link works. Use a private window and a known external contact instead.

Send the test email from that contact's own profile in HubSpot. A forwarded test email prevents enrichment, so you will see nothing and blame the wrong thing. A test contact with no company record will legitimately get no company enrichment, which says something about the test data and nothing about the tracking. Internal addresses will not trigger vendor-side form activity at all.

Then read the answer in the right place. Do not look at a dashboard. Open the contact's timeline and confirm the click and the vendor activity are both there. For vendor integrations, ask the vendor to run a test and send you the address they used, then look that contact up yourself.

Before the send, confirm four things. The record ID token visibly resolves in the editor preview. One test email to a known external contact shows the click and identity on the timeline. The hidden form accepts a submission that contains only an email address. The suppression workflow shows as published, with the customer branch first.

After the send, scan new contacts and their activity each day for the first three days. If something looks wrong on day one, escalate on day one. A missing signal gets harder to repair every day it runs, because every missed touch is a record you cannot reconstruct.

Credit rules are a separate problem with a separate fix. Settle what credit pays, split lead source, channel and owner into their own fields, and only then model multi-touch. None of that works on top of a feed that has quietly stopped. Start tomorrow with one test email to a known external contact, and read the timeline.