Skip to main content
Connectors do not all behave the same way. Some pull data live from the source every time a dashboard loads; others store a daily snapshot and refresh it on a schedule. Knowing how a connector behaves explains why Meta Ads data and BigQuery data on the same dashboard can feel like they update at different speeds, and why a refresh sometimes takes a few hours to reflect. Two dimensions describe how any connector works:
  1. How data is stored — cache-based (Adriel keeps a copy) vs. live query (Adriel asks the source every time)
  2. How data is refreshed — the four refresh patterns described further down

​
How most connectors store data

Most Adriel connectors are cache-based — Adriel maintains an internal copy of the data and refreshes it on a schedule. Database connectors are the exception — they query the source live every time a dashboard loads. Within cache-based connectors, what happens when Refresh is clicked varies:
  • Cache-only — the dashboard always serves the most recent cached data, even after clicking Refresh. The next scheduled refresh cycle is the next opportunity to see new data.
  • Cache-based with on-demand refresh — clicking Refresh triggers a fresh pull from the source platform between scheduled cycles.
Most Adriel connectors are cache-only, because their source platforms either rate-limit API calls heavily or require asynchronous report polling that takes too long to run on demand. Cache-only platforms include, for example, X (Twitter) Ads, DV360, Snapchat Ads, Reddit Ads, Amazon Ads, Pinterest Ads, TikTok Ads, Naver Search Ads, Kakao Moment, Moloco, Walmart Ads, Amazon DSP, Yahoo Japan, Yahoo DSP, LINE Ads, Naver GFA, and Criteo Retail Media. For day-to-day reporting on a cache-only connector, this means the schedule is the schedule. To see updated numbers, wait for the next scheduled cycle. The dashboard’s Refresh data button still works — it re-runs widget queries against the cache — but it does not reach back to the source platform.

​
How connectors refresh — the four patterns

Independent of caching, connectors also vary in how they pull and store data over time. There are four patterns. Each connector follows one of them.

Live query

The connector queries the source platform every time the dashboard loads. Numbers always reflect the source’s current state. Used by database connectors.

Daily refresh with backfill

One row per day is stored. A scheduled job re-pulls the most recent days on every refresh cycle to capture late-arriving updates. Most ad platforms use this pattern.

Snapshot replace

A single snapshot per data source. Each refresh replaces the previous data in one swap. Used for sources that do not change day-by-day — for example, uploaded files, reference data, audience lists.

Combined snapshot + daily

Both patterns at once. Reference tables refresh on a short cycle; performance data sits in a daily-refresh cache. CallRail is the textbook example.

​
Pattern 1: Live query

Used by database connectors — for example, BigQuery, PostgreSQL, Redshift, and MySQL. Every widget render triggers a fresh query against the source database. Nothing is cached on Adriel’s side beyond a short-lived result cache to avoid running the same query twice within a few minutes. What to expect: numbers always match the source database. The trade-off is that each dashboard load runs queries against the source, so query latency depends on the database. See: BigQuery, PostgreSQL, Redshift.

​
Pattern 2: Daily refresh with backfill

Most ad-platform connectors use this pattern. One row is stored per day. A scheduled refresh runs once or twice a day at fixed UTC times. Every refresh re-pulls a rolling window of the most recent days so that late-arriving conversions and platform corrections flow through automatically. Three settings shape a daily-refresh connector’s behavior: What to expect: data for a completed day usually stabilizes within hours of the day ending in the platform’s account time zone. Today’s row keeps updating on each refresh cycle until the day closes. Examples: Meta Ads and Google Ads refresh on a daily cycle with a 30-day rolling window. Naver Search Ads refreshes twice daily with a guaranteed 12-month history.

​
Pattern 3: Snapshot replace

When data is not naturally partitioned by day — for example, a CSV file imported from Amazon S3, a sheet pulled from Google Sheets, or an audience list — the connector stores a single snapshot per data source. Each refresh replaces the previous data in one swap. Replacement happens in one of these ways depending on the source:
  • Full replace — All rows are written to a temporary table, then swapped in as a single operation. A failed refresh leaves the previous snapshot intact, so partial data never shows up. This is the default for snapshot-style sources.
  • Add and update by unique ID — New rows are added; existing rows are updated by their unique identifier. Used when the source returns only changes since the last fetch.
  • Source-managed — The connector decides how to apply the update, used in unusual cases where the source has its own update semantics.
  • Multi-table fan-out — A single source file is split into multiple tables based on row-level metadata.
What to expect: data is as fresh as the last successful refresh. A failed or partial fetch never corrupts the previous snapshot. Examples: Google Sheets, CSV File Import, Amazon S3.

​
Pattern 4: Combined snapshot + daily

Some connectors mix Patterns 2 and 3. Reference data (entity lists, settings, metadata) is stored as a snapshot and replaced on a short cycle. Performance data (calls, sessions, etc.) is stored as a daily refresh with backfill. The dashboard joins the two at query time. Example: CallRail keeps companies, form submissions, trackers, and tags as a snapshot refreshed every 4 hours. Call records use the daily refresh pattern — they refresh once daily at 02:00 UTC, re-pulling the trailing 5 days each time, with a 90-day initial backfill.

​
Refreshing data manually

Two manual-refresh paths exist:
  1. Dashboard header → Refresh data re-runs the widget queries against the existing cached data. It does not pull fresh data from the source platform.
  2. Connection settings → Refresh tab triggers a fresh pull from the source platform for the selected data source. This option is available on cache-based connectors that support on-demand fetches. Cache-only connectors do not show this option, and a few others — for example, Amazon S3 — disable it.
Once a manual refresh is queued, the Refresh tab updates its status every 15 seconds.

​
Troubleshooting

Cache-based connectors refresh on a fixed schedule, so today’s row reflects the last completed refresh. Wait for the next refresh cycle, or trigger a manual refresh from the connection’s Refresh tab if it’s available. For database connectors, today’s data should match the source immediately on every dashboard load.
Three common causes: (1) the connector is cache-only and the previous scheduled refresh already pulled the latest data the platform exposes; (2) the source platform has not finalized today’s totals — most platforms close a day shortly after midnight in the account’s time zone; (3) the refresh is queued but not yet processed. The Refresh tab updates job status every 15 seconds.
Initial backfill depth varies by connector — 60 to 180 days is typical. See the connector’s page under Data Sources for its specific initial backfill window.
Conversion data can update inside each platform’s attribution window (commonly 7 to 30 days). The rolling refresh window on daily-refresh connectors is sized to recapture those updates. Days outside the rolling window are not re-pulled automatically and stay fixed unless a manual refresh covers them.
Cache-only connectors like TikTok and DV360 aggregate daily snapshots. Reach and Frequency are unique metrics: one person reached across multiple days is counted once by the platform but summed by day in Adriel, so period totals appear inflated. For example, a TikTok Reach of 48M in Adriel versus the platform’s deduplicated 21M for the same range.Adriel shows an asterisk next to Reach with a tooltip explaining this.Related limitations:
  • TikTok Organic does not support page-level Reach at all — only Post Reach.
  • DV360 Unique Reach: Average Impression Frequency became unusable when DV360 migrated to cache-only.
  • The TikTok Overview widget’s Reach tile is mapped to Post Reach (Delta), which is the change in reach versus the prior day. It can legitimately be negative when yesterday’s reach was higher than today’s.
Several data sources and breakdowns are scoped to a rolling 90-day window:
  • Teads only caches the last 90 days on data-source creation. Earlier data requires a manual backfill.
  • The Creative Image breakdown only supports the last 90 days across all channels. Earlier date ranges return no data.
  • Ad-level + daily breakdown on Meta only supports the last 90 days. For longer ranges, use a monthly breakdown.
  • Manual refreshes of Pinterest Organic Page Analytics can fail for dates earlier than 90 days because Pinterest’s own API only exposes 90 days.
A newly launched campaign can simply have no performance data on the reported day. Once data arrives from the platform and the next refresh runs, the campaign appears in the widget. This is expected data delay, not a filter or configuration issue.
Related: Time zones & data freshness · Data history & retention