How to use UTM parameters to grow your audience

For ad networks: the solve seems to be more disclosure from advertisers of customer PII[1]. All of the recent tracking prevention and cookie restriction measures are disruptive to last-mile analytics, but are far less disruptive to the overall strengths of device and identity graphs. Offline/out-of-band data feeds for click-through tracking don't require passing any identity data, since the click id acts as a key to connect the result to the associated click action. You don't have that for view-through, so instead you pass identity data and that's used to associate the result with the network's device/identity graph and attribute it to any relevant view through action that occurred. But because the advertiser is blind to which conversions/results may be relevant, they have to disclose all results and associated identity data in the process.

Caveat emptor: The above is based on my observations working in digital analytics in general, but my primary focus is in a different area. So there may be nuances or aspects that I'm not cognizant of.

For advertisers: The three main options tend to be either blissfully ignoring (or consciously accepting) the visibility gap, move towards the greater data disclosure of the above solution if you (and your lawyer) are comfortable doing so (which maintains the status quo for visibility while disclosing significantly more data to ad networks), or invest internally in the tech and resources to perform the tracking themselves (which gives the advertiser visibility, but keeps the ad network blind). For option three, you can self-host something like Snowplow[2] and abuse it as a poor-man's ad server for tracking purposes. The Cloudfront implementation model gives you the throughput and latency to allow you to use it as a view-through pixel, and you can then put it on any placements/networks that allow you to use an advertiser-provided tracking pixel.

[1] In hashed form, for what it's worth. The liability of disclosing raw PII is too black and white for comfort, but the security theater of obfuscated PII via hashing hasn't been tested in court well enough to put a dent in that practice.

[2] https://snowplowanalytics.com/

Might even be good, as a way to calculate how well your internal links are working in keeping the users within the property.

For example, put a link at the end of the blog post, and then track how many users clicked it, vs. how many exited on that page.

- The primary attribution model in Google Analytics is last non-direct visit prior to . Leveraging the source tracking parameters (utm_*) on internal links obliterates the usefulness of much of the built in attribution-related reporting. Relatively recent enhancements do provide visibility into multi-channel funnel flows, but the capability is compartmentalized into a few purpose-built views and don't filter back to most of the core reporting.

- It also drastically skews engagement-related reporting, overall and at a source level. A new session in GA constitutes a completely new visit. So metrics like visits per user, new vs existing users, average visit duration, pages per visit, etc all get whacked in the process. And understanding user behavior and conversion paths from any given channel becomes somewhere between torturous and impossible, as the actions performed in the "new" session aren't visible when looking at the user flow of the original session.

What you're describing is possible and commonly done, you just can't do it with the utm parameters intended for source tracking without having disastrous side effects. Custom dimensions/metrics[1] or event hits[2] are the intended ways of doing that. For developers, Google's autotrack[3] library is useful for implementing that with fairly minimal dev overhead (mainly, seeding your markup with relevant data- attributes so event hits can be auto-populated and sent). There are also a lot of third party libraries for framework-specific integrations. And for non-developers, Google Tag Manager (or any other tag manager) makes event tracking pretty straightforward to implement without dev coordination.

[1] https://support.google.com/analytics/answer/2709828?hl=en

[2] https://support.google.com/analytics/answer/1033068?hl=en

[3] https://github.com/googleanalytics/autotrack/#overview

First, we had some issues with certain sites not working at all if we added them and since our link forwarder was doing it automatically, it made life difficult. We came up with a way to turn them off on an adhoc basis but it was annoying.

Second, I didn't feel they were really moving the needle in any useful way. I don't think people are looking at their stats every day like they used to.

Third, it just felt like more litter/junk for tracking purposes. While there's no privacy aspect to it, I just felt like going a little cleaner in this regard. But.. I can't say they won't ever come back :-)

If I were to do localStorage I would only do it if the first touch and last touch tags (even if empty) were saved as separate values. That just means slightly more coding which I haven’t gotten around to. Pull requests welcome :)