Skip to main content
Three behaviors together explain why a dashboard number can differ from the source platform’s own interface: which time zone is used for each row, when daily totals close, and which days remain eligible for updates.

​
Which time zone does each connector use?

By default, each connector uses the time zone configured on the connected ad account. When data is pulled from a connector such as Google Ads, Meta Ads, or LinkedIn Ads, the platform returns rows already aggregated to its account-level time zone, and the connector stores them as-is. A few connectors behave differently:
  • Amazon Ad Server reports always use US Eastern time, regardless of the account’s configured time zone. This is required by the source API for historical date ranges.
  • Pinterest Ads normalizes the reporting window to UTC before requesting data.
  • Adjust requires choosing a UTC offset at connection time. That offset applies to every report.
  • Reddit Ads parses each event’s hour stamp from the ad account’s time zone, then stores the row in UTC so that cross-account aggregations align.
For multi-account dashboards, each row keeps its account’s time zone. A “Friday” line item in a US Eastern account and a “Friday” line item in a Tokyo account refer to overlapping but different clock windows. This is intentional — it matches what each platform shows in its own interface.

​
When does each day’s data become final?

Most ad platforms close out daily reporting shortly after midnight in the account’s time zone. Until that happens, today’s row keeps updating on each refresh cycle. After the day closes, the row is generally stable, with two caveats covered below. There is no separate “finalization” step inside Adriel. Data is whatever the source platform’s API returns at the moment of fetch.

​
Refresh cadence

Cached connectors refresh on a fixed schedule, typically once or twice per day at specific UTC times. A few examples: Database connectors — for example, BigQuery, PostgreSQL, Redshift, or MySQL — have no refresh schedule at all — data is read directly from the source on every dashboard load. See Refresh strategies for the full pattern map.

​
Why historic days can still change

Two mechanisms drive late updates:
  1. Conversion attribution windows. A click today can be attributed to a conversion that fires up to 30 days later. Most marketing connectors default to a 30-day attribution window; some are platform-specific (Facebook Ads runs 1-day and 7-day windows by default plus optional 28-day; Walmart exposes 3, 14, and 30 days; Pinterest is user-configurable from 0 to 60 days).
  2. Rolling refresh window. Cached connectors re-pull a rolling window of the most recent days on every refresh (typically 3 to 30 days), so platform restatements inside that window flow through automatically. Days outside the window stay fixed unless a manual refresh covers that range.
For Facebook, Instagram, LinkedIn, TikTok, and X organic connectors, audience and post metrics are snapshots taken once per day. Meta in particular can revise lifetime performance up to 48 hours after the fact, which sometimes shows up as a negative day-over-day delta. See Organic connectors: Delta vs lifetime metrics for the underlying math.

​
Troubleshooting

Three common causes: (1) the platform has restated the day inside its attribution window — the next refresh will pull the new value; (2) the platform uses a different time zone than expected — confirm the account’s time zone in the source platform; (3) for Amazon Ad Server, every row is reported in US Eastern time, which can shift day boundaries against a non-US account.
Expected. Today’s row is incomplete until the day closes in the account’s native time zone, and the connector refreshes today’s row on every scheduled refresh.
The row was inside the connector’s attribution window or its rolling refresh window when the refresh ran. To freeze the number, export it from the connection’s data view once the relevant attribution window has fully closed.
Each connector preserves the account’s native time zone. A row labeled “2026-06-15” in a Tokyo account covers a different 24-hour clock window than a “2026-06-15” row in a New York account. Use a single account, or convert to UTC in a custom metric, if cross-account alignment matters.
Related: Refresh strategies · Organic connectors: Delta vs lifetime metrics · Data history & retention