Meta Ads Attribution Windows

Attribution windows define which conversions Meta credits to which ads. Two changes in 2025-2026 affect pipeline outputs: the June 2025 on-Meta/off-Meta attribution split, and the January 2026 window deprecations. Pipelines built before these changes that have not been updated will produce incorrect warehouse numbers.

How Attribution Windows Work

An attribution window defines the time period after an ad interaction during which Meta will credit a conversion to that ad. The interaction can be a click (the person clicked the ad) or a view (the person saw the ad without clicking).

When a conversion event fires — a purchase, a lead form submission, an app install — Meta looks back through the attribution window and asks: “Did this person interact with one of our ads?” If yes, that conversion is credited to the ad.

The window sizes matter enormously because different window lengths capture different conversion volumes. A 28-day click window captures every purchase made within 28 days of clicking an ad. A 7-day click window captures fewer conversions for the same ad spend, making the 28-day version appear more effective.

The Windows That Survived January 2026

Meta deprecated the 7-day and 28-day view-through attribution windows on January 12, 2026. The remaining attribution windows:

If your pipeline requested 7d_view or 28d_view before the deprecation, it either broke or silently fell back to Meta’s defaults after January 12. Check your extraction logs.

The surviving windows give you reasonable coverage for most use cases: 7d_click is the industry standard for most campaign types, 1d_view is useful for upper-funnel awareness campaigns, and 28d_click is useful for categories with long purchase cycles (B2B, high-consideration purchases).

The June 2025 Attribution Split

This is the change that caught most pipelines unprepared. Meta now attributes conversions differently based on where the conversion occurred:

• On-Meta conversions (lead form submissions, Messenger conversations, Instant Experience interactions) → attributed to impression time
• Off-Meta conversions (website purchases via Pixel, app installs via SDK, Conversions API events) → attributed to conversion time

There is no opt-out. The split is enforced automatically.

What this means in practice

Before June 2025, all conversions were attributed to impression time. A purchase happening on Tuesday that was attributed to a Monday ad click showed up in Monday’s data. After June 2025, that same purchase shows up in Tuesday’s data (conversion time) while a lead form submission still shows up in Monday’s data (impression time).

If your pipeline compares on-Meta and off-Meta events in the same chart — comparing lead form leads to website purchases for the same campaign — those numbers now use different attribution timestamps. Mixing them in an aggregate “conversions” column without documenting this is a source of confusion for anyone who tries to reconcile the warehouse against Ads Manager.

Handling the split in your transformation layer

Two options:

Option 1: Keep them separate. Don’t aggregate on-Meta and off-Meta conversions together in your intermediate models. Create separate columns and document the attribution basis for each.

-- Clear separation in the intermediate model
SELECT
  date_start,
  campaign_id,
  -- Off-Meta: attributed to conversion time
  purchases AS off_meta_conversions,
  purchase_value AS off_meta_conversion_value,
  -- On-Meta: attributed to impression time
  lead_form_leads AS on_meta_conversions
FROM {{ ref('int__meta_ads__actions_pivoted') }}

Option 2: Combine with documentation. If your mart needs a single conversions column for cross-platform comparison, document the mixed attribution basis in the model description and accept that the number is an approximation.

Either way, if you’re analyzing data that crosses the June 2025 boundary, treat it as two different measurement methodologies. A trend line from January 2025 through December 2025 has a methodological break in the middle that will look like a change in performance even if nothing changed in the campaigns.

Specifying Windows in API Calls

This is the most frequently missed configuration: if you don’t specify action_attribution_windows in your API request, Meta uses its defaults. The defaults don’t necessarily match what Ads Manager shows, which is one of the main causes of warehouse-versus-UI discrepancies.

Always specify windows explicitly:

params = {
    'fields': 'impressions,clicks,spend,actions,action_values',
    'action_attribution_windows': ['7d_click', '1d_view'],
    'time_increment': 1,
    'level': 'ad',
}

The windows you specify determine which conversions appear in the actions array. An ad with 7d_click may show 15 purchases; the same ad with 28d_click may show 22 purchases. Both are correct — they’re just measuring different windows.

Align with Ads Manager by checking which windows your team uses in the Ads Manager interface and matching them in your API calls. If Ads Manager shows 7-day click attribution and your pipeline requests 28-day click, the numbers will never reconcile.

Retroactive Data Updates and Lookback Windows

Attribution data updates retroactively. A purchase today may be attributed to an ad impression from 7 days ago. That means yesterday’s data is not final — it will change as the attribution window fills in.

The update window varies by conversion type:

• Most standard conversions: 3-7 day update period
• AEM (Aggregated Event Measurement) conversions: up to 72 hours additional delay before they appear in the API at all
• Off-Meta events sent via Conversions API: additional delay depending on server processing time

For a pipeline, this means you can’t treat any recent data as final. The standard defense is a lookback window: on every sync, re-pull the last 28 days and overwrite stale numbers with updated attribution.

28 days is conservative. For most campaigns, 7 days covers the bulk of retroactive updates. But for Conversions API implementations with AEM, 28 days is safer because the full attribution picture takes longer to settle.

Managed tools like Fivetran handle this automatically. Airbyte requires explicit configuration of the lookback window. If you’re building custom extraction, you build it yourself — and it’s non-trivial because you need to decide whether to overwrite, merge, or track historical snapshots.

Data Discrepancies vs. Ads Manager

Your warehouse will never exactly match Ads Manager. Accept a small variance and focus on trend accuracy rather than exact reconciliation. The main sources of legitimate discrepancy:

1. Attribution window mismatch — your API request and the Ads Manager view use different windows
2. Timezone differences — Ads Manager shows data in the ad account’s timezone; your warehouse likely stores UTC
3. Reporting delay — data can take 1-72 hours to finalize
4. Modeled vs. actual data — post-iOS 14.5, Meta increasingly uses statistical modeling to fill attribution gaps; modeled numbers update as more signal arrives
5. CAPI deduplication — if you’re sending events through both the Pixel and Conversions API without matching event_id values, you’ll double-count conversions in your raw data before they’re deduplicated by Meta

The Reach-to-Viewers rename is also coming. Meta is replacing the “Reach” metric with “Viewers” by end of June 2026. If your dashboards or dbt models reference the reach field by name, plan for that migration before the rename takes effect.

A variance of 5% or less between warehouse and Ads Manager is normal and not worth investigating. A variance of 15%+ on a consistent basis indicates a pipeline configuration problem — start with attribution window alignment and work down the list.