Offline Conversion Tracking on Meta: Connecting Store Sales to Ads

Offline measurement starts with a confirmed store or phone sale, not a directions click or a scheduled visit. Identify the authoritative POS transaction and the supported dataset/connector before designing an upload. This guide provides a fictional input sheet and acceptance procedure, not a captured upload or a ready-made POS integration.

A minimal illustrative input sheet

For an API-style connector, Meta’s server event contract defines event_time in Unix seconds and includes physical_store as an action-source option. The sheet below models those fields; it is not a universal CSV uploader template. Check the actual connector’s headers, formatting, field nesting, identifier requirements and current acceptance limits.

These hypothetical timestamps are October 2, 2026 at 12:00 and 12:05 UTC, respectively. They represent assumed paid times, not upload times. A direct CAPI body places value/currency in custom_data; a CSV importer may expect different columns and date formats. Add only required, permitted customer identifiers through the connector’s documented fields. This example deliberately contains no real personal data, dataset IDs or access credentials.

Preserve transaction identity in a recovery queue

If C was previously settled and then refunded, retain that history and reconcile the refund under the connector’s supported process; cancellation must not rewrite a genuine earlier payment. Use an outbox or equivalent durable job record so process restarts do not lose the original ID. Select a bounded retry policy from the actual connector limits, not a promised 24–48 hour delivery interval.

An acceptance test after a simulated outage

1. Record A and B in an authorized test ledger. Interrupt A delivery after submission, restart the worker and retry A. Use the same ID and original occurrence time.
2. Submit B with its separate ID and cancel unpaid C before sending. Confirm the ledger contains two paid transactions totaling USD 120.
3. Inspect actual response status, rejected records and platform receipt/deduplication diagnostics. Expected logical outcome is two Purchases; raw submission count may be larger because of retries.
4. Reconcile eligible paid transactions, accepted delivery and distinct receipts over the same timezone and interval. Report delayed, rejected, suppressed and unmatched records separately.

These are proposed assertions, not a test result from your shop. Test permission withdrawal while a job is queued and cancel no-longer-permitted advertising work. Keep operational accounting records under their own obligations; advertising suppression does not necessarily mean deletion of a required receipt.

Do not confuse ad credit with matching or causality

Suppose a hypothetical ledger has 100 store orders and the platform reports 60 attributed purchases. That is not automatically a 60% match rate: eligible coverage, identity, reporting windows and attribution rules can differ. It is also not evidence that the ad caused 60 additional sales. Never sum online and offline credit without checking transaction overlap.

Inspect connector availability, supported dataset, API version and event-age limits before each implementation change. Keep late or rejected events visible instead of replacing their times to force acceptance. Use the CAPI deduplication guide and CRM lifecycle guide for separate identity and stage checks. NovaStorm is not demonstrated here as a POS connector or offline event-delivery service.