[gk1]

“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

[mrgreenfur]

I made a startup to try and answer one question further: connect incoming traffic to conversion events and assign credit. This is where you'll get a real bottoms-up view of your marketing effectivness.

[kirillzubovsky]

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!

[hnick]

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.

[cosmie]

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...

[2] https://snowplowanalytics.com/

[hnick]

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.

[cosmie]

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...

[shostack]

How are you seeing companies solve for view through tracking in this landscape?

[medius]

You can also check out https://github.com/medius/utm_form which can handle a lot of use cases.

(Disclosure: I created this to help my customers at https://www.terminusapp.com)

[gk1]

Nice product. I came across it recently when researching other accessible methods for capturing UTM parameters. Yours was the only other one I found.

[gk1]

I’ve used multiple marketing platforms, some costing $xx,000/year, and still haven’t seen this feature.

[redis_mlc]

Well, those parameters are intended for GA to parse, so there's several reasons for analytics competitors to not add those:

1) they make it easier for the marketer to setup campaigns with a paid competitor, and then drop the subscription for that software and monitor them with GA only

2) they make GA top-of-mind for marketers every time they look at a link with UTM in it, even in somebody else's marketing dashboard (free advertising for GA)

3) GA gets to collect campaign data, freeriding on the analytics competitor

[dmkii]

Nice work! Have you considered using localStorage instead of sessionStorage so it works across browser tabs as well?

[gk1]

I did consider it recently, but decided against it as it would mix last-touch with last-tagged-touch attribution. If you fail to tag a campaign link it would be good for the conversion to not have data, so you recognize the error and tag the link.

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 :)

[nitrogen]

Does thay difference have implications under GDPR or California's new law?

[dmkii]

No, it’s stored on the user’s own computer only. You could put an expiry date in there as well so you don’t accidentally use it after, say, 90 days.