fivetran / fivetran/dbt_pinterest
[Feature] Consider rerouting advertiser_id
- Dominant language
- No language data
- Stars
- 3
- Forks
- 10
- PR merge metrics
- No merged PRs in 30d
Description
### Is there an existing feature request for this?
- [X] I have searched the existing issues
### Describe the Feature
Currently in the following models, `advertiser_id` is brought in a relatively roundabout way:
```
pinterest_ads__pin_promotion_report
pinterest_ads__url_report
pinterest_ads__ad_group_report
```
Now that `ad group history` and `pin promotion history` source tables contain `advertiser_id`, it may make more sense to bring it in through those tables as opposed to from the `advertiser_history` table, since `advertiser_history` is joined in a more roundabout way than x_report and x_history.
Once we have data to validate this, we should consider making this change.
### Describe alternatives you've considered
_No response_
### Are you interested in contributing this feature?
- [X] Yes.
- [ ] Yes, but I will need assistance and will schedule time during your [office hours](https://calendly.com/fivetran-solutions-team/fivetran-solutions-team-office-hours) for guidance.
- [ ] No.
### Anything else?
_No response_
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by reviewing the current advertiser_id joins in pinterest_ads__pin_promotion_report, pinterest_ads__url_report, and pinterest_ads__ad_group_report, then compare the available fields in the ad group history, pin promotion history, and advertiser_history source tables. Validate whether the history tables provide consistent advertiser_id data; done means the models use the simpler source path where the data supports it and the results are validated.
Written by the indexing model from the issue text.
Assessment
- Domain
- data-engineering
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100