Bootstrap the AD_IMAGE_HISTORY table on the Facebook Ads connector through individual request of missing DELETED images
AnsweredWhich connector?
Facebook Ads
Additional details
We have been investigating undesirable behavior in the Facebook Ads connector related to the AD_IMAGE_HISTORY table. (This request is the continuation of a discussion with a Fivetran technical support specialist on the support forums as part of this support ticket).
Some ad images are available through the Meta Graph API by hash, and those hashes also appear in the CREATIVE_HISTORY table, but the corresponding records are missing from the AD_IMAGE_HISTORY.
Pseudo-example:
Graph API returns a valid response:
<ad_account>/adimages?hashes=["<hash>"]
However, the destination query returns no rows:
select *
from <destination_schema>.ad_image_history
where hash = '<hash>';
For concrete examples, please see the linked support ticket.
A Fivetran representative confirmed that these hashes are returned by the Facebook API when requested individually. However, if the images have a DELETED status, they are not returned by the unfiltered `/adimages` endpoint. It appears that the API only returns ad images with an ACTIVE status in that case.
We've raised this issue with Meta to no avail.
We would like AD_IMAGE_HISTORY to include these images as well, since they are still available through the Graph API when queried by hash. At minimum, Fivetran could use image hashes referenced in related tables, such as CREATIVE_HISTORY, to fetch and populate the missing records in AD_IMAGE_HISTORY.
Having a complete snapshot of ad images, regardless of current status, is important for our use case. This would significantly improve the value of the Facebook Ads connector and avoid the need for us to ingest these images separately.
Please advise on the feasibility of this feature being implemented by Fivetran.
Thank you in advance for your consideration,
Vid S
-
Official comment
Hi Vid,
Thanks for flagging this. I reviewed your support thread with David and saw you opened a feature request with Meta.
As David said, this will be challenging to implement in a way that won't drastically slow down your syncs due to rate limiting. We'll also need to think about how we store the list of hashes to try individually during the sync, as we can't query your destination to retrieve them. This will be challenging architecturally.
We're discussing options internally. Once we have more information, I'll get back to you with an update.
Cheers,
Luke
Please sign in to leave a comment.
Comments
1 comment