In this guide
A campaign generates hundreds of form submissions, but the sales team rejects many as unsuitable. Feeding a later lead milestone back to the advertising platform can make reporting more useful. It can also create a new source of confusion if “qualified” means something different every week.
Offline conversion imports connect a recorded business outcome, often from a customer relationship management system, with advertising activity. The useful part is the outcome definition. The upload is only the transport.
Choose a milestone that the business can apply consistently
Separate form submission, accepted lead, qualified opportunity, and completed sale. Each is a different stage, and one person may pass through several.
Write down who changes the status, what evidence they use, and when the stage is considered complete. Avoid importing a temporary working status that sales staff routinely reverse without recording the change.
For example, “qualified” might require a valid enquiry, serviceable location, and a confirmed need. That is an illustrative business rule, not an industry standard. The right definition should reflect the actual sales process.
Decide whether the signal is for reporting, bidding, or both, and review the platform’s configuration accordingly. Do not let adding a new milestone silently change the campaign’s optimization objective.
Preserve the event time
Keep the time the milestone occurred separately from the time it was exported and uploaded. Include the required time-zone information.
A lead accepted on Monday and uploaded on Wednesday should not become a Wednesday business event merely because the batch ran late.
Google’s offline conversion import guidance documents eligibility and duplicate handling for its import methods. Confirm the limits and required identifiers for the integration being used instead of assuming every platform accepts the same history or matching fields.
Track the batch all the way through
Build a small reconciliation record for each import:
- Source records eligible for export.
- Records excluded, with reasons.
- Records submitted to the destination.
- Records accepted or rejected, with response details.
- Records subsequently visible in the relevant report.
Suppose a batch starts with 100 eligible leads, excludes eight because required fields are missing, and submits 92. If 87 are accepted and five rejected, there are two different follow-up queues. Reporting “92 uploaded” hides both.
An accepted record is not automatically an attributed conversion in every report. Match availability, attribution rules, processing, and the selected reporting columns still matter.
Keep identifiers stable and access controlled
Use the platform’s documented identity and event fields. Keep an internal record ID to reconcile the source, but do not expose personal details through URLs, campaign names, or shared spreadsheets.
Apply the organization’s approved data-sharing and consent requirements. Hashing a field is not permission to send it.
Make retries traceable. A failed batch should be retried using the same underlying event identity where the integration requires it, rather than generating a new event each time. Follow the documented duplicate rules for that destination.
Define how corrections travel back
A qualified lead may later be identified as a duplicate. A sale can be canceled. Decide which corrections the destination supports and who is responsible for sending them.
Keep the original event and correction history in the reconciliation record. Do not “fix” a rejected timestamp by inventing a different occurrence time.
Google’s conversion upload documentation also explains that reporting dates can follow the attributed interaction rather than the upload date. Check the report’s time basis before comparing it with a CRM daily total.
Begin with a small reviewed batch and prove the complete path. A dependable lead signal should remain understandable from the source status through the final report, including the records that did not make it.
AdOpsNow Editorial
Examples use illustrative data. See our editorial standards or report a correction.