AdAce AdsChoose a reporting cutoff across advertising account timezones
A portfolio can be extracted at one instant while its accounts are in different local dates. Calling every latest row yesterday produces a report that looks synchronized but is not. Separate the moment you collected the data from the local date represented by each account. Then choose whether the business needs comparable local operating days or a genuinely common elapsed-time window.
An extraction instant is not a reporting date
Two reporting policies answer different questions. A local-day policy selects the same named local date in every account once that date has finished everywhere, with additional maturity and collection checks. A common-instant policy selects observations between two shared instants. The second requires sufficiently granular timestamps; daily local aggregates cannot be split accurately into a different timezone without underlying detail.
Educational example using illustrative fixed offsets, not a timezone conversion rule: at 01:00 UTC on October 4, an account at UTC+2 is at 03:00 October 4, while an account at UTC−7 is at 18:00 October 3. October 3 is complete in the first account but still running in the second. For a same-local-date full-day comparison, October 2 is the latest completed shared date at that extraction instant. October 3 remains provisional until the western account completes it and data collection catches up.
Completion of the local calendar day is necessary but insufficient. Imports may be delayed and conversions can arrive later. A useful cutoff therefore combines calendar completion, observed collection completeness and the selected outcome's maturity rule. Use named timezone identifiers and a date-aware conversion library in implementation; daylight-saving changes can make fixed offsets incorrect. Do not treat this example's offsets as permanent account settings.
Choose the comparison you actually need
- Write the selected local date beside each account subtotal, even when all accounts share the same date label. The reader can distinguish date alignment from a common instant.
- Keep extraction time in a single clearly stated reference timezone. This makes refreshed reports comparable and helps identify data collected at different moments.
- Preserve preliminary rows in a separate monitoring view. They can reveal delivery changes without contaminating a completed-day efficiency comparison.
Apply a reproducible cutoff policy
- List each account's configured reporting timezone, the business reporting timezone and the outcome's date basis. Resolve unknown settings before publishing cross-account daily comparisons.
- Choose local operating days or a common elapsed-time window. Explain the business reason: local sales operations and synchronized incidents may require different policies.
- Convert the extraction instant into each account's local date. Select only completed dates under the chosen policy, then check the last successful collection and conversion maturity.
- Build a coverage table with included dates, excluded dates and the reason for each exclusion. Do not backfill missing full days with the current partial row.
- Publish the cutoff rule and extraction instant with the totals. In AdAce Ads, use available stored timezone and coverage information; if only local daily aggregates exist, avoid claiming a precise common-instant comparison.
Daily aggregates limit precision
- Identical weekday names across accounts do not mean simultaneous trading hours. Choose the view that matches the decision instead of forcing a universal timezone.
- A daylight-saving transition changes elapsed hours in a local day. For rate-per-hour questions, calendar-day totals alone may be inadequate.
- Removing the newest date does not automatically make remaining data final. Conversion delay and collection gaps need separate evidence and labels. Preserve the original account dates when exporting. A translated date heading without a documented timezone policy can make a later reconciliation impossible even when the underlying amounts are correct.
Sources and further reading
Try it on your own accounts
Create a workspace, connect Google or Meta in a couple of clicks and see your accounts clearly. Changes follow your approvals or the policy you configure.
Create your workspace