Skip to content

How ad-comment attribution is measured

We do not model, estimate, or share attribution — if it is not on this list, it is not in your number. Every figure on the ad ledger is a live sum over rows your workspace already owns: comments, replies, clicks, and orders. There is no separate attribution engine and no black box. This page is the whole procedure.

The ledger’s unit is the promoted post — the Facebook or Instagram post an ad drove comments to — not the individual ad. Comments accrue on the post across every ad that ever promoted it, so a per-ad comment count would be invented rather than measured. Every ad that promoted a post is listed under its row.

A tap on a tracked link goes through our own router (edge/link-router), which classifies every visit before recording it:

  • Preview fetches — the platform’s own link-preview crawler, which visits the URL the instant a DM containing it sends — are recorded separately and never counted as a click.
  • Every other visit is recorded as a click, and it is that count, not a raw hit count, that appears on the ledger and feeds attribution below.
  • Repeat taps by the same person are deduplicated within a 10-minute window — one person tapping the same link three times while reading the reply is one click, not three. The same person is identified by the link’s own token together with a keyed hash of the visitor’s IP (we never store the address itself). Both halves are needed: a link inside a public reply carries the same token for every reader of the thread, so the token alone is not a person, and two people tapping that link are two clicks. If the IP hash is unavailable we count the visit rather than merge it — we would rather show one person’s second tap than quietly report a tenth of your traffic.

That is the whole definition, and it is the only click number the product shows: the ledger’s Human clicks column, the Ads this week Home tile, and the per-link count in your link library are all the same count, computed the same way.

An order counts as attributed only when one of these two is present on it. Nothing else — ever:

  1. Discount code. The order’s discount codes include a code minted for one of your tracked links. This attributes the order to the link, always. Placing it on a particular promoted post’s row is a second, stricter question, because one link carries one code and a Workflow may issue that same link on ad comments across several posts — in which case the code cannot say which post the buyer came from. So: when every reply or DM that issued the link in the 7 days before the order was on one post, the order counts on that post’s row. When they span more than one, the order is counted at the link level and left off every post’s Revenue cell rather than assigned to a guess. When the same order’s checkout also carried a UTM token we issued on that same link, the token names the exact comment or DM and we use it, which pins the order to that comment’s post. When the code and the token name different links — a shopper who clicked one of your tracked links and then typed a sitewide code they saw elsewhere — the code wins and the token is discarded rather than merged: a token belonging to another link is not extra detail about this attribution, it is a second, contradicting one, and one row cannot credit two links. Such an order stays at the link level, off every post’s Revenue cell.
  2. UTM token. The order’s Shopify customer-journey data carries a UTM content parameter matching a token we issued, on the last visit before checkout — or, when that last visit was direct (no source, no referrer, no UTM parameters of anyone’s), on the first visit in that journey. If the last visit carried anyone else’s attribution — a Google ad, an email campaign — the order belongs to them and we do not claim it. The matching window is 7 days from issuance, last-click. This attributes the order all the way back to the comment, the DM, and the promoted post that produced it.

When both are present, discount-code evidence wins — it is the stronger signal, and upgrading from token evidence to code evidence never downgrades the other way.

If neither piece of evidence is present, the order is not counted as ours. This is why our number is often smaller than a tool that infers a sale from proximity or shared identity alone: theirs is a claim, ours is a receipt.

ColumnWhat it counts
CommentsComments on the post tagged as coming from an ad — never comments merely near an ad.
QuestionsOf those, the ones classified as a purchase question.
Hidden / deletedModeration actions that actually hid or removed a comment: a platform hide from a rule or the inbox’s hide button, or a delete. A status-only flag that never hides anything on-platform is not counted here.
Answered / median responseHow many of this post’s ad comments got a landed reply, and the median time it took, measured from when the comment arrived to when the reply actually reached the platform, not when we merely decided to send it. This is not a count of questions answered — a reply to any ad comment counts. Inbound DMs are not counted here and this number can never exceed the Comments column: a direct message does not arrive attached to a post, so there is no post to count it on. DMs you sent appear in the DMs sent column.
DMs sentPrivate replies and direct messages whose delivery actually succeeded. A queued, retrying, or failed send is not counted as sent.
Links issued / human clicksTracked links your Workflows or your team issued on these comments, and the human clicks measured above.
Attributed orders / revenueOrders meeting the evidence bar above, and their total value. UTM-token orders always pin to the comment and therefore to the post. Discount-code orders pin to a post only when the link behind the code was issued on a single post in the window (see above); otherwise they are real, attributed orders that this per-post column deliberately does not claim. Per-post revenue is therefore a floor, never an over-count.
SpendRead directly from Meta’s Marketing API for the ads on this post, shown verbatim with the time it was read — dated, not just timed, whenever the read was not today, so a figure carried over from a Meta outage cannot read as this morning’s. Present only once you have opted in to ad comments and Meta has approved the read scopes — until then it is blank, not zero. It is also blank whenever the cached figure was computed for a different date range or a different set of ads than the ones you are looking at: a seven-day spend relabelled as this month’s would be a wrong number, and blank is the honest answer.

Every money figure is shown in the currency it was recorded in — your Shopify store’s for revenue, your ad account’s for spend — never converted. We do not hold exchange rates, and a converted figure would be an estimate, which is the one thing this page promises you will not find here. When a window’s orders span two currencies, or spend and revenue are billed in different ones, the affected total or ratio is blank rather than added up: EUR 40 plus USD 50 is not 90.

  • Attributed revenue ÷ spend — labelled “attributed, deterministic” on every screen it appears on, and never called ROAS without that qualifier. Blank, not zero, whenever spend is not yet known for every post in the window — and when it is blank for that reason, the page says so beneath it (“12 of 20 posts have no spend for this window”) rather than leaving you to guess. One page load refreshes spend for the busiest handful of your promoted posts, so a workspace running many at once will see that message until the rest catch up.
  • Spend under moderation — spend on posts that had at least one Workflow decision in the window they’re being measured over. This is our honest reply to “protected spend”: we show what a Workflow actually touched, not a modelled claim about what harm it prevented.

The ledger is the audit trail summed, not a second system. The two cells that count comments — Comments and Questions — link into your inbox filtered to exactly the rows behind them: the same post, on the same connected page, over the same date range the ledger header names. A page you have since disconnected has no ledger row at all, for the same reason: its comments are not reachable in the inbox, so a number that counted them would open onto nothing. The other columns count effects and events rather than comments, so they are deliberately not linked: a link whose destination held a different set than the number you clicked would be worse than no link at all. If a linked number doesn’t match what you see in the inbox, that is a bug — tell us.