Hi Kristie,

Thanks for the detailed feature request and for including the API documentation links. 

I've created an internal ticket to add the ad_name and custom_id columns to the top_campaign_content_report table. Both are documented dimension columns of the report's item_breakdown dimension, where ad_name is Taboola's report name for creative_name (dimension columns, custom data). They're returned by the same report endpoint the connector already syncs, so no additional permissions or setup changes will be needed.

One note on how this fits our schema design. We follow a normalized model: an entity's descriptive attributes belong in its own metadata table, and report tables carry the keys, so you join across for names and labels instead of having them copied into every report row. Taboola's API currently shapes this decision the other way: their documentation exposes ad_name and custom_id only through the report endpoints, not through the campaign item endpoints, so the ticket adds them to top_campaign_content_report as the only available delivery path. The trade-off to be aware of: these are optional labels advertisers can edit at any time, so each report row will carry the item's custom name and ID as of the most recent sync, not what they were on each past date. If Taboola later exposes these fields through the item endpoints, they would move to the item metadata table with change tracking, and the report columns would be retired in favor of joining to that metadata for current values, or to its change history for the value as of the report date.

While I can't promise a timeline, I'll follow up on this thread when there's an update.

Cheers,
Luke