Meta discontinued the former Offline Conversions API in May 2025 and directs businesses to upload offline events to a dataset and use Conversions API. A migration therefore needs more than a new endpoint: event meaning, identifiers, consent, timestamps, retry behavior, and source reconciliation must survive the change. This lesson creates that migration record step by step.

VISUAL LESSON

What you will learn

  1. 01Inventory the legacy offline-event pipeline.
  2. 02Design the dataset and Conversions API event contract.
  3. 03Test, reconcile, and cut over safely.
Store, phone, and web outcome signals cross a secure bridge into a unified dataset
A migration succeeds when the source event meaning and audit trail remain intact across the new delivery path.

ILLUSTRATIVE WORKED EXAMPLE

Reconcile an illustrative migration test

Source outcomesVerified business records
500
Eligible to shareGovernance checks passed
455
Accepted eventsPlatform receipt, not attribution
435
Attributed eventsPlatform-modeled campaign view
315
Illustrative example—not a benchmark. Replace every sample value with your own campaign, market, and measurement data.

PRACTICAL INTERFACE MAP

Translate the legacy flow into the current dataset path

Inventory01Document the former pipeline

Capture source systems, event names, schedules, identifiers, transformations, retry logic, and reports.

Dataset02Map the current event contract

Define event time, action source, stable event ID, values, consent state, permitted matching fields, and ownership.

Cutover03Test and mark the reporting boundary

Run labeled events, inspect diagnostics, reconcile source totals, stop the old job, and annotate the transition.

Conceptual walkthrough. Labels, controls, and availability can vary by account, region, plan, and interface version; verify the current screen before acting.

STEP-BY-STEP LESSON

Legacy inventory → dataset contract → API test → reconciled cutover

PreserveOld logic and evidence
TranslateDataset event contract
Cut overReceipts and reconciliation

THE LEAD ATLAS METHOD

Lead Atlas Data can produce a done-for-you business-contact list specific to the campaign’s categories, locations, and market while offline outcomes remain governed in the company’s own measurement systems.See how custom list research works ↗
01

Inventory the legacy offline flow

List every source that produced offline events, including CRM stages, phone outcomes, store purchases, appointments, and imported sales. Record each event name, trigger, source record key, event time, value rule, currency, matching fields, upload schedule, failure queue, retention rule, and downstream report.

Freeze representative exports and logs before changing anything. Identify deprecated jobs, duplicated upload routes, manual spreadsheets, and reports that silently depend on old event-set identifiers so the migration does not leave an orphaned process running.

02

Define the dataset event contract

For each outcome that still matters, specify the current dataset, event name, action source, event time, stable event ID, value, currency, permitted customer-information fields, consent state, source-system key, and owner. Keep early leads, qualified leads, appointments, and sales as distinct business facts.

Use one consistent normalization and hashing specification where the current Meta implementation calls for it. Do not send sensitive notes or repurpose an internal identifier that exposes business or personal data; an event ID should support deduplication and audit without becoming a data leak.

03

Build the governed server route

Choose the approved Conversions API implementation path and document authentication, secret storage, field mapping, batching, rate handling, retries, idempotency, deletion, monitoring, and incident ownership. Apply eligibility and consent checks before an event enters the delivery queue.

Meta states that Conversions API is not a way around privacy rules or platform controls. Treat it as a controlled data processor connection, preserve applicable user choices, and involve privacy, security, and legal owners where the organization’s use requires review.

04

Test receipts, retries, and meaning

Send labeled test events for success, missing identifier, invalid value, delayed outcome, duplicate retry, corrected record, withdrawal, and unsupported data. Preserve request identifiers, sanitized payload evidence, response codes, diagnostics, source records, and the expected platform result.

Reconcile source outcomes, eligible records, attempted events, accepted events, rejected events, deduplicated events, and attributed conversions separately. An accepted event proves processing, not that Meta matched it to a person or attributed it to an ad.

05

Cut over with a marked boundary

Run a controlled overlap only if the design prevents double-counting, then stop and disable the legacy delivery job, verify schedules and alerts, and annotate dashboards with the exact transition date. Compare equal maturation windows and investigate breaks in event volume, values, lag, or qualification.

Deliverable: legacy inventory, preserved exports, dataset register, event contracts, data and consent map, implementation diagram, retry and idempotency rules, labeled test evidence, diagnostics log, reconciliation bridge, legacy shutdown proof, report annotations, monitoring thresholds, and incident owner.

THE TAKEAWAY

Preserve the old process, define one dataset event contract, send only permitted source-of-truth outcomes, test retries and diagnostics, and mark the cutover boundary in every report.

OFFICIAL REFERENCES

Check the platform’s current instructions.

Platform labels, eligibility, and workflows can change. These official help pages were used to validate this lesson.