// the find
fivetran/dbt_ad_reporting
Fivetran's ad reporting dbt package. Combine your Facebook, Google, Pinterest, LinkedIn, Twitter, Snapchat, Microsoft, TikTok, Reddit, Amazon, and Apple Search advertising metrics using this package.
A dbt package from Fivetran that unions ad performance data from 11 platforms (Google, Facebook, TikTok, LinkedIn, etc.) into a common schema with consistent metrics for clicks, spend, impressions, and conversions. It's the transformation layer on top of Fivetran's ad connectors — you need Fivetran syncing your ad data before any of this is useful. Aimed at data teams running multi-platform ad campaigns who want a single table to query instead of 11 different schemas.
The passthrough metrics system is well-designed: you can promote platform-specific fields (video views, shares) into the unified reports by configuring variables, with `transform_sql` to handle type mismatches and nulls where a platform doesn't have the field. The multi-connection union pattern handles the common case of multiple ad accounts on the same platform cleanly via `*_sources` variables rather than the old schema/database union approach. Integration tests use CSV seeds covering every platform combination, and the consistency tests verify that unioned output matches the sum of individual platform outputs — that's the right thing to test here. The Fivetran Quickstart path auto-detects which connectors are present and sets variables dynamically, which removes a common foot-gun.
Hard Fivetran lock-in is the obvious one — this only works if you're already paying for Fivetran connectors, making it useless for teams using Airbyte, Stitch, or direct API pulls. The timezone handling is a known gap documented in the DECISIONLOG: because ad platforms pre-aggregate data in their own timezones, cross-platform date comparisons can be off by a day at month/quarter boundaries, and the package can't fix this without raw event data. Configuring passthrough metrics across 11 platforms requires setting the variable in every upstream package individually, even if most values are just `transform_sql: "null"` — the README example runs to hundreds of lines of YAML for a handful of custom metrics. No attribution modeling or incrementality testing is in scope; this is purely a reporting roll-up, so if you want to answer 'which channel actually drove the conversion,' you're on your own.