What Counts as Offline
Anything that completes outside the measured session qualifies, whether or not a human ever leaves a screen:
- A phone call that closes a sale after a click on a lead form.
- A CRM deal marked won by a salesperson three weeks after the ad click.
- A network conversion posted back to you from a vendor's checkout you do not own.
- A rebill on day 30 of a subscription bought on day one.
- A refund, chargeback or cancellation, which is a negative offline conversion and behaves exactly like the positive kind.
- An upsell taken over the phone, or a payment plan whose second instalment clears a month later.
That last cluster is why this term matters more to affiliates than to almost anyone else. If you promote a network offer, the checkout is on somebody else's domain, the buyer's details are typed into somebody else's form, and the news comes back to you as a postback. By the ad platform's definition, your entire revenue picture past the initial click is a series of offline conversions.
Three Ways They Get Reported
Click-identifier upload. You captured the platform's click ID at the moment of arrival, you stored it, and later you send it back attached to a conversion. Google uses the GCLID for this, along with GBRAID and WBRAID for app and web-to-app paths. This is the highest-fidelity route because the match is exact: one identifier, one click, no probability involved.
Identity upload. You send hashed customer data instead of a click identifier: email, phone, name, address components. Meta's Conversions API works this way, and Google's enhanced conversions for leads does too. The match is probabilistic and depends entirely on how many fields you can supply.
Batch file import. A scheduled upload from a CRM, a spreadsheet or a connector. Mechanically the same as the two above, just slower and less frequent, which as you are about to see is the part that hurts.
The Deadlines Nobody Reads Until They Miss One
This is the section I would tattoo on the inside of every media buyer's eyelids, because every one of these limits is published and almost nobody plans around them.
Google gives you 90 days. Google retains the GCLID for 90 days. An offline conversion uploaded more than 90 days after the associated last click will not be imported and will not appear in your conversion statistics. The maximum conversion window is the same 90 days. Google's own guidance is blunt about the workaround: upload more often, or if the real conversion genuinely happens later than 90 days, import an earlier event that happens inside the window and optimise on that instead.
Meta gives you seven days, and fails the whole batch. The Conversions API accepts an event_time up to seven days in the past. That allowance exists so you can batch a few hours of events for server efficiency, not so you can reconcile a month later. And the failure mode is worse than most people expect: if any single event in a request is more than seven days old, Meta returns an error for the entire request and processes none of the events in it. One stale row poisons the batch.
There is a separate 62-day allowance for events sent with physical_store as the action source, which is Meta's genuine bricks-and-mortar path. It does not cover the affiliate case, and using the wrong action source to buy yourself extra days is not a clever hack, it is a misdeclaration.
TikTok publishes no figure I could find. I checked TikTok's reachable Events API help pages on 2026-08-20. They document the identity signals matched on and they say plainly that late events match poorly, but I found no stated maximum age at which an event is rejected. I am not going to invent a number. Send them promptly and assume the same discipline applies.
The events that decide whether a campaign was actually profitable are the ones most likely to arrive after the upload window has closed.
Why the Late Ones Are the Ones That Matter
Look at that table again and notice which rows fall below the line. The initial sale is the row you already report perfectly, and it is also the row that tells you the least. Whether a campaign made money is decided by the rebill, the upsell and the refund, and those are exactly the rows that arrive after Meta has stopped accepting news.
So the optimisation loop runs on the most incomplete version of the truth available. The platform learns from day one and never hears about day thirty. It keeps buying more people who look like the ones who bought, including the ones who bought and then took the money back, because from where the algorithm is standing those two groups are identical.
One more mechanical trap worth knowing. Google deduplicates on the combination of click identifier, conversion name and conversion time. Re-uploading a corrected row with the same three values does not overwrite the original, it gets dropped as a duplicate. Corrections are their own kind of event with their own handling, not a second attempt at the first one.
How to Not Get Caught by This
Three habits, and none of them require buying anything.
Capture identity while the visitor is still yours. Late events are worth reporting only if they carry match keys. If the only thing you hold is a click ID that expired, the upload has nothing to attach to. An email collected on your own prelander is the difference between a reportable day-30 rebill and a row that gets rejected.
Upload on the day, not on the month. A monthly reconciliation batch is guaranteed to contain events older than seven days, which means it is guaranteed to fail against Meta in whole rather than in part. Daily is the minimum that works. Same-hour is better.
Write down which of your events fall on which side of the line before you build the reporting. If your offer carries a 60-day guarantee, your refunds are structurally unreportable to Meta as offline events, and you need to design around that fact rather than discover it in month four.
So What Do You Do About It
Offline conversions are not an edge case for affiliates, they are the majority of the story, and the platforms buy that story on a deadline. Everything after the first click has an expiry date attached to it, and the expiry has nothing to do with your tracker's retention policy or whose server it runs on.
ClickerVolt was built with that clock in the foreground: the fifteen-field Meta payload exists so a late event still has something to match on, and Refund Sync fires the Google RETRACT, the Meta reversal and the TikTok CancelOrder at the moment the refund posts rather than at the end of the month. You can see how that works here.
Even if you never touch it, do the one free thing this week: open your reconciliation schedule and check whether anything in it batches conversions for longer than seven days. If it does, you are not sending late data. You are sending nothing.
