Google Ads

Data Manager API Offline Conversion Timestamp Window Audit

HandL WP Engineering·Jul 4, 2026

Offline conversion uploads need the right event time, lead stage time, time zone, click identifier, and upload timing. If those fields drift, Google Ads may reject the row or match it to the wrong business event.

Use this for WordPress lead forms, CRMs, call tracking, booking systems, and sales teams that send qualified lead, closed won, or disqualified lead outcomes back to Google Ads.

Quick answer

Data Manager API Offline Conversion Timestamp Window Audit should be handled with a narrow evidence-first workflow: map timestamp fields, normalize timezone, check window rules, then verify the result before making broader changes.

What to check first

Record the original form submission time, click ID capture time, CRM stage time, and upload time in one timezone.
Check whether the uploaded conversion action expects click identifiers, enhanced conversion user data, or both.
Confirm late-stage conversions are still inside the allowed upload and lookback window for the account setup.
Normalize daylight saving time, CRM local time, UTC storage, and spreadsheet exports before building upload rows.
Save rejected rows and partial failures with row numbers so fixes do not hide other valid conversions.

Diagnostic table

Use this table to keep the work practical. It connects the symptom to evidence and a verification step.

Action	Evidence to collect	How to verify
Map timestamp fields	Record the original form submission time, click ID capture time, CRM stage time, and upload time in one timezone.	Each upload row has a named timestamp source and timezone.
Normalize timezone	Check whether the uploaded conversion action expects click identifiers, enhanced conversion user data, or both.	Rejected rows show row-level reasons instead of only a batch failure.
Check window rules	Confirm late-stage conversions are still inside the allowed upload and lookback window for the account setup.	Google Ads receives the intended conversion action, value, and time.
Log partial failures	Normalize daylight saving time, CRM local time, UTC storage, and spreadsheet exports before building upload rows.	CRM lead stage counts reconcile against uploaded accepted rows.

Why this usually happens

The website stores form times in local time while the CRM exports UTC or another office timezone.
The upload uses the qualification date but Google Ads expects the original conversion time for matching.
Click IDs expire or disappear before the sales team marks the lead qualified.
Partial failures are not logged, so one bad timestamp is mistaken for a broken API.

Field notes

Store both raw timestamps and normalized timestamps during the first audit. It makes timezone mistakes visible.
Do not overwrite the original form submit time when the CRM stage changes.

Useful command or data shape

Adapt paths, IDs, and privacy handling to the site before running commands or storing data on production.

offline_conversion_row:
  lead_id: GF-8842
  gclid: CjwKCA...
  form_submitted_at_utc: 2026-07-03T19:42:11Z
  qualified_at_utc: 2026-07-04T14:08:00Z
  upload_at_utc: 2026-07-04T14:20:00Z
  conversion_action: qualified_lead
  timestamp_source: crm_stage_change

Safe fix order

Do the work in a sequence that makes each result easy to prove. Stop if a step produces new evidence that changes the incident scope.

Map timestamp fields
Normalize timezone
Check window rules
Log partial failures
Reconcile uploads

What to tell the client or owner

Tell the marketing owner which timestamp should drive bidding and which timestamps are only operational notes.

Production verification checklist

Each upload row has a named timestamp source and timezone.
Rejected rows show row-level reasons instead of only a batch failure.
Google Ads receives the intended conversion action, value, and time.
CRM lead stage counts reconcile against uploaded accepted rows.

Mistakes to avoid

Do not judge the fix by one browser or the homepage only.
Do not delete evidence before recording usernames, file paths, timestamps, and response headers.
Do not add a cache, security, or tracking plugin while the original problem is still unclear.
Do not leave test users, temporary debug logs, or broad API keys active after verification.

When HandL WP should help

Bring in help when this affects leads, checkout, search visibility, malware risk, paid media reporting, or a client production site. HandL WP can trace the issue through WordPress, hosting, cache, tracking, and Search Console, then verify the workflow after the technical fix.

If this is active on a production site, fix Google Ads conversion tracking for WordPress leads.

Related HandL WP guides

Use these related guides when the same issue touches tracking, security, checkout, or crawler visibility.

Helpful references

Google Ads Data Manager API Conversion Tracking