“Grow your audience” is a stretch here. Better to say “...to see where traffic comes from.”
If you want to go a step further and see which traffic sources lead to form completions (like newsletter or app signups), I made a utility that captures UTM parameters and then inserts them into any form submitted during that session: https://github.com/gkogan/sup-save-url-parameters
That's really useful! It's actually surprising that something like this doesn't come as a default with Mailchimp forms. Just forked it and will give it a try. Thank you!
I'm pretty sure I saw this somewhere in one of the other marketing automation tools but yes it's definitely not common.
Kind of related, I saw a webinar by Ontraport recently and they were going a step further by saving google analytics IDs against contacts for deep funnel conversion tracking. The idea is they don't really care about who signs up for a free trial, they want to know who upgrades to paid within the trial period and usually the attribution is all messed up by then or they don't know who is who. So saving details and manually calling google will help to track this.
It seems there are still a lot of little tricks out there that aren't standard practice.
Yea, that combined with the User Activity API is incredibly handy. Especially useful to pull out when some anomaly occurs, and stakeholders suddenly want a particular conversion under the microscope (an unexpected enterprise user, unusually large order value, an unexpectedly frequent recurring customer, etc).
That said, all of the browsers are becoming so aggressive about cookie management that relying on the Google-set clientID is asking for pain at this point, unless you've implemented something like this[1] cookie setting service/proxy/relay. Creating your own first-party identifier (even if it's just randomly generated the same as the GA clientID) and leveraging the user-id field is far more stable.
> It seems there are still a lot of little tricks out there that aren't standard practice.
Simo Ahava's blog (linked to in [1]) is a wealth of nifty web analytics tricks (primarily focused around Google Tag Manager, Google Analytics, and a sprinkling of Snowplow[2] for the self-hosted crowd). The blog is geared at a less technical audience, but the vast majority of content is around technical nuances of analytics implementations and fairly minor coding adjustments that can be made to significantly enhance a standard implementation.
[1] https://www.simoahava.com/google-cloud/create-cookie-rewrite...
In the near future tracking won't be as easy as throwing a script from Facebook into a blog header. I wonder where it's leading. One guess I had is people will be plugging in web service calls to get the info behind the scenes and generate a first party cookie. Not sure if that capability exists yet but it does sound like your first link so I'll have a read, thanks.
Edit: I had a look through that first link, nice hack, but definitely out of reach of most small businesses. That's kind of how these things go, big players have the resources to jump a hurdle without slowing down, everyone else is left behind.
For purely analytics systems, it's already pretty easy to leverage server-side calls or an internal proxy service to route figures, which does truly mask where the data is going (but should still be disclosed in your privacy policy).
And many of them offer a hybrid approach called CNAME cloaking[1], where you CNAME a subdomain on your host to the analytics/marketing system. That way you still leverage their infrastructure but they gain access to the first-party context. Here[2] is an example of that for Adobe Analytics.
Google Analytics doesn't officially support a CNAME implementation, so the above doesn't apply. The cookie service I referenced in the parent comment is a workaround for that. The GA code is still all third-party, but you create an internally hosted microservice that will set cookies when called out to. You hit that service (even via a third party tool like Google Tag Manager), it sets an appropriately named first party cookie in it's response, and you suppress GA from triggering it's usual cookie-setting properties (which would overwrite the first party cookie and get hit with ITP restrictions).
That said, ad networks are a different beast entirely. Some of them offer a CNAME cloaking implementation option, but it's less common than you'd expect. And few if any of them allow internal proxying of the tracking data. There's simply too much potential for fraud and too little trust between parties. "Offline" conversion tracking is pretty commonly supported though, which involves having a site capture a click identifier that an ad network appends to an ad click, then in an out-of-band process, upload conversion activity to the ad network using that click id as a key. Precludes the super invasive browser-side tracking, while still allowing for attribution and media effectiveness analysis.
[1] https://dev.to/dnsadblock/cname-cloaking-or-how-are-we-being...
[2] https://docs.adobe.com/content/help/en/id-service/using/refe...
How are you seeing companies solve for view through tracking in this landscape?
From which perspective?
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.