Contents 11
Two cost layers do not appear automatically. They overlap only when the marketplace charges the seller its fee for the sale and the seller separately pays Meta for traffic to that same product page. With no advertising, there is one layer. If the sale closes on the seller's own storefront away from the marketplace, there is no marketplace fee on that particular transaction. Measurement is the harder part: it depends on whether the seller controls the code of the destination page or has an agreed technical integration. Meta separately documents links that can point to third-party retail sites (site links to third-party retail destinations), but that page does not confirm seller access to measurement on such a site.
What "paying twice" means in unit economics
The phrasing is colloquial, so it is worth translating into the language of calculation. The seller has a gross margin per unit. Out of it comes everything the marketplace withholds for the fact of the sale, and separately everything spent on the paid traffic that brought the buyer to that page. The question is not "twice or once" but whether enough remains after both deductions for the transaction to make sense. Both layers exist at the same time only under two conditions together: the marketplace charges the seller for the sale and the seller pays for Meta traffic.
This is a seller-side audit method, not a platform rule. It is worth calculating in three modes: a sale on the marketplace with no advertising, a sale on the marketplace with paid traffic, and a sale on the seller's own storefront with paid traffic. In the third mode there is no marketplace fee, while payment acceptance, logistics and support become direct seller costs or separately visible line items; their composition depends on the marketplace model. So "saving on commission" does not equal a margin gain until those line items are accounted for.
A second element of the calculation often drops out: repeat purchases. If a buyer acquired through advertising later returns on their own, the cost of the first acquisition spreads across a larger volume. But the seller can only see this with access to data on repeat orders. Without that access, the calculation has to run on a single transaction, and that is a deliberately conservative estimate rather than a fact.
In the working spreadsheet, do not mix actual amounts with assumptions. Mark the marketplace fee, ad spend, cost of goods, logistics, returns and the contribution of repeat orders separately. Note the data source for each row. If a repeat purchase cannot be tied back to the first acquisition, do not credit it to advertising. Such a calculation does not settle the attribution question, but it does show where the conclusion rests on records and where it rests only on a model.
Who owns the destination page
Start the audit with ownership of the page and the data. Meta documents links that can point to a third-party retail site (site links to third-party retail destinations). That confirms only the existence of the described configuration: no conclusions about measurement access or about the rules of a specific marketplace can be drawn from that page.
Before planning measurement, the seller should record in writing the answer to two questions: can they modify the code of the destination page, and does the marketplace offer an agreed integration for passing events. This is an editorial audit method, not a Meta requirement. Technical access differs between marketplaces, so a claim along the lines of "marketplaces always block measurement" is not supported by sources.
Objective, conversion location and event have to line up
Meta describes objective selection as a choice made for the business goal of the campaign (choosing an ad objective). It separately documents that after the objective is chosen, you set the conversion location and the event that delivery optimizes toward (conversion locations and events). These two configuration levels need to be checked against each other.
First establish which outcome you can actually observe, and only then pick the objective and an available conversion location with the corresponding event (conversion locations and events). If the final order happens somewhere you receive no event from, do not claim optimization toward or measurement of that order without a separate integration. The sources cited do not support the claim that any particular objective measures sales on a third-party marketplace by itself.
If reporting is built on clicks and landings, it is traffic reporting. Calling it sales reporting is not acceptable, and comparing cost per click with product margin to draw a conclusion about effectiveness substitutes one kind of data for another. Sales in that case are reconciled against the seller's own accounting system or against data received from the marketplace.
Meta Pixel: the conditions under which first-party events are possible
The Meta Pixel is set up on your site and sends browser events from your pages; the documentation covers installing and configuring the code on the site (Meta Pixel get started). This requires control over the page code or an agreed way to place it.
If the seller cannot modify the code of the destination page and the marketplace provides no integration, first-party browser events from that page will not arrive. Optimization and audience-building scenarios that rely specifically on those events are then unavailable until another permitted data source appears. Where control or an agreed integration does exist, measurement capability depends on correct setup and on the set of events being passed.
Conversions API: a server-side channel where an integration exists
The Conversions API connects marketing data from your servers and systems with Meta and supports server-side event integrations (Conversions API). This is relevant to the seller only when an authorized technical integration exists and there is a lawful basis for processing and transmitting the relevant data.
Both conditions are verified outside Meta: the first in technical documentation or in the contract with the marketplace or developer, the second with a lawyer and in the personal data processing policy. This is a seller-side audit and legal control requirement, not a platform statement. If neither condition holds, the architecture should be built on the assumption that the final outcome stays outside the system, rather than on hope that the channel will appear later.
Which audiences remain when there are no site events
Custom Audiences is a targeting option that lets you reach people who have already interacted with the business (about Custom Audiences). Documentation separately covers the implementation in which an audience is built on Meta Pixel data through the Marketing API (Pixel and the Marketing API).
An audience built on Pixel events needs those events, so it is unavailable where the Pixel is not installed and there is no other agreed source for them. This material does not list other source types without supporting documentation; instead, the audit compiles a factual list of what is available in the specific account, confirmed in Events Manager and in the audiences interface.
An empty audience does not prove the creative is fine
An empty audience based on site events gives no grounds for ruling creatives or bids out of further checking. Such a list may indicate that events from that source did not reach the available audience, but on its own it explains nothing and is not a diagnosis.
The causes can differ, and until they are checked, each remains an audit hypothesis: there is no access or no technical means to place measurement on the destination page; events are not being sent or are going somewhere else; the wrong dataset is being checked; the data is thin or filtered; there is some other configuration error.
Creative, offer, delivery and bidding strategy are checked separately and with the campaign's own data. An empty segment says too little about them. If the seller sees a high cost per click and weak engagement under the ad, that is material for a creative review regardless of whether the audience is populated.
Three traffic architectures
| Architecture | Who owns the destination page | What is actually available for measurement | Main limitation |
|---|---|---|---|
| Straight to a product page on a third-party marketplace | The marketplace | A documented link configuration to a third-party retail site; available metrics must be checked in the account (site links) | First-party browser events require control over the page code (Pixel) |
| Own storefront with a subsequent handoff | The seller | Events on the seller's own site through the Pixel (Pixel) and audience building on that data (Marketing API) | The final order may happen off the seller's site; that extra step has to be measured separately |
| Server-side integration | Jointly, by agreement | Server events through the Conversions API where an integration exists (CAPI) | Requires an authorized integration and a lawful basis for processing data; this is the seller's check, not Meta's |
A decision frame
Start with the question of whether a confirmed technical channel exists for returning final orders to Meta. If it does, the third architecture can be assessed on the merits, and the conversion location and event can be chosen with the actually available measurement in mind (conversion locations and events). If it does not, check whether the seller has their own page that they control and where they can place the Pixel code (Pixel). If they do, the second architecture yields first-party events but adds a step between the ad and the final product page. If neither of the two is present, the first architecture may be the practical one. In that case the audit treats Meta data only within the delivery and click metrics actually available, and reconciles sales against whatever system the seller has access to.
At the outset, also test whether the product margin holds up under both cost layers in a pessimistic scenario with no repeat purchases. If it does not, more precise measurement by itself will not change the arithmetic of the deal.
Audit: a step-by-step check
- Record who owns the destination page and whether the seller has the technical ability to place code on it, since that is precisely the
conditionfor browser events to work (Pixel). - Ask the marketplace whether an agreed integration for passing events exists, and record the answer in writing. This is a seller-side audit step.
- Check in Events Manager which datasets are connected to the ad account and which events actually arrive, before drawing conclusions about empty audiences.
- Reconcile the business goal with the chosen objective (choosing an ad objective), and the objective with the available conversion location and event (conversion locations and events).
- Compile a factual list of the custom audiences available to you in the account (about Custom Audiences), flagging separately the ones built on Pixel data (Marketing API).
- Check whether server-side event transmission is possible (Conversions API), and separately obtain a legal opinion on the basis for processing that data.
- Check whether the link configuration to a third-party retail site that Meta documents is suitable for your ad format and destination (site links to third-party retail destinations). Do not carry conclusions about measurement over from that page.
- Calculate unit economics in the three modes from the earlier section, including payment acceptance, logistics and support costs in the own-storefront mode.
- Assess creative, offer, delivery and bids separately using the campaign's own metrics, without inferring anything about them from the state of the audiences.
- Describe which metric counts as the result in each architecture, and do not mix traffic metrics with sales metrics in one report.
Final checklist
- It is clear who owns the destination page and who has access to its code (Pixel).
- The suitability of the Meta-documented link to a third-party retail site has been checked for the chosen format and destination (site links to third-party retail destinations).
- The objective is chosen for the business goal (choosing an ad objective), and the conversion location and event match what is genuinely measured (conversion locations and events).
- The list of available custom audiences is compiled from what is actually in the account (about Custom Audiences), with a separate marker for those that rely on Pixel data (Marketing API).
- The feasibility of server-side event transmission is established before launch (Conversions API), and the lawful basis for processing the data is confirmed by a separate opinion.
- The two cost layers are treated as a conditional situation: the marketplace fee plus the seller's own traffic spend.
- Margin is tested in a scenario with no repeat purchases.
- Creative and bids have their own review procedure, independent of the state of the audiences.
- Reporting distinguishes delivered traffic from confirmed orders that the seller can see in the system available to them.