Use session_traffic_source_last_click for session traffic attribution

[umairkarel]

I noticed that the package currently uses custom logic to calculate session-level traffic parameters such as source, medium, campaign, channel_grouping, etc using last non-direct attribution.

However, Google has introduced a new field, session_traffic_source_last_click, which provides the same session-scoped traffic information using the standard last non-direct click attribution method. Leveraging this field could help:

• Ensure better alignment with GA4's attribution methodology
• Improve data consistency
• Reduce custom logic and maintenance overhead

[dgitis]

Thank you for bringing this up because it is certainly worth discussing.

There are two issues with Google's logic:

1. Sometimes, it returns nonsense that has nothing to do with the source data.
2. It decouples all of the attribution fields resulting in strange results that are inferior to our custom logic.

The second issue results in a number of strange behaviors.

One is that when you get a source / medium combination that doesn't have a campaign, then the decoupled logic will look back until it finds a campaign. This results in google / organic or direct / none with campaign values from ads and email campaigns.

Another, is when internal UTMs are in place, a session can start with google / organic and then have a click mid-session with values like internal / banner. Then, in the next session, someone arrives via direct. The last, non-direct logic will assign this session to internal / banner even though there is no session with this value.

Finally, there'a the backwards compatibility issue. This package is deployed on data that predates the advent of these fields. At most, we can add a config variable that lets you choose custom or Google attribution logic.

It is a headache when people ask why the numbers don't match, but I'm not sure that it is worth the effort.

Having said that, I think there may be an argument to create a new major version that uses all of the various new fields and tables that Google has introduced and then instruct people with legacy data to stay on the last major version. That would simplify the code base, reduce bloat, and make the package easier to implement.

[umairkarel]

I totally agree with you @dgitis, adding the config variable would be the best approach. As user can choose to use custom logic and override it if needed else choose the export fields directly.
As for the mismatched numbers, I faced the same issue while using this package. The numbers didn’t match in my case either!! and I also noticed extra source/medium values, just like in your example.

So I started digging in and discovered that Google provides these fields directly in the export. I ended up overriding some of the files from the current package to use channel grouping and other session-level traffic source fields — and the data started matching much more closely!

I’m suggesting this change because it worked well for me. Thanks!

[umairkarel]

I would love to work on this if you are planning to add these changes in the next major version!

[dgitis]

@umairkarel, @adamribaudo and I are considering moving version 7.x to drop support dbt-GA4 package tables that pre-date Google's addition of new fields and tables including the session fields that you've identified here. I've tagged this to mark this for inclusion in that release.

Let's keep the discussion going here.

The main issue from my perspective is still that the package attribution is better than Google's but using Google's means fewer concerns from stakeholders, less processing (lower costs for large implementations), and simpler code.

I'm fine with either approach but I'd like to hear what others have to say.

[dgitis]

We are looking at doing a major release that drops support for all of the legacy features that we implemented before Google.

This is one of the items that we want to consider for that major release.

Having said that, Google's documentation mentions that in the streaming export "New user and new session traffic source data is excluded from export".

What I presume that this means is that the cookies that hold all of the first_user data don't exist and, because the data is streaming, Google doesn't bother calculating this stuff. Similarly for consented mode, Google does some calculations when consent is given midway through a session and those calculations won't be done either (this is me hypothesizing based on what I understand of GA4 and how these conditions can arise; I'm not certain I'm correct).

That means that with the streaming export we will need to calculate the session attribution and user attribution values. The user won't be too hard since we know it is the first time this client_id has been seen so we just copy the session values to user.