Re: UTMs Via Cookies and Inflated Lead Source Buckets

cookiemonstersa · ‎03-09-2023

Hey everyone!

We are switching from a URL Parameter model of UTM tracking to a cookie-based model. We are switching because people navigate to different URLs and the UTMs fall off before they convert. This leads to underreporting channels like paid media and paid search.

However, if we switch to a cookie-based model, won't it inflate these exact same buckets that used to be underinflated?

For example, a person visits the website via direct organic and does not convert. The person then interacts with a google search ad, and comes back to the website, this time the UTM values are cookied in and they convert. The system sees them as a person from google search.

So basically our lead source program is set up to be first conversion touch.

However if someone clicks a google ad, and then leaves the website, and comes back in via direct organic, will the cookies still be there, thus inflating the paid bucket should they convert?

SanfordWhiteman · ‎03-09-2023

Since there isn’t one definition of “cookie-based model”, there’s not one answer here.

Persisting tracking params in cookies (or in LocalStorage) merely means you can access stored data until the browser forcibly removes it. It doesn’t dictate the particular logic you use to restore that data into hidden fields.

You can apply your own expiration policies to that data: in our most recent rollout of tracking JS, the client only wanted first touch values to live for 48 hours and intermediate touches for 30 minutes. You can have different expiration policies for different sources, so some are “stamped harder” than others. It’s all about the implementation.

View solution in original post

SanfordWhiteman · ‎03-09-2023

Since there isn’t one definition of “cookie-based model”, there’s not one answer here.

Persisting tracking params in cookies (or in LocalStorage) merely means you can access stored data until the browser forcibly removes it. It doesn’t dictate the particular logic you use to restore that data into hidden fields.

You can apply your own expiration policies to that data: in our most recent rollout of tracking JS, the client only wanted first touch values to live for 48 hours and intermediate touches for 30 minutes. You can have different expiration policies for different sources, so some are “stamped harder” than others. It’s all about the implementation.

cookiemonstersa · ‎03-10-2023

Thanks Sanford!

Understood! I think for now we will be okay with "overinflating" these paid buckets, as currently, they have been massively underinflated with our current model.

We will monitor the people the system is labeling as "Paid" and then we can switch to a system style you described should it be needed!