The main structure for analytics is the same as Automated Billing.
The main part of analytics deals with the "MediaAction" table. Each Media Action has a "MediaActionType". The Media Action Type would be something like "Viewed Media". Because new rows are being added for each Media Action, there is no worry for concurrency issues. There is not one single field to update at a time, so issues of "lost updates" are alleviated (A good example of this can be found here: http://stackoverflow.com/a/880815/5141403 - we solve this by not using updates but instead adding new records)
So, whenever a user scans a particular type of media, simply add a row the MediaAction table of the required type.
Some types are not available by just the server-side, and the app will have to send these. Endpoints will have to be made in image recognition to do so.
MediaActions have a nullable UserID - this is the RocReadaR App's user ID, which is any ID provided by the phone unless the app implements authentication.
Media Actions should record the IssuePage and IssuePageMedia if relevant, and the time of access. This provides access to relevant data such as Type of Media, Publication, who owns the media, the page accessed etc.
Other useful metrics that should be included include:
- GPS location if available
- Time Spent on page/looking at media
- If anything was bookmarked
These must be sent by the app to the server though!