As someone who has built several top 1000 trafficed websites over the past decade here is what the publishing industry definitely needs out of an analytics program.

1. Please give me a report that can prove that my user traffic is real.

2. Please give me a report that can prove that the traffic is healthy.

I know that I can get this from analytics now, but it needs to be the focus.

For a decade I've competed against content websites that for the most part game seo traffic, build click traps and generally pollute the Internet with secondary source content. I've always had fairly large audiences on my sites, with healthy 50% returning visitor rates. However, when it comes to getting ad dollars, I always lost to competitors who had much larger volume mostly because they were either buying meaningless inbound links or using some other scam like click trap "we recommend this hot girl talking about prostate cancer" photos to goose their numbers. Meanwhile we'd create quality content and my sites would have hundreds of comments, while theirs would have very little. It didn't matter that my audience was more engaged, advertisers bought volume.

I just need something that I can show to an advertiser (or even better, that they have access to and can compare) that says... hey, this website isn't a constructed fabrication made to fake volume and take your money you sucker. This is a real website.

A lot of the industry right now is based upon buying links from aging front door portals (Yahoo, MSN, AOL) which still do ungodly amounts of traffic with a mostly Internet illiterate audience. Sites buy these links, convert them into CPM click traps on their targeted magazine sites and sell their inventory to advertisers who don't know that the whole thing is shell game. They think they're buying ads on a hot new site with explosive growth.

I started saving all my page views in a postgresql database. Schema is pretty simple.

I have the following tables:

    sessions
      session_id (uuid type)
      created_at
    
 
    page_views
      page_view_id
      session_id
      created_at
      site_id
      path
      query_string (hstore)
      user_agent
      referral_url
      ip_address
      user_id
      http_method (get, post, etc)
      details (hstore, used to tag page views/actions)
   

This allows me to simply query all my page views against data in my live database. I can see the path a user took to place an order. I can easily integrate a/b tests. If someone uses a coupon on the site and we want to see if they later came back and viewed/purchased more, we can easily write a sql query to figure that out. We can simply figure out lifetime customer value, even if not logged in. If we're getting a large amount of traffic from a certain affiliate, we can alert our staff.

It's really awesome to be able to have your data in the same place. Having analytics data spread out to GA made it difficult to match that data against ours. If we need to scale out to multi-terabytes, postgres_fdw will make querying against the analytical database simple.

Since we're also tracking affiliate purchases to pay out commissions, I also have another table that that stores additional information about a page view if they came from an affiliate site (click id, the affiliate network, etc).

Here's the plpgsql function I use for saving the sessions and page views: https://gist.github.com/joevandyk/f63523cdd1a3aa75d0ec

The last paragraph is important. I spent some time earlier this week when I learned about Universal Analytics -- but quickly discovered that UserID tracking hasn't shipped yet.

Can anyone on the GA team speculate about a release date for the uid bits?

I was not aware that the new analytics would track users. One interpretation of section 7 of the Google Analytics Terms of Service is that tracking individuals is not allowed:

http://www.google.com/analytics/terms/us.html

  > You will not [...] use  the Service to track, collect or 
  > upload any data that personally identifies an individual 

http://productforums.google.com/forum/#!topic/analytics/tTaq...

  > you cannot store names or ip addresses in a custom var, 
  > but you can store ids that need your backend to resolve 
  > into a person identification

This article is really making a big deal out of nothing. All the "major issues" brought up here only create problems in edge cases. When you're trying to drive growth or understand your users (the purpose of metrics at the end of the day) you should not be focused on edge cases.

In most cases the reason you care about tracking logged-out -> logged-in behavior is to measure onboarding behavior, understanding what the user does pre-signup so you can do a better job of driving signups. Signup is not a multi-client process in the common case so being able to track multi-client behavior pre-signup doesn't really matter at all.

My gripe about google universal analytics or analytics.js vs ga.js is

broken backwards compatibility (cookie data is no longer stored in the same way) this was an interface many add/systems used and depend on from the days of Urchin.

Otherwise, new interface is pretty slick, features look good, the API to send data server side is so much nicer.

broken compatibility just kinda sucks though

> For one, there can’t be 2 [clientID, userID] couples with the same userID: with the way mixpanel does things, this is essentially a technically impossible scenario (...) And yet one user can access your site through different clients, leading to a systematic overestimation of the number of visitors hitting your site.

Really? Anyone can confirm this behavior? I'm pretty sure KissMetrics doesn't have this limitation.

Last I checked User based analytics is directly against the Google TOS. You are not supposed to store any identifying information about specific users, probably because Google has been under privacy scrutiny. So not only is google not for user based tracking they prohibit it, making them a real non-starter in any case.