Preserve event time through queues and time zones

Event time records when an action occurred. Receipt time records when your service learned about it; send time records when it forwarded the event. Keeping all three makes a delay measurable. Replacing the original moment with the current clock removes that evidence.

For a conversions API integration, check the exact field requirements of the destination and event type. This guide uses Meta's documented rules as a scoped example, not as a common contract for every platform.

Separate the three timestamps

Take one transaction and compare the source record, queued job and outgoing payload. Identify the unit at each stage and retain the original time-zone information if the source supplies a local date string.

If only a reporting date remains, do not invent the missing hour and offset. Mark occurrence time unresolved and request the source record. The event delay guide covers the wider delivery investigation.

Apply Meta's age rule to the correct event type

Meta defines event_time as the actual event's transaction time in Unix seconds. Its API guide states that it can be up to seven days before sending. Under that rule, an older value anywhere in the request's data array causes the entire request to fail.

The same passage separately says to upload offline and physical-store transactions with physical_store as action_source within 62 days of conversion. Keep that provision separate from the seven-day rule. It does not authorize relabeling a website event as a store event: Meta requires action_source to be accurate.

Before a backfill, classify events by their actual source and validate the relevant age condition. Separate questionable records so one stale item does not block an otherwise eligible batch. Inspect the response rather than assuming separation guarantees acceptance. See the age-limit error guide for the related diagnostic path.

Convert local time without changing the moment

A local date string without an offset may be ambiguous. Around daylight-saving changes, some local times repeat and others do not occur. A server's default zone is not evidence of the zone used by the source.

Prefer an unambiguous source timestamp. If conversion is required, use the source's stated zone and the rule applicable on the event date. Record the input and the resulting value so a reviewer can reproduce the transformation. Check seconds versus milliseconds separately from the zone conversion.

Use several diagnostic examples: an ordinary day, a date near a daylight-saving change where applicable, and a delayed event. A timestamp that appears on the expected calendar day is not enough; compare the actual instant. When the only available timestamp comes from a network, the CPA postback guide helps define the source contract.

Keep acceptance, deduplication and attribution separate

Meta's deduplication guide describes corresponding browser Pixel and server events. The recommended method matches the Pixel's eventID and event name with CAPI's event_id and event_name. The guide describes a 48-hour receipt boundary for matching those browser/server copies.

It also describes an alternative using the event name with fbp and/or external_id. That method has its own ordering and source limitations, including a browser-first condition and no deduplication of browser-only or server-only copies. Do not turn either passage into a guarantee that every server retry before 48 hours is safe or every later retry is counted again. Keep an integration-level resend policy; see retries and idempotency.

Google Ads adds a different set of checks for offline imports: upload deadlines after the associated click and a separately configured conversion window. The conversion-time reporting column also differs from reports grouped by another date. None of those settings should be used to reconstruct or overwrite the original event time.

Verify the repair with a traceable record

Record the original value, the source zone or offset, the queued value, the outgoing value and the receiver's result. If a retry changes only send time, the original occurrence time should remain available. If a timestamp changed, document the conversion that caused it.

For TikTok or another destination, verify the current schema, units and age rules for the exact event workflow before sending a backfill. Do not borrow Meta's seven-day or 48-hour numbers. If the required rule is not established, leave it unresolved.

After correcting a time-zone bug, inspect how affected historical records will be handled before replaying them. A corrected timestamp does not by itself establish eligibility, deduplication or attribution. Keep the original record and a reason for any correction so the reporting difference can be explained.

Sources