This seems like it's just a serialized cookie, am I missing something?

One thing that would make this insanely valuable is if you had the option to follow the same rules that google analytics uses to store UTM cookies.

Since the release of analytics.js they no longer allow you to ask the ga object what it thinks the current utm variables are (as they can be overwritten, expire, etc). One might want to do this to track stuff in their own database, etc.

That means one has to attempt to model their algorithm to get it to work, and lets just say thats super annoying:

https://lh3.googleusercontent.com/8EiYEKczs9NLsuKkZjRmeygRZ1...

Thanks your suggestion. That's pretty much what the library is doing. One thing the library does is if on their first visit a user has utm codes in their URL (e.g. utm_medium) it'll store this and make it available via pursor.convert() & pursor.fetch().

Currently the library looks for 'utm_source', 'utm_medium', 'utm_name', 'utm_term', 'utm_campaign', and 'utm_content' in URL.

If I understand correctly you would like additional data collected by analytics.js made accessible via the library? I created an issue for your idea here (https://github.com/bilbof/purser/issues/1).

This is pretty cool, but it seems like it doesn't store data for multiple visits. Say I land via Google yesterday, come back today via HN, then sign up. I'd like to know all that.

Thanks. Do you mean track additional UTM codes etc. for each subsequent visit?

Is having the following data included in the object returned by purser.fetch() what you're after?

    "visits_before_conversion": 2,
    "subsequent_visits": [
      {
        "referrer": "news.ycombinator.com",
        "utm_source": "hn_post"
      }
    ]

I added this as an issue here https://github.com/bilbof/purser/issues/3

if anything OP is helping dismantle it by releasing OS code that we need but isnt maintained by a massive conglomerate that is literally integrated with the US Federal Government.