Offline conversions uploaded but not showing: trace the missing checkpoint

If an offline conversion upload succeeds but the Google Ads report is short, trace the missing outcome through the import path before resending it. A connector job, an individual row result, processing diagnostics and an attributed report measure different checkpoints. A successful batch does not settle every row.

This guide covers later CRM outcomes associated with website leads or clicks, including enhanced conversions for leads. For imports matched using caller and call details, use the phone-call import diagnostic. A phone-number tap, connected call, qualified lead and closed sale are different business events.

Identify the path and the conversion owner

Record the connector, import method and current product/API version. Distinguish a classic click import from enhanced conversions for leads, a phone-call import and a website action supplemented by another source. Their requirements are not interchangeable. Write down the destination advertising account, the account that owns the conversion action, and any manager authentication context. A manager login is not the destination action.

For programmatic imports, check the currently supported access route before copying an old upload example. Google’s deprecations page records a June 15, 2026 restriction on offline click uploads for integrations without the required earlier upload history, and directs migrations to Data Manager API. It also records the subsequent sunset of developer tokens. This is not a statement that every established importer stopped working on that date.

If you encounter CUSTOMER_NOT_ALLOWLISTED_FOR_THIS_FEATURE, inspect the applicable feature/access restriction and migration path. Changing the business conversion time, inventing another click ID or repeatedly submitting the same payload does not establish eligibility. Use current access documentation for the actual integration.

Google Ads API access restrictions and unversioned changes; original offline-click import announcement. Checked 3 November 2026.

Build three queues from real results

Keep an opaque CRM outcome ID beside the input row, request/job identifier, destination action, submission time and original result. Preserve repeated attempts as history, then summarize distinct business outcomes separately. If a qualified outcome has no upload attempt at all, inspect the export selection, connector filters and scheduled job first. If a connector only exposes a batch total, that total cannot identify which source rows require repair.

In Google Ads, inspect offline data diagnostics and, for file-based imports, the uploaded file’s results. A green integration card and a warning about another stage can coexist. Read the specific issue, scope and reporting date rather than treating every “Needs attention” label as the same failure.

Google: upload errors, successful uploads and reporting discrepancies. Checked 3 November 2026.

Check the outcome, identifiers and actual event time

• Business event: a qualified-lead action should receive the qualification outcome you defined. Keep an enquiry, qualified lead and sale distinct; do not relabel all stages as new leads to increase a total.
• Matching information: inspect the identifiers and permitted first-party fields actually captured for this path. Preserve click IDs exactly when available. Do not reconstruct a missing GCLID from an IP address, invent customer fields or paste private customer data into a public troubleshooting tool.
• Website-to-CRM continuity: for enhanced conversions for leads, review the supported tagging and user-provided-data setup as well as the later import. A later file cannot prove that the earlier website collection worked. Preserve consent choices and follow the selected method’s field preparation rules.
• Time: use when the business outcome actually occurred, with the correct time zone or offset. Source event time, original ad interaction, upload time and review time are different fields. Correct a documented time-zone mapping error; do not move the event to another day merely to clear a diagnostic.
• Identity and retries: keep the supported order/transaction identity stable and check the actual destination action. A new timestamp or new ID can create another event instead of repairing the original. Use the duplicate-conversion guide for action boundaries.

Google notes that enhanced-conversions-for-leads uploads can include outcomes from other channels, so some “Unknown clicks” results can be expected. That does not make every unknown-click warning harmless. If all rows are affected or attribution is unexpectedly low, inspect capture and implementation instead of ignoring the queue.

Enhanced conversions for leads implementation checklist; unknown-click and upload diagnostics. Checked 3 November 2026.

Align the report before declaring outcomes lost

Standard Google Ads conversion reporting organizes attributed outcomes by the original impression or click date. Use the appropriate by conversion time columns when comparing with a CRM’s business conversion date. Upload date is another basis; do not compare a day’s uploads directly with a day’s ordinary campaign conversions.

Keep the account time zone, conversion action, campaign filters, date range and review cutoff with the export. Include the original interaction period where relevant. Check Conversions versus All conversions, the action’s One/Every setting and the actual selected campaign goal. A secondary action can still affect bidding through a selected custom goal; the conversion-signal diagnostic covers that distinction.

Allow the documented processing interval for the actual import method and identifiers. Google’s troubleshooting page describes delays and longer processing for some braid-keyed imports. This is a reason to record and revisit the cutoff, not a guarantee that waiting will fix a bad mapping. Accepted uploads can still be affected by counting and conversion filtering.

A campaign-level aggregate does not identify which individual CRM rows Google attributed or filtered. Keep that uncertainty visible. The numerical difference is not a count of bots, rejected customers or necessarily lost conversions.

Google: reporting dates, processing and count behavior; conversion-time reporting columns. Checked 3 November 2026.

For a change that lines up with a banner release, check consent behavior and Ads reporting alongside your row results.

Run a local upload-ledger exercise

This fixed synthetic SQLite example has six source outcomes, five qualified outcomes and six upload attempts for that cohort. The labels accepted, error and pending belong to our review ledger; they are not Google API enums. The selected report value is a separate supplied aggregate. It is not calculated from the attempts or assigned to any individual outcome.

Download the local upload-ledger SQL, save it in your working folder and run:

python3 - <<'PY'
import sqlite3
from pathlib import Path
connection = sqlite3.connect(':memory:')
setup, report = Path('offline-upload-ledger-demo.sql').read_text().split('-- BEGIN REPORT\n', 1)
connection.executescript(setup)
for metric, value in connection.execute(report):
    print(f'{metric}: {value}')
PY

-- Fixed synthetic operational ledger. Not a Google upload/report parser.
-- 'accepted', 'error' and 'pending' are our review labels, not API enums.
-- A separately supplied aggregate report cannot identify individual outcomes.
CREATE TEMP TABLE source_outcomes (
  outcome_id TEXT PRIMARY KEY,
  qualified INTEGER NOT NULL CHECK(qualified IN (0,1))
);
INSERT INTO source_outcomes VALUES
  ('outcome_1',1), ('outcome_2',1), ('outcome_3',1),
  ('outcome_4',1), ('outcome_5',0), ('outcome_6',1);
CREATE TEMP TABLE upload_attempts (
  attempt_id INTEGER PRIMARY KEY,
  outcome_id TEXT NOT NULL,
  review_state TEXT NOT NULL CHECK(review_state IN ('accepted','error','pending'))
);
INSERT INTO upload_attempts VALUES
  (1,'outcome_1','accepted'), (2,'outcome_1','accepted'),
  (3,'outcome_2','error'), (4,'outcome_3','pending'),
  (5,'outcome_4','accepted'), (6,'outcome_6','accepted');
CREATE TEMP TABLE report_snapshot (metric TEXT PRIMARY KEY, supplied_value TEXT);
INSERT INTO report_snapshot VALUES ('selected_report_conversions','1.00');

-- BEGIN REPORT
WITH qualified_attempts AS (
  SELECT a.* FROM upload_attempts AS a JOIN source_outcomes AS s
    ON s.outcome_id = a.outcome_id WHERE s.qualified = 1
), outcome_states AS (
  SELECT outcome_id,
    MAX(review_state = 'accepted') AS has_accepted,
    MAX(review_state = 'error') AS has_error,
    MAX(review_state = 'pending') AS has_pending
  FROM qualified_attempts GROUP BY outcome_id
)
SELECT 'source_outcomes' AS metric, CAST(COUNT(*) AS TEXT) AS value
  FROM source_outcomes
UNION ALL SELECT 'qualified_outcomes', CAST(COUNT(*) AS TEXT)
  FROM source_outcomes WHERE qualified = 1
UNION ALL SELECT 'qualified_upload_attempts', CAST(COUNT(*) AS TEXT)
  FROM qualified_attempts
UNION ALL SELECT 'accepted_attempt_rows', CAST(COUNT(*) AS TEXT)
  FROM qualified_attempts WHERE review_state = 'accepted'
UNION ALL SELECT 'distinct_outcomes_with_acceptance', CAST(COUNT(*) AS TEXT)
  FROM outcome_states WHERE has_accepted = 1
UNION ALL SELECT 'error_without_acceptance', CAST(COUNT(*) AS TEXT)
  FROM outcome_states WHERE has_error = 1 AND has_accepted = 0
UNION ALL SELECT 'pending_without_acceptance_or_error', CAST(COUNT(*) AS TEXT)
  FROM outcome_states WHERE has_pending = 1 AND has_accepted = 0 AND has_error = 0
UNION ALL SELECT metric, supplied_value FROM report_snapshot;

Review the actions alongside the upload evidence

Use the sample or paste the read-only conversion-action export into the browser audit. It can flag supplied action settings and overlapping paths. It does not inspect your live connector, match a click, validate customer fields or fetch processing results. Use the actual campaign configuration for goal decisions absent from the export.

Make one traceable fix and verify the next outcome

Download the offline-import review worksheet. Record the first failed checkpoint, evidence, owner, scoped correction and rollback. Retest an appropriate supported outcome, inspect its actual row result and diagnostics, then revisit the same report scope after processing. Keep unresolved records rather than forcing them into a matched total.

OFFLINE CONVERSION IMPORT REVIEW
Internal review checklist, not a Google upload format or automatic submission.

IDENTIFY THE PATH
Classic click import / enhanced conversions for leads / phone-call import:
Connector and API/product version; current supported access model:
Target advertising account / actual conversion-owning account / manager context:
Exact destination action resource or identifier; intended qualified/converted stage:
Current API access restriction checked if applicable; no credentials in this record:

FREEZE THE COMPARISON
Business outcome cohort and qualification rule / source export timestamp:
Actual business conversion time with UTC offset; source/account time zones:
Original interaction period when known / upload time / review cutoff:
Conversions versus All conversions; standard versus by-conversion-time columns:
Selected campaign/action filters / goal membership / counting option:
Aggregate reports cannot identify which individual CRM rows were attributed.

TRACE THE ATTEMPT
Opaque internal outcome ID and stable deduplication identity:
Captured click identifiers when available; provenance, not reconstructed values:
Required permitted first-party fields and path-specific formatting verified:
Consent signals preserved; do not paste customer fields into public troubleshooting:
Request/job identifier, original input row reference, destination and submission time:
Per-row result/error/warning; transport success versus final processing evidence:
Later attempt status, actual retry policy and destination diagnostics:
Do not invent a new conversion time or identity to force an old upload through.

INVESTIGATE THE GAP
Explicit failed rows to repair:
Pending or incomplete results to revisit at a stated cutoff:
Distinct business outcomes with documented accepted results:
Repeated attempt rows kept separate from unique outcomes:
Missing/unavailable matching data or unsupported scope:
Reporting date basis, attribution scope, processing and counting reviewed:
Unresolved facts and owner; avoid labelling the gap as fraud or lost customers:

CHANGE AND VERIFY
Specific fix, affected connector/action, owner and rollback:
One supported test outcome followed through row results and diagnostics:
Before/after export dates, remaining unresolved issues and processing review time:
Actual selected campaign goals and custom-goal membership checked separately:
Billing and visitor protection are separate from import success and attribution.

For enquiry validation and local retry handling, use the server acceptance guide. For mixed reporting definitions, use the conversion reconciliation guide. Website protection and billing questions require their own evidence.

AdProtektor adds observed-visit context and configurable protection. Review ConversionOS only against the event paths and destinations actually supported by your chosen integration; its presence does not establish a working CRM import, accepted upload or attributed conversion. Keep the delivery owner, destination diagnostics and qualified-outcome definition explicit.

Once reporting is stable, use the qualified-lead goal worksheet to check volume and conversion delay before a bidding change.

If the original conversion counted and its count or value is wrong, use the Google Ads conversion adjustment guide.

Start a free AdProtektor trial to review the supported visitor-protection and event workflow for your site.

For phone calls with no captured website click identifier, use the call-attribution path guide to select the supported native or provider workflow.

For identifier provenance and an optional client-account lookup, use the GCLID evidence guide. Keep a returned account record separate from the current request, billing and business qualification.