Poor man's analytics: events, client side, server side, whatever. Set up a separate DB with one big table, many columns for properties. One server call to write an event (a row), one ajax call to write from the client, throw it wherever you need.
A bit of good old simple SQL for queries and reporting, and you are done.
I've often wondered about the efficacy of having a simple catch-all script that just tracks everything a user does on the site. I would think it would pound the database relentlessly under even modest load.
AWS comes into its own for these kinds of use cases - make a lightweight autoscaling events API on Elastic Beanstalk pumping events into DynamoDB coupled with a bunch of workers running at the EC2 spot price sorting and processing these into a traditional RDBMS = massively horizontally scalable events handling for pennies an hour.
That's why he said "Set up a separate DB with one big table" ;)
I think it can actually work quite well, provided you can setup a separate service just for analytics. It's not too unreasonable to assume there are sites already doing this since the concept of a central repository that you alone control (and isn't provided by a third party) can be appealing.
Also, you have to worry less about privacy and just concentrate on keeping your own systems and services secure.
Please don't do this! Entity-Attribute-Value tables are a nightmare waiting to happen about 98% of the time.
If there's something wrong with your DBMS where the alter table to add a row is an expensive or dangerous operation, just add a new table for every attribute, having lots of tables in a database is no worse than having lots of variables in a program.
If your DBA gets angry at you for adding new tables all the time, get a new DBA.
I have a system exactly like this at my company, with a prettier UI on top of the SQL querying. I've been considering open sourcing it for a while; I wonder if there really is a demand for this, or if it's one of those things that everyone prefers to roll themselves.