We Keep Coding

Multiple distributed event stores for data governance working together

I play around with CQRS/event sourcing for a couple of months now. Currently, I'm having trouble with another experiment I try and hope somebody could help, explain or even hint on another approach than event sourcing.
I want to build a distributed application in which every user has governance of his/her data. So my idea is each user hosts his own event store while other users may have (conditional) access to it.
When user A performs some command this may imply more than one event store. Two examples:
1) Delete a shared task from a tasklist hosted by both event store A and B
2) Adding the reference to a comment persisted in event store A to a post persisted in event store B.
My only solution currently seems to use a process manager attached to each event store, so when an event was added to one event store, a saga deals with applying the event to other related event stores as well.

Not sure what is the purpose of your solution but if you want one system to react on events from another system, after events are saved to the store, a subscription (like catch-up subscription provided by Greg Young's EventStore) publishes it on a message bus using pub-sub and all interested parties can handle this event.
However, this will be wrong if they just "save" this event to their stores. In fact they should have an event handler that will produce a command inside the local service and this command might (or might not) result in a local event, if all conditions are met. Only something that happens within the boundaries, under the local control, should be saved to the local store.

How does Google Tag Manager extract tracking data from dataLayer?

Google Tag Manager provides the dataLayer global variable for storing event tracking information. To add a new event, you simply do a dataLayer.push({"Your data here"});, and the information is captured.
How is the information from that array being sent back to Google? Is there some kind of polling of that variable going on in the background?

This information is not being sent to Google. Everything in Google Tag Manager is evaluated client side.
You publish your Container that includes rules based in Events. Once this container is loaded into the browser that also loads all the tags, rules and macros defined on GTM UI.
When the container is loaded the dataLayer array is evaluated and replaced by an API that evaluates calls to the push method right away. This is not a common Array anymore but a custom object defined by the GTM Javascript code.
Once the push is evaluated by GTM code, it's matched to the several rules defined on the Container. Note that this doesn't reach Google again it's evaluated client side.
At least this is how it works right now. Since it's not documented I assume it can change in the future.

Pass extra data to Google Analytics

I have some good experience with Google Analytics and have been using it for years. I've done some basic tracking and some event tracking from flash and AJAX apps. I'm working on a project now that has detail pages about people, but the query string is an ID rather than a SEO-friendly URL. (e.g. bio.aspx?id=3945 vs. /bios/ursino-mark.aspx). I have the actual info about the person (like name) in ASP.NET and I'd like to somehow pass it to Google Analytics so we know more about the actual page in the report, other than just a number. I've looked into this and found Custom Variables in GA. I'm wondering if there are any other options/recommendations?

Based on the information you give in the question, Custom Variables are indeed the method you'd want to proceed with. (There's also the possibility of using the 'User Defined Variables', but their use is discouraged, as the feature is considered deprecated in favor of Custom Variables.)
In contrast to Events, Custom Variables don't create their own request to Google Analytics; instead, they define an attribute of the hits (events, pageviews, transactions) that result from the given custom variable scope. Thus, they're the best way to send extra data about something you're already tracking (ie, pageviews.)
In that sense, the best usage for you would be to set a page-level custom variable before the _trackPageview call with the name of the person in question, always in the same slot. (Since each bio page would be their own page, setting it at the page-level scope would prevent any variable-overwriting issues, as there would never be any overlap.)
In this sense, you can think of a custom variable being something that describes the page/session/visitor, rather than describing a particular interaction (which is what Events are better suited for.)

To push custom variables and events to Google Analytics use this method.
_gaq.push(['_trackEvent',
'Shopping', // category of activity
'Item Removal', // Action
]);
You can learn more about tracking events from code.google.com:
http://code.google.com/apis/analytics/docs/tracking/gaTrackingCustomVariables.html

i would consider using virtual pages in the analytics. you can report all personal pages under the same virtual directory so that you will be able to easily filter out this data. something like /personal-pages/Mark-Ursino or /personal-pages/john-smith

Analytics for 3rd party JavaScript widgets

I'm trying to find the best approach for analyics on 3rd party JavaScript widgets - i.e. tools and content that is distributed to any number of arbitrary users, who include the widgets as HTML snippets with tags.
On the same domain
Note that the widgets do not load into an iframe element that has a document loaded from the external site. Instead, they load content into the DOM of the host page - i.e. they are treated as being on the same domain as the host.
Analytics for a fragment of the host page
So, essentially, I want to track stats (such as widget views, user clicks and custom interactions within the widget), but I only want to track stats for the fragment of the host page that is the widget. I don't want to track clicks on the host page that are outside the widget.
I want the stats to be collated together, so that stats for the widget on site A will be aggregated with those of the widget on site B and site C, etc.
Questions
Is it possible to use Google Analaytics in a custom way that satisfies these requirements? Or is it not possible to separate GA from the rest of the data collected on the host page?
If it is possible to use Google Analytics, then will there be a problem if the host page already uses GA (with a different GA profile ID), or is it possible to keep them safely apart?
Are there any other analytics packages out there that are properly suited to widget stats tracking, to meet these requirements?
Or, how else would you approach the problem of obtaining stats for these widgets?

GA can be used for this, though since it is a free tool, it is a bit limited compared to the other tools out there. Example of other tools out there are Yahoo Web Analytics (YWA), Omniture SiteCatalyst, and Webtrends.
Most of the tracking tools out there have the ability to do custom link and "event" tracking. Basically what you would do is lookup the necessary snippet of code for custom link tracking and put it into a wrapper function to be executed in an onclick event (or add an event listener, etc..).
The first thing you want to do is decide what "events" you want to have for the widget(s). You mentioned counting "widget views". That's easy enough to do: just put a snippet of custom code on the page the widget is embedded on.
But beyond that...does clicking any button count as a single event? Does each button signify a different event? etc... Also, are there any custom values you want to associate with the buttons, like a product ID or description or whatever.
Another important thing to ask yourself when deciding on what you want to track is "How actionable is this data?" There is very little you can't track, but there are a lot of things that aren't very useful for making real business decisions.
For example, it sounds like overall you are wanting to try to measure user interaction with widgets. I'm sure the idea is to figure out how useful, engaging, etc... they are to people, so you can figure out whether it's worth further developing them or throwing money at them or dropping them. Fair enough. But just remember to make the events goal-oriented. Knowing how many times a user clicked a button isn't very useful because all by itself it isn't very actionable. Knowing how many times people completed a process or step, etc.. is more actionable.
Once you have made a list of what all you want to track and when, then you can start building your custom code.
With GA, there are 2 main ways to track events and metrics: through steps/goals, and through custom variables. The way you setup steps/goals with GA is to have GA match what the URL of the page is. For example, if you have a newsletter signup form, the form page might be signup.html and the confirmation page might be signup_confirmation.html. You would then setup a goal in the GA interface. The goal would match for signup_confirmation.html and you could have a step be to look for signup.html. Then you can see how many people viewed your form and completed it vs. abandoned it.
You can use this same tracking method with events, by pushing a virtual page view to GA.
Here is an article detailing how to push a virtual page view:
http://www.google.com/support/analytics/bin/answer.py?hl=en&answer=55521
But basically, whenever the event happens (like a view of the widget, click of a button, etc.. you would execute the following javascript:
pageTracker._trackPageview(’virtual url here’);
Main thing to note about this method is that you can organize/categorize/provide hierarchy to your data by passing delimited values. This will help you rollup data for different widgets/sites.
The 2nd way to record events is with custom variables. Making use of custom variables during events provides a lot of reporting possibilities and flexibility. Here is a link to how to use them:
http://code.google.com/apis/analytics/docs/tracking/gaTrackingCustomVariables.html

can entire web document be cached/archived (including the precise state of the DOM) and later reloaded?

imagine that we have loaded a complex website with lots of Javascript which loaded all sort of info via AJAX and by making computations based on user input. So, now suppose we want to archive it in such a way that we can reliably load it later on from file (maybe even without an internet connection) and study its behavior / debug it / etc. Is there a way to do this?

The browsers already do this to make the "Back" button work fast -- in Firefox it's called "bfcache". This cache lives only in memory, though. I don't know if it's possible to serialize it to a file, if yes, it would be very interesting.

I don't think there's a way to export the entire DOM state without manually looking at each piece, and storing it. There is a lot of information that goes in representing that DOM than what visible in the source.
For instance, you might want to save the window scrollbar position which is available in the window object as window.scrollX and window.scrollY. This is just one example but there's plenty of other state information to be saved including attached event handlers etc.
If you could identify the pieces that are relevant for you purposes while ignoring others, you could store it locally using Google Gears (now obsolete) or the new Local Storage introduced in HTML5 and if you are already serializing this information, you could pass it on to some server and restore it from there. The new storage mechanism in HTML5 is called DOM Storage but its a little misleading because it's just a key value pair storage where both the keys and values are strings.
Edit: This might be a different perspective on the problem but here it goes. Instead of storing the entire DOM state, you could store just the intial state, and the relevant actions that change it. To get to the final state, a replay mechanism would be used that runs each action in sequence. This is a popular design pattern known as the Command pattern. That's how multiplayer games keep each player up-to-date and in-sync by passing only the player actions like a keystroke, mouse movement, etc. instead of the entire view and the receiver applies those actions to update its state. It's a lot more complicated than that in practice but thats the crux of it.

Where would you want to store it?
Currently there's no way to store anything browser side (apart from new browser features, that very few people have installed). The only realistic solution would be in a Cookie if the DOM is small enough (this is because a Cookie can only hold a certain amount of data).
If you're looking at storing the DOM server-side, then you could use document.body.innerHTML to access the current DOM state and then send it to your server.