View-through attribution: why Meta and your data disagree

We recently dug into a sale that looked, at first, like a tracking bug.

Our tracker had the whole visit on record. The buyer arrived through the link in the brand's Instagram bio, landed on the sales page, went to checkout and paid. One session, one clear origin.

Meta's Ads Manager credited the same purchase to a static image ad. As far as the site could tell, that ad never sent anyone: no session carried its click, no UTM of its own, nothing on the landing page.

Then the buyer added a third version: later on, they mentioned that the purchase was made on a computer.

• Our tracker: the sale came from the Instagram bio.
• Meta: the sale belongs to a static ad.
• The buyer: the sale happened on a computer.

The reflex is to decide which one is lying, and acting on that reflex costs money. It's how ads that were working get paused, and how ads that only happened to be near a sale keep getting budget. Nobody in this story is lying. Each source answers a different question, using a different piece of the journey, and once you see which piece each one holds, the three answers fit.

This article takes that sale apart: what Meta's attribution counts in 2026, how an ad earns credit without producing a visit, why that doesn't require an fbclid, where the second device comes in, and what a tracker on your own domain should and shouldn't try to do about it.

Three questions that look like one

Most of the confusion comes from treating three different questions as one.

Where did the session that converted come from? This is what a first-party tracker, one that runs on your own domain, can observe: the referrer, the UTMs, the click IDs, the landing page. If the visit that ended in a purchase came in through the Instagram bio, recording "Instagram bio" as its origin is correct. It doesn't mean the bio was the person's first contact with the brand. It means that's where this session started.

Did this person interact with one of our ads inside the attribution window? That's Meta's question, and it's a different one. An ad can get credit for a conversion without having produced the session in which the conversion happened. Meta doesn't need the ad to have sent the visit. It needs an eligible interaction between that person and that ad, inside the window the ad set uses.

Would the sale have happened without the ad? That's causality, or incrementality, and neither of the first two answers it. If someone was shown an ad and bought eight hours later, that can be enough for view-through attribution. It doesn't prove the sale depended on the ad. Meta draws the same line itself: in the same March 2026 announcement that changed its attribution, it calls incrementality experiments, like its own Conversion Lift, the best way to answer that question.

So when Meta, GA4 and your own tracker show different origins for the same purchase, that isn't evidence of a bug. Usually it's evidence that you are reading three answers to three questions.

What Meta's attribution counts in 2026

Take a campaign optimizing for purchases on your website. In 2026, under Meta's Standard attribution model, its setting usually combines three windows:

• 7-day click-through: the person clicked a link in the ad and converted within seven days.
• 1-day engage-through: the person clicked the ad anywhere other than a link (a like, a comment, a share, a save) or watched at least five seconds of a video, and converted within a day.
• 1-day view-through: the ad was shown to the person, with no interaction at all, and they converted within a day.

The middle window is new. Until March 2026, click-through counted any click on the ad, so someone who liked it on Monday and bought on Friday could show up as a click-through conversion. In March 2026, Meta changed the definition for website and in-store conversions: click-through now means a link click, and every other click moved into what used to be engaged-view attribution, renamed engage-through, with its own one-day window. Video views live in that same bucket, and Meta has lowered the bar for an engaged view from 10 seconds to 5. The rollout was gradual, so some accounts may still show the old labels.

Two consequences matter for everything below:

1. A conversion credited to an ad that sent no session is not automatically a view-through. It can be a link click from days earlier, an engagement, or a view.
2. These windows don't only shape the report. Meta says Standard attribution optimizes delivery for the windows and behaviors you select, so they also shape who gets to see the ad.

How an ad gets credit for a sale it never sent

Two timelines make it concrete.

A click from earlier in the week.

Monday    → clicks the ad, looks around, leaves
Thursday  → types your address and comes back
Thursday  → Purchase

Thursday's session is direct. Meta credits the ad as a click-through conversion, because there was an eligible link click three days before the purchase. Both are right about what they describe.

A good first-party tracker does something similar within a single browser. Supreme, for instance, lets a visit that comes back direct within seven days inherit the origin of the last visit that had one, so Thursday's purchase lands on Monday's campaign. The limit is in the words "a single browser". Keep them in mind for the section on devices.

An impression a few hours earlier.

14:00 → the ad is shown in the feed
17:00 → the person looks the brand up and opens its profile
17:05 → taps the link in bio
17:15 → Purchase

Your tracker sees Instagram bio → Purchase. Meta holds one more fact, one your site never received: this person was shown ad A at 14:00. If Meta can connect the purchase to that person, ad A can take the credit as a view-through conversion.

The ad producing a session is simply not a requirement. That is the part that breaks the intuition of anyone used to reading attribution as "who sent the visit".

Why view-through needs no fbclid, and what fbc really is

The usual objection at this point: the ad never generated an fbclid, so how could Meta tie it to the sale?

It didn't need one. An impression happens entirely inside Meta's infrastructure, where the platform already records something like person X was shown ad Y at time Z. Nothing has to reach your site for that record to exist. View-through attribution doesn't depend on an fbclid or an fbc attached to the impression, because an impression produces neither.

fbc is a click identifier. It starts when someone clicks a link inside a Meta app and the URL arrives at your site carrying ?fbclid=…. The site stores it in the _fbc cookie, and your server can later send it with the event through the Conversions API. The value follows a documented format, fb.1.<creation time>.<fbclid>. Meta's documentation explains how to build it from the fbclid when there's no cookie, and Meta publishes a small library, the CAPI parameter builder, that builds it for you.

Two details matter more than they look.

fbclid doesn't mean paid traffic. Meta's documentation only describes it for ad clicks, but that isn't the only place it shows up. Since late 2018, people have reported it on links shared organically on Facebook, and technical glossaries list it on organic traffic from Instagram, Messenger and Threads. Treat those cases as observed rather than documented. Either way, an fbclid, or an fbc, tells you the visitor clicked a link inside a Meta app. It doesn't prove they clicked an ad. To know whether a visit was paid, you need parameters you control: UTMs on every ad. The UTM builder shows which channel each link will land in before you publish it.

The number in the middle is the click's time. Meta's documentation defines it as the moment the _fbc cookie was saved or, if you don't keep the cookie, the moment you first saw the fbclid. A server that rebuilds fbc only when the purchase arrives, say from a checkout webhook two days after the click, is telling Meta that the click happened at the time of the sale. Whatever Meta does with that timestamp, it is working from a wrong fact. It's an easy mistake: our own Node made it on server-side purchases until version 3.7.1, in September 2026. Since then, it only builds an fbc from an fbclid for events recorded in the browser during the visit, and otherwise sends the fbc it actually observed.

The second device

The buyer's remark, that the purchase was made on a computer, is where most first-party explanations stop working and Meta's keeps going.

Meta's privacy policy says it collects and receives information from and about the different devices you use, and that combining that information across your devices is part of how it helps businesses measure how their ads performed. The policy's own example is a phone-to-laptop journey: an ad shown on your phone, then a click and a purchase from your laptop. A tracker restricted to your domain has nothing like it. For your site, the phone's browser and the computer's browser are two different visitors, unless something ties them together, like a login.

PHONE      person X → is shown ad A
              ...later...
COMPUTER   person X → your site → Purchase

Your site may never hold a single identifier proving those two browsers belong to the same person. Meta may hold several. What travels with the purchase through the Conversions API is what gives Meta the chance to try:

• email and phone, normalized and hashed;
• external_id, a stable ID you assign to the visitor;
• IP address and user agent, in plain text, as Meta asks for them;
• fbc and fbp, the click and browser identifiers.

Meta's own Event Match Quality guidance rates email and the click ID as high-priority identifiers, and the browser ID, external_id and phone as medium.

None of these is an impression. They are signals Meta uses to recognize who made the purchase. Once it knows who, it can look up what that person was shown and clicked, on any device where they use Meta's apps.

Reconstructing the sale, carefully

Here is a plausible reconstruction of the case from the top. Plausible is the operative word: from outside Meta, nobody can see which signal decided this particular match.

1. On the phone, the person is shown static ad A.
2. Later, they open the brand's Instagram profile.
3. On the computer, they click the link in bio. An fbclid may come along with the click and become an fbc.
4. On your site: bio, landing page, checkout, Purchase.
5. Your server sends the Purchase through the Conversions API, with the customer information it has.
6. Meta ties the purchase to person X.
7. Meta finds an eligible impression of ad A inside the window.
8. Ad A gets the credit.

If the impression happened within a day of the purchase, this is exactly what 1-day view-through describes.

What's documented: fbc can be built from an fbclid; the Conversions API accepts it together with email, phone, IP address, user agent, fbp and external_id; Meta says it combines information across devices; and Meta keeps its own record of which ads it showed to whom.

What nobody outside Meta can claim: that the bio's fbc was the identifier that linked the computer to the phone, or that it was decisive at all. The honest version is that the fbc may have contributed to the match, together with the other identifiers the Conversions API carried and whatever Meta already knew about that person.

There's one more trap in this story. The bio click may well have produced an fbclid, but it wasn't a click on the static ad. Since March 2026, click-through for website conversions requires a link click on the ad itself. So the same purchase can carry an organic click on the bio, which explains the session, and a view-through credit to the ad, which explains the ad's number. Two different facts about one sale.

A received event is not an attributed event

A server-side tracker has two jobs here: capture the event correctly and deliver it correctly. Attribution happens after that, on Meta's side, and it's a separate problem.

A Purchase that Meta received is not automatically a Purchase that Meta attributed. Events sent through the Conversions API are processed like Pixel events, but Meta still has to connect each one to a person, and then find an eligible ad interaction for that person inside the configured windows. Meta's own Event Match Quality documentation ties the two together: it's the matched events that help you attribute conversions to your ads. Some purchases clear both steps. Others don't.

That's why improving the identifiers you send can raise the purchases in Ads Manager without raising your sales by a single unit.

Say you have 100 real sales. Before, Meta connects and attributes 55 of them. After you fix the data your server sends, it attributes 70. Sales: still 100. What grew was Meta's ability to match. That has value: a conversion Meta can't tie to anyone teaches its delivery very little, so better matching gives it more to learn from. But the first effect is on the report, not on the bank account. When a vendor tells you their tool "increased conversions by 30%", ask which number they mean: Ads Manager's, or your store's.

The same logic explains why platforms don't split your sales among themselves. Meta credits by Meta's windows, Google by Google's. The same purchase can be claimed by both, legitimately, each under its own rules. Add up what every platform reports and you can easily end up above your real sales. And the same sale reads differently depending on where you look:

How many sales you made comes from your store or your checkout. Attribution tells you who is claiming credit for them.

How to investigate a sale like this in Ads Manager

When a result shows up on an ad that doesn't seem to have sent anyone, don't guess. Open Compare attribution settings, or break the results down by attribution setting, and see which window the purchase fell into. The labels vary from screen to screen (Meta calls the middle bucket "engagement" in some places and "engage-through" in others), but the buckets are these:

Then set it next to what your tracker recorded for the same purchase: the session's origin, whether it carried an fbclid, and the buyer's earlier visits. Between the two, you get a much more confident answer about which mechanism produced the credit.

Remarketing is where view-through deserves the most skepticism

View-through needs special attention in remarketing. Someone who already knows the brand, is on your list, got your email or your WhatsApp message, or was going to buy anyway, is exactly the person most likely to be shown an ad and then buy a few hours later through some other channel.

Meta can credit that sale to the impression even if the ad changed nothing. That isn't Meta cheating: the model is doing what it says it does. It is also why attribution and incrementality have to be read separately, and on warm audiences most of all. If the question is "is this remarketing paying for itself?", the tool is an incrementality test with a holdout group, like Meta's Conversion Lift, not the attribution column.

What your tracker should do, and what it shouldn't pretend to

A first-party tracker will never reproduce Meta's attribution, and it shouldn't try. It doesn't have the impressions, the history of interactions inside Instagram and Facebook, the logged-in identity, or the cross-device graph. A tool that promises to match Ads Manager is either copying Meta's number or inventing one.

What it can do is keep both sides honest:

• Capture the sale and tie it to the session that produced it, including purchases your checkout platform confirms outside the browser, whenever the buyer can be recognized.
• Keep the click identifiers with the right time. Store the fbclid and fbc observed at the click and send the real ones with the purchase, instead of manufacturing a new fbc when the sale arrives.
• Send customer information the way Meta asks for it. Email and phone normalized and hashed, IP address and user agent in plain text, a stable external_id. Hashing the IP protects nobody; it only makes the field useless for matching.
• Check that Meta actually ingested the event. An HTTP 200 isn't proof. Meta's response says how many events it received, and a 200 with zero received is a failure that should be reported as one.
• Put both readings on one screen, and label them. Meta's conversions next to the revenue your own records tie to each ad, with the understanding that they measure different things.

That's how we built Supreme. The Node runs on your server, under your domain, and keeps the session, the click identifiers and the purchase in your own database. It sends the purchase to Meta through the Conversions API, records a delivery as failed when Meta answers OK but ingests nothing, and keeps Meta's trace ID and warnings for when you need them. In the Console, Insights → Meta Ads shows Meta's own numbers next to the revenue your Node measured, per ad, once your ads carry their ID in utm_content. The two readings sit side by side instead of competing, and now you know why they won't match.

What can be proven, and what can't

Your tracker knows what happened on your property. Meta knows what happened inside its apps, and who the person probably is. The buyer knows the rest. The Conversions API is the bridge that lets Meta attribute a journey your site could never reconstruct on its own, and the reasonable goal is for each side to be right about its own half.

Want to see both readings on one screen? Install your first Node, free and without a credit card, then connect your Meta ad account.

Sources

• Meta's March 3, 2026 announcement on click-through and engage-through attribution — Meta for Business
• Attribution settings: click-through, engage-through and view-through — Meta Business Help Center
• Event Match Quality — Meta Business Help Center
• Privacy Policy: information from and across the devices you use — Meta
• Conversions API — Meta for Developers
• The fbp and fbc parameters — Meta for Developers
• Customer information parameters — Meta for Developers
• CAPI parameter builder — Meta, on GitHub
• Meta Business SDK for Ruby — server-side UserData
• How Meta Ads Attribution Works in 2026 — Jon Loomer
• Click-Through Attribution Now Requires a Link Click — Jon Loomer
• Meta Ads Attribution Reporting: What Your Results Really Mean — Jon Loomer
• fbclid on an organically shared link, October 2018 — Hacker News discussion
• What Is fbclid? — AffBuddy (secondary source for organic fbclid)