Join our Community in its new Home - The Datorama Trailblazer Community Group!

It's been an amazing 3 years coming together in this forum to collaborate, innovate, support, and inspire each other about our shared usage of Datorama. While this is not quite a goodbye, we are excited to announce that we are getting a fresh start in our new home within the Salesforce Trailblazer Community. We have a ton of fun new content planned and you may even see the revival of some of our most popular posts from the past few years.

We’ll be keeping this group around for a bit for you to peruse, but as of November 15, we will no longer be allowing new posts or comments. Be sure to join our new group at to keep the conversation going.

We can’t wait to see you there!

FB Reach by Campaign


  • _ben_easley_ben_easley SFOSYS_ADMIN IMG42
    How KDM,

    I would suggest reviewing a monthly reach solution that was previously posted here:

    If you don't have an API licensed user for your datorama account, you could also implement a rolling 30 or 31d reach report at the campaign level.  You'd implement a custom FB Ads data stream like the article above, except you'd need to set the sliding window to 30d (or 31d) and the statistic span to 90d.  This way you can see the last 30d of reach for a given campaign for a specific date.  For example, if you looked at the reach for "My demo campaign 123" on Mar 31, you would see the aggregated reach data covering the period Mar 1 to Mar 30  (assuming you set the sliding window to 30d)    

    If your aim is to get the reach data aggregated at the campaign level over the lifetime of a campaign, you're going to run into some technical issues, and let me explain why:

    The Sliding Window determines the last N days to process data for a given data stream.  So if the sliding window is set to 10 for a FB data stream, the stream will retrieve the last 10 days of data every time it is scheduled to retrieve data.  Why is this an issue?  It's because the maximum sliding window that can be attained for an FB ads data stream is 31 days.  If all of your campaigns are 31d or less, then you could actually report on reach at the campaign level.  However, if you have 60 day campaign, your reach data set will be spread across two separate API jobs and log files.  Why is this an issue?  Well, it's because your reach data is split into two separate queries (API jobs)  and then your reach data is not deduplicated.  Let's assume campaign 123 ran from Feb 1 thru Mar 31, and let's assume I was exposed to an add on Feb 1, and then to another ad on Mar 20.  I should only be counted once, but in fact I would be double counted twice because I show up in the API job spanning Mar 1 - Mar 31, and then a second time for the API job covering the period Feb 1 - Feb 28.  

    As you can see, the primary impediment to implementing this with a FB Ads Data Stream is that you would need a much larger sliding window.  There are other technical challenges to figure out as well, such as determining the start + end dates of a campaign, but that is a moot point given the Sliding Window Issue.  

Sign In or Register to comment.