Which POS Lets You Track Marketing Revenue? What the Integration Must Prove

Square and Toast both publish native sales reporting for marketing or loyalty activity, while Feast documents POS-linked campaign sales for restaurants using Toast, Square, or Clover. The best POS for restaurant marketing tracking is not the one with the longest list of reports; it is the one that can join a campaign response to an identified guest, a verified in-person visit, and a paid, non-voided settled check without losing transaction status.

If you already use one of those systems, test the data path before you consider switching. A POS can record the sale, but you still need a distinct campaign identity and a defensible matching rule; this is the difference between a sales report and the full attribution work a restaurant marketing company may need to do.

Tracking route	What current official pages document	What it can answer	What it cannot answer by itself
Square's native loyalty and marketing tools	Square documents loyalty-attributed sales and promotion performance.	Which sales Square labels loyalty-attributed and, separately, how Square reports loyalty-promotion performance	Whether every outside ad, organic post, reservation, or walk-in caused a sale
Toast's native marketing reports	Toast documents marketing-driven-sales reports and a Demand Attribution Dashboard.	Which sales Toast attributes to activity represented in its marketing reports, including reported guest segments	Profit, causal lift, or a complete identity path from every outside source
A third-party campaign-to-POS connection	Feast says its campaign page captures guest identity and that later payments using the same phone identity can be matched in supported Toast, Square, and Clover systems.	Which POS-linked sales match the third party's own campaign records	Anonymous walk-ins, unmatched cash checks, another person paying, profit, or incrementality

These are different products answering different questions. Native reporting starts with activity the POS already knows. Third-party attribution starts with an outside campaign response and tries to connect that person to the restaurant's transaction record.

The overlooked requirement is identity before revenue

Marketing revenue can be matched only when the campaign and the check share a usable identity or another unique key. An ad impression, click, reservation, loyalty account, seated party, cover, order, and check are not interchangeable records.

Write the chain you expect the system to preserve:

Campaign response: the guest takes a distinct action tied to one campaign, such as completing a form or claiming an offer.
Identified guest: the response creates an identity the restaurant is allowed to use and the POS or attribution system can recognize later.
Verified in-person visit: the restaurant records the arrival and completed service independently of payment.
Settled check: the POS records the final paid transaction, including whether it was later voided or refunded.
Campaign match: the system links the check to the campaign identity and retains the source and transaction state.

The identity requirement creates a real blind spot: the person who responded may dine, but a friend may pay. That leaves a completed visit without a check linked to the original guest unless the workflow records the relationship another way. Cash creates the same problem when no usable guest identity is attached to the transaction.

Reservations add another unit. A reservation record belongs to a party, covers count seats, a guest record identifies a person, and a check records payment. If one guest books for four people and another guest pays, calling all four people “attributed customers” would turn one partial match into four invented ones.

Square and Toast can both report sales, but their starting points differ

Square offers a documented native route for a restaurant already using Square. Its current pages say Customer Directory carries purchase history, loyalty status, visit frequency, and purchase behavior across Square channels, while the loyalty product reports loyalty-attributed sales and promotion performance. That supports Square-owned loyalty and promotion analysis; it does not make Square the source of truth for every outside marketing channel.

Toast also publishes native marketing attribution. Its support documentation lists marketing-driven-sales reports and a Demand Attribution Dashboard that separates attributed sales among new, active, and reactivated guest segments. For a deeper treatment of that boundary, see what Toast can and cannot say about where customers came from.

Before buying access, write down the exact Toast report and export you need. The Toast marketing add-on cost guide keeps that separate buying decision from the question of what the report proves.

Clover enters this decision differently. Feast's current pages list Clover among its supported POS systems, but a support claim does not prove that Clover, Toast, and Square expose identical identifiers, history, or transaction states through every configuration. If you use Clover, require the attribution vendor to run the same acceptance test against your live setup instead of treating a logo on an integration list as the finish line.

Native reporting and third-party attribution need different labels

The report label should tell you how close the number is to the check and what remains unproven. Use four labels consistently:

Platform-attributed sales: the POS or ad platform assigned sales under its own rules. Useful, but the report must disclose the rule and eligible activity.
Directly matched sales: a person-level campaign record joined to a paid, non-voided settled POS check. This is stronger evidence of a recorded match, not proof that the campaign caused the purchase.
Observed lift: sales, covers, or visits moved during a period. Seasonality, menu changes, capacity, service, and other marketing may also have moved.
Incremental contribution: a controlled or otherwise defensible estimate of what the campaign added after costs. This requires more than a match.

Two systems can both claim the same sale under different attribution windows or identity rules. One agency reported conflicting results when Toast and a reservation platform each ran campaigns and claimed conversions. Keep each system's number in its own labeled column until you reconcile the guest, visit, and check rather than choosing whichever report looks better.

A matched dollar is still gross or net sales as defined by that report. It is not profit. It is not causal lift. Those conclusions need their own math and evidence.

Make the vendor prove a paid check before you sign

An end-to-end acceptance test should create the exact successful state you plan to buy, then prove that reversals disappear. Run it with a documented test campaign and a staff-approved transaction:

Create one campaign with a unique response path that does not reuse an existing in-store code. A restaurant that reused the same POS offer code for an old lunch special and a Feast campaign left staff unable to tell the transactions apart.
Complete the campaign action with a designated test identity and confirm that the system records the source.
Record an in-person arrival separately. Do not let the matched check retroactively serve as the only proof that the visit occurred.
Pay a real test check and leave it paid, non-voided, and settled long enough for the promised reporting process to run.
Confirm that the check appears under the correct campaign with the correct amount and transaction ID or another auditable reference.
Void or refund the test transaction only after the positive match has been observed. Confirm that the report removes or reverses it rather than preserving false revenue.
Repeat the test with cash and with a different person paying. Record those as known gaps unless the vendor demonstrates a valid way to link them.

Definition of done: you can start with the campaign record, find the visit, find the settled check, see its current payment state, and reproduce the same path in an export. If the vendor can show only a total sales number, you have reporting—not a check-level audit trail.

Measure match coverage before trusting the total

Check-match coverage tells you what share of eligible completed visits actually reached a known POS result. Choose one fixed reconciliation window before the test.

Check-match coverage = eligible verified completed-visit events with a linked paid, non-voided settled check ÷ the exact eligible verified completed-visit events whose full reconciliation window elapsed and whose matched-or-unmatched outcome is reconciled and known.

The numerator is the successful subset of that denominator. Hold early matches out until the rest of their cohort receives the same full window. Report open, immature, ineligible, and unresolved visit records separately; do not improve the rate by dropping the hard cases or count unknowns as failures.

Keep the supporting scorecard in exact units:

Record	Unit and treatment
Campaign responses	Unique identified people by campaign; shared or unattributable responses stay separate
Verified completed visits	In-person visit events, established before check matching
Mature known match population	Eligible completed-visit events after the fixed reconciliation window, separated into matched and unmatched outcomes
Check-match coverage	Matched completed-visit events divided by that exact mature known population
Matched checks	Paid, non-voided settled transaction records; do not relabel them as people or visits
Matched sales	Net settled sales under the written report definition, with refunds and voids removed
Excluded states	Open, immature, ineligible, and unresolved visits; failed joins; cash or different-payer gaps; voids and refunds

Turn matched sales into a restaurant decision

Matched sales become useful only after you compare them with the cost of producing those checks. Use one ledger and count each cost once:

Matched campaign contribution = matched net settled sales − variable costs of the matched checks − allocated campaign costs.

Variable check costs include applicable food, packaging, payment processing, fulfillment, and incremental service labor. If the offer includes a reward, use its actual incremental food and fulfillment cost inside those variable costs once. Because net sales already reflect a discount, do not subtract the discount's face value again.

Campaign costs include applicable media, creative production, influencer compensation, content licenses or usage rights, software or agency fees, and campaign-specific labor not already counted in service labor. Allocate shared charges to the test with one written basis, such as the share of the billing period or campaigns served, and do not add a subtotal beside the components that already produce it.

If matched sales are strong but contribution misses your prewritten floor, the POS connection may be working while the campaign economics are not. If responses are recorded but verified arrivals are weak, fix the action-to-visit step. If arrivals are healthy but match coverage is poor, repair identity capture, staff handling, or the POS join before buying more traffic. If the report preserves voids or refunds as revenue, stop relying on it until transaction-state filtering is fixed.

The same chain applies when you track restaurant sales from Facebook and Instagram ads; the campaign source changes, but the check still has to settle.

Feast matters when the POS is only one piece of the chain

Feast is relevant when you need the campaign response, guest identity, follow-up, and POS-linked campaign sales connected across Toast, Square, or Clover—not merely another native POS report. Its current pages document that flow while limiting the defensible result to POS-linked campaign sales; profit needs the cost ledger above, and incrementality needs a stronger test design.

If you want to test that complete response-to-check path on your current setup, book a demo of Feast.