Add session_traffic_source_last_click fields

[adamribaudo-velir]

Description & motivation

Google recently released a new set of fields, session_traffic_source_last_click, documented as:

The session_traffic_source_last_click RECORD contains the last-click attributed session traffic source data across Google ads and manual contexts, where available.

These fields have been added to the base package model.

Checklist

• I have verified that these changes work locally
• I have updated the README.md (if applicable)
• I have added tests & descriptions to my models (and macros if applicable)
• I have run dbt test and python -m pytest . to validate existing tests

[adamribaudo-velir]

@dgitis I ran this and noticed differences between our stg_ga4__sessions_traffic_sources_last_non_direct_daily model and Google's last_click fields. When I looked at the raw events, it looked like our model was more accurate which was weird.

I think it will only confuse people to have 2 definitions of 'session last click attribution' in the package. I suppose we should just include these fields and remove stg_ga4__sessions_traffic_sources_last_non_direct_daily just thought I'd check with you first.

[dgitis]

The advantage of our method over Google's is that we don't decouple the attribution fields where GA4 does.

So, if you see source / medium / campaign from sessions in this order from earliest to latest:

facebook / paid_social / my_fb_campaign
google / organic
direct

The last, non direct source / medium / campaign in GA4 would be google / organic / my_fb_campaign while the package would return google / organic / null.

As with my comment on the other PR, should we maybe make this configurable?

The advantages of using Google's definitions are as follows:

• data will match closer
• cheaper to calculate

While the advantage of our definitions are as follows:

• better data
• upgrading package version won't error

I'm thinking that we create a use_google_attribution_fields variable.

At this stage, the new variable only enables these fields in the base model, but in the future we could modify our various attribution models to detect this variable and return vastly different SQL depending on the configuration.

[FloDevelops]

@adamribaudo-velir can I help to push this pull request?

[dgitis]

Sorry @FloDevelops , I'll review this now. I thought that I had reviewed it.

[adamribaudo-velir]

I'll go ahead and merge. There is some overlap with these new fields and our existing 'last touch' calculated model, but offering both options does no harm. If we want to deprecate or further clarify in the future we can.