I think you might be making the assumption that events consist of an event name plus arbitrary JSON envelope. This is a very MixPanelish view of the world - it doesn't really translate to Google Analytics, Piwik, SnowPlow, Omniture...
Really good points. I think there is definitely a way for the Mixpanel-esque API to map cleanly via a decided on spec to the GA-style API with 'category' and 'label'. We are thinking about how to solve this in the nicest way possible for the developer right now!
It's going to be really hard to make a generic, non-lossy mapping in a static, stateless JS script. Have you looked at Google's dataLayer as an alternative yet? The setup guide for SnowPlow + dataLayer is here in case it's interesting: https://github.com/snowplow/snowplow/wiki/Integrating-javasc...
The dataLayer approach seems really sound to us - here's hoping other tag management solutions move to something similar (or standardise on Google's dataLayer API).
I'd disagree that it's a natural progression to move from collecting anonymous (or at least pseudo-anonymous) use data from what your users actively do on your web site (which is very useful for measuring usage and making design improvements) to cross-referencing that with data your users did not give you for the explicit purpose of identifying them.
There was a post on here a few weeks ago where people were specifically blasting KISSMetrics for using an Evercookie style tracking system, so I'd argue that HN hasn't come up with a coherent opinion of the moral implications of analytics and conversion tracking yet.
STRONGLY disagree. The point of using analytics is to put metrics behind your decisions. You need your data to give you insights, but you need these insights to be generalized to larger demographics.
I.E. this type of person that is my potential customer doesn't convert on my landing page.
Personal targeting is a TOTALLY different thing. It's not about optimizing technology, it's about optimizing sales WITHOUT optimizing technology.
How does this script impact the performance of a site?
Specifically...
1. It includes code to load up various analytics tools even if you never use them. For example, if I only use GA and Mixpanel, do I really want to serve the bytes for all the other plugins to my users? Maybe it would be useful to only package the JavaScript that a certain site needs.
> It includes code to load up various analytics tools even if you never use them. For example, if I only use GA and Mixpanel, do I really want to serve the bytes for all the other plugins to my users? Maybe it would be useful to only package the JavaScript that a certain site needs.
It only has code that knows how to load each script, which isn't that much. So for example if you don't tell it to load chartbeat.js, it will never load chartbeat.js.
Regarding load time of pages, it's one thing we (Chartbeat) take really seriously, e.g. our default implementation waits until after onload before downloading anything and we keep our JS as light as possible. This script does, unfortunately, throw some of that out the window with it's implementation though. I'm working on my pull request already. :)
For the last question, all of the providers are initialized just like they would be normally, so GA's queue is setup already and it will just be routed the track calls.
Happy to be supporting this project at http://customer.io . A lot of folks who use other tools want it to be easier to send the same information to everyone. Thanks guys for helping us all play nicer together.
Hm, I seem to recall Google used to ban third-party wrappers in their Terms of Service, but I can't seem to find it in the ToS anymore – so either they've softened up or I have a faulty memory.
The Google Analytics provider doesn't send properties for events. The only thing the GA API providers that's even close is a "Label" which is just a string. The idea is to get as much from each provider as possible, so we just don't send properties when a provider can't use them.
Ah yep that's a good point. Trouble is it doesn't apply to all cases, and has really strict requirements, but if it's a big enough need I could totally see a .price() method that hits GA's ecommerce API and then delegates to other providers's normal event API with properties. Wouldn't be a bad way to handle it.
Maybe just pass the JSON object in as a string to the label? I personally don't think I'd mind reading "{'paymentAmount': 50, 'productColor': 'red'}". I haven't used Google Analytics for event tracking yet, though, so not sure what the UI around Labels is like.
You can customize every last bit of it, it being open source. Feel free pay them or someone else to do just that. Nobody would claim it's the prettiest, but it's open source and self-hosted, surely that counts for something? The devil will always have the shinier bling, but it's also the devil.
This looks awesome! One thing would be nice on the demo/landing site is to maybe add screenshots of how your examples translate in Google Analytics or the others. Like karolisd mentioned in his comment, I would like to see how that stuff translates or what it looks like in the respective apps. Again, great work! :)
Great library! I know that a number of companies have created a wrapper of their own exactly for this purpose.
We could contribute integration to https://bitdeli.com for those who want to build their own analytics. Is it enough to add a new provider to availableProviders?
Thanks for sharing. A useful improvement could be a build step that supplies only the metrics snippets that I want so I don't need to deliver to clients provider code I'll never use.
I would like us to use a C++ like name mangaling convention like __1cGstrcpy6Fpcpkc_Analytics.js. In this way we will never confuse version numbers, with the added advantage to run several version concurrently. I recently purchased a CDN subscription for precisely this application.
There's also Google Tag Manager. It's not itself an analytics script, but it provides a clean way to separate tags from code (one tag to rule them all). In addition, it's dataLayer acts as an intermediate store which any tag can access via macros in order to use the shared data. The SEM folks can (almost) manage the tags themselves once some rules are prepared.
When I saw this Show HN, I actually assumed it was an article about the new Google Analytics offering. (In retrospect, I should have realized that wouldn't make sense as a Show HN.)
The extra arguments are used as identifiers within the function. It's a common trick to save a few bytes since you get function scoped vars without needing the "var" keyword.
yes but it's not needed in this case, they could have reused existing variables and since clarity is not a goal (given e.g. "s=document") it wouldn't be an issue.
true, but if it aggregates multiple services, it makes more sense to have a generic name like "analytics", than for a singular service to have that name just because it's Google. still, you're right that it will probably be confusing.
edit: a reply below points out that it's hard to search for. that's actually a quite good reason why the author(s) might want to reconsider the name.
Yes this is also known as Universal Analytics and has several new features more processing on the server rather than on client side and less cookies. It's pretty awesome by the way.
I'm interested in adding SnowPlow support to this (https://github.com/snowplow/snowplow) - our tracking API is very similar to Google Analytics's.
We've just gone through the quite involved exercise of mapping SnowPlow to Google Tag Manager (http://snowplowanalytics.com/blog/2012/11/16/integrating-sno...) so I was a bit surprised in the code to see this mapping for GA events:
I'm a bit confused by this - how would I use analytics.js to pass through all the valid data that I can log in a GA event or indeed SnowPlow event - https://github.com/snowplow/snowplow/wiki/javascript-tracker...I think you might be making the assumption that events consist of an event name plus arbitrary JSON envelope. This is a very MixPanelish view of the world - it doesn't really translate to Google Analytics, Piwik, SnowPlow, Omniture...