Facebook & Meta Ads Data Challenges — The Enterprise Reconciliation Playbook

Your Meta spend reports two different numbers for the same campaign — the Ads Manager UI says one thing, the Marketing API returns another, and neither reconciles with GA4. Monday's dashboard moves again by Friday. iOS conversions arrive as statistical estimates, not events. For brands running six- and seven-figure monthly budgets on Meta, this isn't an edge case; it's every Monday morning.

The discrepancies aren't random. They're the predictable output of Meta's attribution windows settling asymmetrically, breakdowns that can't be combined, Aggregated Event Measurement erasing signal, and a Conversions API that deduplicates on parameters Meta won't fully document. Agencies layer one more failure mode on top: every Business Manager is per-client, and Meta's API has no native concept of an agency book of business.

Below, nine structural Meta data problems — plus the tenth problem agencies own alone — with the root cause, the exact API or privacy mechanism behind each, and the reconciliation pattern that makes the number defensible when finance or the client asks.

Why Meta Data Is Structurally Hard to Reconcile

Meta runs more parallel data systems than any other ad platform. The Marketing API, Ads Manager UI, Events Manager, Conversions API, and the reporting warehouse that feeds Ads Manager each compute metrics on different schedules, with different attribution windows, and through different aggregation paths. A single ad account can legitimately show four different numbers for the same campaign on the same day — and Meta's own documentation confirms the divergence.

Layered on top: iOS App Tracking Transparency, Aggregated Event Measurement's 8-conversion-per-domain cap, statistical noise added to conversion modeling, and a Conversions API that ships raw server-side events that must be deduplicated against the browser pixel. Each mechanism is documented in isolation. None of them compose cleanly. The result is that enterprise Meta data is the one most likely to be questioned in the CFO review — and the one most likely to stall the agency-client QBR.

Challenge #1 — API vs. UI Metric Discrepancy

You query the Marketing API and get one set of numbers. You open Ads Manager and get another. Spend differs by a few percent, reach differs more, and action/conversion counts can differ by double digits for the same campaigns over the same date range. This is the first reconciliation ticket most enterprise teams file.

Problem

Finance, performance marketing, and BI each believe they are looking at authoritative Meta data. Finance opens Ads Manager. Performance marketing exports from the Marketing API. BI blends API data with GA4. Three teams, three numbers, no shared source of truth — and no defensible answer when the C-suite asks which is real.

Why it happens

Meta's Marketing API and Ads Manager UI do not read from the same materialized tables. They hit different internal pipelines with different freshness SLAs and different aggregation logic. Three structural factors compound the gap:

• Attribution window defaults differ. API and UI can apply different defaults (7-day click vs. 1-day view vs. unified attribution) unless you pin them explicitly on every call.
• Statistical modeling for privacy-impacted conversions. Meta injects modeled conversions to compensate for ATT-driven signal loss. The UI and API can surface different modeled slices depending on when the query runs.
• Reach is computed through separate systems. Meta documents this openly — API reach and UI reach are independent calculations and will not match.

The Fix

You cannot fix this inside Meta. Fix it at the extraction and governance layer: pin attribution windows on every API call, persist the exact parameters used to pull each dataset, and stand up a governance layer that compares API output against Ads Manager exports on a schedule and surfaces drifts above a threshold. Across brands running this pattern, finance-vs-marketing reconciliation disputes drop to near-zero once governance is wired in.

Challenge #2 — Cross-Channel Attribution Conflicts

Meta claims credit for a conversion. Google also claims credit for the same conversion. GA4 attributes it to organic. Your CRM attributes it to a sales-assist email. All four are looking at the same user action, and all four can be defensibly right inside their own attribution model.

Problem

Every ad platform reports conversions using its own last-touch-within-window logic, with overlapping attribution windows and different click vs. view weighting. Sum the platform-reported conversions across Meta, Google, TikTok, and programmatic, and the total routinely exceeds actual conversions by 20% or more. Subtracting one platform's claim from another is not statistically valid — teams discover this the hard way when the quarterly number stops matching the CRM.

Why it happens

Platform-reported conversions are by design not mutually exclusive. Meta's attribution engine sees a last-click it served and claims the conversion. Google's attribution engine sees a last-click it served 15 minutes later and also claims it. Both are true inside their own world. The platforms are not communicating; there is no arbiter. Stitching a single journey requires a user-level event stream that all platforms feed into, deduplicated by a stable identifier (GCLID, FBCLID, hashed email, or first-party user ID).

The Fix

Build a multi-touch attribution layer in the warehouse. Pull platform-reported conversions for spend justification and operational optimization, but anchor the single source of truth for conversion counts to first-party CRM or server-side analytics events joined to platform click IDs. Report platform-claimed and warehouse-attributed conversions side by side so the magnitude of over-claiming is visible rather than hidden.

For agencies: the attribution conflict compounds per client. Each client runs its own CRM, its own GA4 property, and its own preferred attribution model — you are reconciling three sources of truth across 20+ clients simultaneously. Agencies that standardize on warehouse-side attribution per client (deduplicated by click ID joined to the client's first-party events) stop the weekly argument at the source and defend platform spend on each client's own terms.

Challenge #3 — Attribution Window Data Settling and the 72-Hour Lag

You pull Meta conversions for yesterday on Monday. Tuesday they are higher. Wednesday they are higher still. By Friday the number has moved 15% from what you reported on Monday morning.

Problem

Daily performance decks, automated bid-pacing, and weekly finance close all assume numbers are final. They are not. Meta conversions keep settling for at least 72 hours after the day ends, and for attribution-window-extended events they can continue moving for up to 7 days. Any dashboard built on yesterday's pull is reporting a number guaranteed to change.

Why it happens

Three mechanisms produce the lag:

• ATT modeled conversions arrive late. Meta's privacy-preserving measurement waits for enough aggregated signal before releasing modeled conversions into the attribution window — often 24 to 72 hours.
• Conversions API events can arrive days late. Server-side events from enterprise stacks are batched, retried, and sometimes replayed after outages.
• Meta's attribution engine itself reprocesses. Last-click attribution can be reassigned as later signals arrive within the attribution window.

The Fix

Stop reporting same-day or next-day Meta conversions as final. Snapshot conversion counts at multiple timestamps — T+1, T+3, T+7 — and display both the initial pull and the settled number. Build a maturity curve that shows how much a conversion count typically moves between T+1 and T+7 for each campaign type so stakeholders calibrate expectations. Automate the resnapshot; never rely on a single one-time pull.

For agencies: budget pacing against unsettled conversions is the single biggest source of client-invoice disputes. You pace on Monday's numbers; Friday's invoice shows 15% more conversions and the client asks why pacing is wrong. Running pacing on T+1 numbers without a T+7 snapshot is effectively invoicing from data guaranteed to restate. Snapshot at T+1/T+3/T+7 per client account and report settled numbers to the client — the disputes stop before they start.

Challenge #4 — iOS 14 / ATT Privacy Impact on Tracking

Apple's App Tracking Transparency (ATT) didn't just reduce Meta's tracking — it restructured the entire conversion reporting surface. Years in, most enterprise teams still work around the consequences every week.

Problem

Industry-reported ATT opt-out rates run in the 50–65% range, with some verticals higher. On the Meta side, this means the pixel cannot fire a deterministic conversion event for a large majority of iPhone users. What you see in Ads Manager is a blend of deterministic events, modeled conversions, and Aggregated Event Measurement (AEM) roll-ups — each with its own reliability profile. iOS conversion counts cannot be trusted as raw data. They are statistical estimates.

Why it happens

ATT forced Meta to build a privacy-preserving measurement stack on top of an ad network originally designed around deterministic pixel tracking. Four constraints reshape the data:

• 8 conversion events per domain cap. AEM limits you to 8 prioritized events. Additional events are dropped.
• 72-hour reporting delay on AEM conversions.
• Attribution window collapse — 28-day click is gone for iOS; you are limited to 7-day click / 1-day view.
• Modeled conversions are statistically injected with noise to preserve privacy.

The Fix

iOS conversion counts cannot be recovered by any single measurement source. The approach that works is triangulation: pull Meta pixel data, Conversions API data, and your first-party warehouse events, join them on hashed email and click ID, and reconcile the three independent signals into a single conversion ledger. For channels where ATT opt-out is concentrated (social, app-installs, mobile commerce), expect to continue running a blended methodology — deterministic where available, modeled with guardrails where it is not.

Challenge #5 — Custom Conversions Missing from the API

Your CMO's weekly deck runs on a dozen custom conversions — lead-quality tiers, high-intent product views, multi-step funnel milestones. You set them up in Events Manager. They appear in Ads Manager. But when you pull the API, many are incomplete, labeled differently, or missing entirely.

Problem

A full production Meta reporting stack depends on custom conversions exposing the same names, structures, and counts in the Marketing API as in Ads Manager. In practice, the API exposes custom conversions through a set of action breakdowns that do not always line up with what Events Manager displays. Newly-created custom events can take time to propagate; renamed events sometimes keep their old internal ID and show up under a label nobody expects.

Why it happens

Custom conversions are a UI-layer abstraction built on top of Meta's underlying event infrastructure. The API exposes the underlying actions (offsite_conversion.custom.* and similar) rather than the friendly custom-conversion names you configured. If your custom conversion is an AEM-prioritized event under the 8-event cap, API behavior can diverge further — lower-priority events may be dropped from some iOS traffic entirely.

The Fix

Maintain an explicit mapping between the custom-conversion names in Events Manager and the action keys the API returns. Version the mapping. When a marketer renames a custom conversion, the data pipeline catches the change rather than silently dropping a column. For AEM-constrained accounts, tier custom conversions deliberately into the 8-event cap with a documented priority order and a review cadence.

For agencies: custom-conversion configurations vary by client, and a mapping change in one client's Events Manager can silently corrupt cross-client benchmark reporting. Agencies need a per-client version-controlled mapping between Events Manager and API action keys, with change detection that flags when a client renames or reorders AEM priority — not a single global mapping that breaks when one client's setup drifts.

Challenge #6 — Breakdown Incompatibilities

You want to report spend by publisher_platform (Facebook vs. Instagram) and device_platform (mobile vs. desktop) and action_type (link clicks vs. video views) in a single query. The Marketing API rejects the request. You learn, by trial and error, which breakdown combinations Meta actually allows.

Problem

Meta's Marketing API has a sparsely documented matrix of which breakdowns can be combined. Request an unsupported combination and you get a generic error. Teams waste engineering cycles mapping the matrix by hand, only to rediscover a year later that Meta has silently changed which combinations are allowed. The volume of “facebook api breakdown not working” long-tail searches is a diagnostic in itself.

Why it happens

Breakdowns are not free. Each additional breakdown multiplies the rows Meta has to aggregate and precompute. Some combinations would be computationally prohibitive to offer in real time, so Meta simply does not. The matrix reflects what Meta's internal reporting warehouse precomputes, and it evolves as Meta's infrastructure changes — which is why a query that worked last quarter can break this quarter.

The traps most teams hit:

• action_type with publisher_platform is restricted — many action breakdowns cannot be combined with placement-level dimensions.
• device_platform with impression_device can return duplicate rows that look wrong but are technically valid.
• age + gender + placement + action_type in one query often exceeds limits.

The Fix

Build a compatibility map as data, not tribal knowledge, and have the extraction layer fall back automatically: if a four-breakdown request fails, split it into two three-breakdown requests and reconcile. Persist every rejection with the exact breakdown combination so when Meta updates the matrix, you know within a day rather than a quarter.

Challenge #7 — Conversions API (CAPI) Gotchas

CAPI is the post-iOS solution — server-side conversion events that don't depend on the browser. But CAPI is designed to complement the pixel, not replace it, and the complement is where enterprise teams lose weeks.

Problem

The same conversion can be logged by the pixel on the browser and by CAPI on the server. Unless both events carry a matching event_id and are within Meta's deduplication tolerance, one of two things happens: the conversion is counted twice (inflated numbers the CFO will catch) or Meta over-deduplicates (missing conversions the CMO will catch). Event Match Quality (EMQ) is opaque; it tells you the score is low but not which parameters failed.

Why it happens

Deduplication depends on exact matching across event_id, timestamp, and a set of hashed user parameters. Any inconsistency — timestamp format drift, event_id generated differently on the browser vs. the server, a missing hashed-email field — breaks dedup silently. The blast radius compounds because multiple systems (tag manager, server-side analytics, CDP) are all pushing events into Meta at once.

The Fix

Treat CAPI deduplication as a data-engineering problem, not a marketing-ops checkbox. Instrument event_id generation in a single place (ideally your server-side event collector), persist both the pixel and CAPI event streams in the warehouse, and run deduplication logic transparently where the analyst can inspect and audit it. Monitor EMQ by event and alert on drops rather than reviewing it quarterly.

Challenge #8 — Instagram-Specific Data Gaps

Instagram lives inside Meta's ad platform, but Instagram-native metrics — story completions, reel plays, saves, shares, profile visits driven by ads — arrive through a different lens than standard Facebook feed metrics. Enterprise teams investing meaningful spend on Instagram Reels or Shopping routinely discover the Marketing API is missing the metric they built their reporting around.

Problem

Three patterns repeat in enterprise Instagram engagements:

• Reels engagement metrics (plays, watch time, saves) are exposed inconsistently across the Marketing API and the Instagram Graph API.
• Shopping and product-tag attribution requires stitching Instagram Graph API events to Meta ad-level data — a join Meta does not do for you.
• Creator and branded-content metrics sit behind a different API surface with different permissioning and data freshness.

Why it happens

Instagram and Facebook are unified in Ads Manager but not in the underlying APIs. Historical reasons: Instagram's organic data surface (the Graph API) predates its full integration into the Marketing API, and Meta has never fully reconciled the two. For Reels specifically, Meta has added metrics iteratively, which means a metric available in the UI this quarter may not appear in the API for another quarter.

The Fix

Plan the Instagram data model as a two-API join up front. Pull ad-level performance from the Marketing API and Instagram-native engagement from the Graph API, and stitch them on creative ID and post ID in the warehouse. Do not rely on the UI's unified view — the underlying API surfaces are distinct and will diverge.

Challenge #9 — Data Freshness and Reporting Delays

Ads Manager shows same-day data. The API returns same-day data too. But the same-day data in the API is not the same as the same-day data in the UI, and neither is final.

Problem

Freshness inconsistency means an automated bid-management script reading from the API can see a different picture than the performance marketer reading from Ads Manager at the same moment. Combine that with the 72-hour settling lag from Challenge #3 and the CAPI event-arrival lag from Challenge #7, and any dashboard built on “latest available” data is reporting a moving target.

Why it happens

Meta runs multiple reporting pipelines with different SLAs. The Marketing API hits a materialized view refreshing on one cadence; Ads Manager hits a reporting warehouse refreshing on another. Under normal load these converge within a few hours. Under peak load (Black Friday, Super Bowl, major platform incidents), the gap widens and the API can lag several hours behind the UI.

The Fix

Standardize on a freshness contract: every dashboard and every automation declares the maximum lag it tolerates. Monitor actual lag as a first-class metric (time between event and its appearance in the warehouse) and alert when the lag breaches the contract. Never let a bidding or pacing system act on data whose freshness is unknown.

Challenge #10 — Multi-Client Business Manager Management at Scale

Agencies managing 20+ clients on Meta don't have one Business Manager — they have one BM per client, each with its own ad accounts, pages, pixels, CAPI endpoints, and permissions. Meta's API has no native abstraction for “an agency's entire book of business.” Every operational task is per-client, every auth flow is per-client, and every data-isolation guarantee has to be engineered rather than inherited.

Problem

Three agency-specific failure modes dominate:

• Client account delegation is fragile. A client grants the agency Business Manager access to their ad account. When the client's internal admin changes, rotates, or fires the person who granted the delegation, the agency's access cascades silently. The Meta pipeline stops returning data — and the first signal is usually a confused account manager noticing a flat line in a dashboard.
• Cross-client data isolation is not automatic. The agency has one extraction stack pulling from N clients. A single misconfigured query or schema collision can leak Client A's spend into Client B's report. The isolation guarantee has to be enforced in the warehouse, not by Meta's API.
• Per-client reporting at scale is a workflow problem, not a data problem. Twenty clients means 20 branded reports, 20 attribution configurations, 20 different definitions of “success.” A single analyst hand-rolling this spends most of the week on formatting rather than analysis.

Why it happens

Meta's Business Manager model was built for brands managing their own ad operations, not for agencies managing many brands on behalf of clients. Agency tooling is layered on (Agency Ad Accounts, partner permissions) but the underlying primitives — auth, pixels, CAPI, custom conversions — remain per-BM. There is no native “agency view” that rolls up data across clients because Meta's API doesn't have the concept. Every agency that scales past ~10 clients has to build that roll-up layer themselves or adopt a managed layer that already has it.

The Fix

Stand up a per-client tenancy model in the warehouse: one schema per client, enforced isolation on every query, and shared transformation logic that runs identically across all clients but never mixes their data. Monitor per-client token health and delegation status as a first-class observable — don't wait for an account manager to notice the flat line. Template the client-facing report surface so new clients onboard with the same 20 dashboards, the same attribution model, and the same freshness SLAs as every other client — varied only by the parameters that genuinely differ per client.

Enterprise and Agency Playbook — Unified Meta Data Reconciliation

The ten challenges above share a single architectural pattern: Meta's data cannot be trusted as final, and cannot be reconciled inside Meta. The reconciliation layer sits between Meta and the warehouse, built on six principles.

Six Principles of a Meta-Safe Data Architecture

1. Pin every API parameter. Attribution windows, breakdowns, fields, date ranges. Persist the exact request so the response is reproducible.
2. Snapshot conversions on a T+1/T+3/T+7 cadence. Store all versions. Report the settled number, not the first pull.
3. Deduplicate CAPI at the warehouse, not at Meta. Keep both raw streams. Make dedup auditable.
4. Join Instagram Graph API with Marketing API. Do not rely on the UI's unified view.
5. Govern the API vs. UI delta. Alert when it exceeds your tolerance. Do not wait for finance to find it.
6. Make freshness observable. Every dashboard, every automation, every alert declares its SLA.

The Reference Architecture

The reconciliation layer has five components: an extraction engine that respects Meta's rate limits and handles breakdown incompatibilities automatically; a transformation layer that normalizes custom conversions, attribution windows, and Instagram joins; a deduplication layer for CAPI; a governance layer that monitors API vs. UI drift, freshness, token health, and dedup ratios; and an observability layer that surfaces each of these as first-class metrics a data team can alert on.

Teams that build this themselves typically spend 4–6 engineer-months on the first pass and keep 1–2 engineers on maintenance. Teams that adopt a managed reconciliation layer like Improvado typically cut that to days not weeks for the initial rollout, with no ongoing engineering cost dedicated to Meta specifically — the connector, governance, and agentic analytics layer are already in place.

Adoption Sequence

The rollout sequence that works across brands and agencies we see running this architecture:

1. Week 1–2: Stand up unified extraction. Pin parameters. Persist lineage.
2. Week 3–4: Turn on T+1/T+3/T+7 snapshotting and CAPI dedup at the warehouse.
3. Week 5–6: Wire governance — API vs. UI drift, token health, freshness SLAs.
4. Week 7–8: Layer agentic analytics on top so marketing analysts can ask Meta reconciliation questions in plain English and get grounded answers.

If you want us to walk through how this architecture would apply to your specific Meta estate — enterprise or agency — we'll map it in 30 minutes on a working session and share the spec afterward. Book a review.

FAQ

Why does the Meta API show different spend than Ads Manager?

The Marketing API and Ads Manager read from different internal data pipelines with different refresh cadences and different default attribution windows. Meta has confirmed that reach and some spend metrics are calculated through separate systems and will not match exactly. The reliable fix is to pin attribution windows explicitly, persist query parameters, and monitor the API-vs-UI delta as a governed metric.

How much conversion data did iOS 14.5 actually remove?

Industry-reported ATT opt-out rates are typically 50–65% on iOS. For enterprise advertisers, this translates to roughly half of iPhone conversions being modeled rather than deterministic. Meta compensates with Aggregated Event Measurement (AEM) and modeled conversions, but these carry statistical noise and a 72-hour reporting delay. A triangulated measurement stack (pixel + CAPI + first-party warehouse) typically surfaces 15–30% more reconcilable conversions than pixel-only reporting.

How often do Meta access tokens expire?

User access tokens expire after roughly 60 days. System user tokens for Business Manager are longer-lived but can invalidate silently when ad account permissions change, Business Manager ownership transfers, or an employee leaves and their access is revoked. Enterprise pipelines should monitor token health as a first-class observable and alert before expiry.

Can I still get 28-day click attribution from Meta?

For iOS traffic, no — 28-day click is gone and you are limited to 7-day click / 1-day view. For non-iOS traffic, longer windows remain available. Enterprise reporting should make the attribution window an explicit parameter on every pull and never assume a default.

How does Improvado handle Meta's rate limits?

Improvado's extraction engine manages Meta rate limits automatically — intelligent queuing, prioritization, exponential backoff, and parallelization across ad accounts within Meta's tiered limits. Backfills and multi-account extraction that take days when self-built typically complete in hours on Improvado.

What's better — Meta pixel or Conversions API (CAPI)?

Neither alone is sufficient at the enterprise tier. The pixel gives you browser-side deterministic events (where the user has consented); CAPI gives you server-side events that survive iOS ATT and ad-blockers. Best practice is to run both and deduplicate at the warehouse using event_id matching, with Event Match Quality monitored as a first-class metric.

Why do my Meta conversions keep changing days after the fact?

Three mechanisms produce the lag: ATT modeled conversions arrive 24–72 hours after the event, CAPI server-side events can arrive days late, and Meta's attribution engine reprocesses last-click assignments as later signals arrive within the attribution window. Enterprise reporting should snapshot conversion counts at T+1, T+3, and T+7 and report the settled number.

Which Meta breakdowns can I combine in a single API request?

Meta's breakdown compatibility matrix is sparsely documented and evolves over time. Common restrictions involve action_type combined with placement-level dimensions (publisher_platform, device_platform, platform_position). The practical fix is to maintain the compatibility matrix as live data, auto-split incompatible requests into supported queries, and reconcile the pieces.

How do I reconcile Meta-reported conversions with GA4?

Meta and GA4 use different attribution models (last-touch-within-window vs. GA4's data-driven attribution) and different deduplication logic. Summing platform-reported conversions across channels routinely overcounts total conversions by 20%+. Anchor a single source of truth in your warehouse — CRM events joined to click IDs — and report platform-claimed and warehouse-attributed numbers side by side.

Why are my Instagram Reels metrics missing from the Meta API?

Instagram and Facebook are unified in Ads Manager but not in the underlying APIs. Reels engagement (plays, watch time, saves) is exposed inconsistently between the Marketing API and the Instagram Graph API. Pull from both APIs and join on post ID and creative ID in the warehouse.

What is Event Match Quality (EMQ) and why is it low?

EMQ is Meta's score for how well your CAPI events match with Meta's user graph. Low EMQ usually means missing or inconsistent hashed user parameters (email, phone, click ID) or event_id mismatches between the pixel and CAPI. Enterprise teams should instrument event_id generation in a single place — typically a server-side event collector — and monitor EMQ by event type with alerts on drops.

How do I handle multiple Business Managers across brands or regions?

Meta has no native API for cross-Business-Manager reporting. Each BM requires separate authentication and separate data extraction. Enterprise brands with multi-region or multi-brand structures should standardize on system user tokens per BM, extract each BM into a shared warehouse schema, and reconcile at the warehouse level — not in Meta.

How should an agency manage 20+ clients on Meta without access breaking?

Treat Meta access as a first-class observable: monitor token validity, Business Manager delegation status, and per-client pipeline health, and alert on loss-of-access before an account manager spots a flat dashboard. Enforce cross-client data isolation in the warehouse (one schema per client, schema-aware queries), not by relying on Meta's API.

What does a Meta data audit actually cover?

A Meta data audit typically covers the API-vs-UI delta, attribution window settings, CAPI deduplication ratio and Event Match Quality, custom conversion mapping between Events Manager and API action keys, Instagram Graph API coverage, token health, and freshness SLAs. The deliverable is a written architecture spec that finance, marketing, and data engineering all sign off on.

How long does it take to build an enterprise Meta reconciliation layer in-house?

The typical in-house build is 4–6 engineer-months for the first pass with 1–2 engineers on ongoing maintenance. Managed reconciliation layers reduce the rollout to days not weeks, with no ongoing engineering headcount dedicated to Meta specifically.

Does Improvado work with Meta's Conversions API?

Yes. Improvado extracts both Meta pixel and CAPI event streams, deduplicates at the warehouse with transparent, auditable logic, and monitors Event Match Quality. Dedup decisions are inspectable by the analyst rather than hidden inside Meta.

Can AI agents query my Meta data directly?

Yes. Improvado's AI Agent exposes reconciled Meta data (alongside 1,000+ other connectors) to AI agents over MCP. Analysts can ask questions like “why did conversions for campaign X drop on Tuesday” and get a grounded answer that joins Meta, CAPI, and warehouse signals.

What's the single biggest Meta reporting mistake enterprise teams make?

Treating the first API pull as final. Meta conversions settle for at least 72 hours — same-day and next-day numbers are guaranteed to change. Any dashboard or automation built on an unsnapshotted pull is reporting a moving target. The fix is T+1/T+3/T+7 snapshotting, implemented once, monitored automatically.

Does Improvado support both enterprise brands and agencies?

Yes. Enterprise brands use Improvado as a unified agentic data pipeline for Meta plus 1,000+ other sources with governance and AI Agent built in. Agencies use the same platform with per-client workspaces, enforced data isolation, per-client token health monitoring, and templated client reporting — deployed in days not weeks.