Reporting across multiple conferences

Issue Summary

A common need for organizations that run events is to have multiple events (conferences, classes etc), per year, or to repeat an event annually, and generate reports (e.g. ticket sales reports, past presenter ratings reports) that span multiple events.

As an example, think of the Drupal Association which hosts ~3 DrupalCon conferences per year and likely wants to track things such as:

- Ticket sales for event X over time, as compared to ticket sales for event Y over time.
- Overall report of tickets purchased by date, price level, coupon use, etc
- Presenters at past conferences and ratings on their presentations

This issue exists to discuss and collect info about different approaches to solving this problem so that folks who are interested in providing standardized COD solutions can collaborate.

Reporting across COD sites isn't supported out-of-the-box with the 6.x COD architecture. It would be great for the 7.x version of COD to provide support for this kind of reporting, via one or more approaches:

A) Single site, multiple conferences

If you want to have multiple individual conference websites run off of the same Drupal installation, you're mostly OK for event registration, but you need to find a way to segment out the session proposals and other data between conferences, either with a solution like Domain access, Organic Groups, Noderefernece or another solution. These approaches are discussed at #1084462: Support for multiple events in one cod site (next generation feature).

With all of those solutions, the conference sites are tied to the same Drupal installation and need to share site architecture such as content types, and the result is that the sites are not as free to be customized to meet the needs of the individual event.

Benefits to a single site, multiple conference architecture

• No need to synchronize data between sites
• Single source of all data simplifies reporting (eg, who presented at previous conferences, what the results from their session evaluations)

Drawbacks to a single site, multiple conference architecture

• Less flexibility per site: Sites share same configuration, content types, likely session tracks
• COD doesn't currently support segmenting session proposals & sponsorships of multiple events within a single site (but could provide optional support

Next steps to implement solution A:

• Develop optional addon feature module(s) for COD that segment out specific conferences within an individual site.

B) Single Commerce/Registration site, Multiple conference satellite sites

Another alternative is for COD to optionally support an architecture where e-commerce related functionality happens on a central purchasing site, and relevant data is synchronized to individual satellite sites for each conference.

It would be ideal for the satellite conference site to store data (such as who is attending which event) in the same data structure (e.g Registration module registrations), regardless of whether the registration was created on the satellite or master site. That way, we could rely on the same set of features regardless of how the site is setup. (From the satellite site's point of view, it's a standard COD site with some data imported).

Note: Synchronization of information about users, such as registration, requires some level of integration with a single sign-on solution such as Bakery, shared database tables, or the proposed Drupal.org user sharing API.

The DA has already experimented with ways of synchronizing registration information with solutions like http://drupal.org/project/drupalorg_drupalcon . Currently this is setup to consume JSON outputted by http://drupal.org/project/association_drupalorg and simply grant an "attendee" role on the conference site.

A similar setup could import more specific attendee information (e.g. who is attending training x) and store it as registration module registrations on a conference satellite site.

Data such as who presented which sessions at which conference and what the post-session evaluations were, would be more complex to represent in a centralized site and would require syncing in the other direction (from the satellite back to the central site).

If we assume that registration and sponsor information is the only information that needs to be synchronized, and it only goes one way (from master site to satellite site), we greatly simplify the implementation.

The breakdown of functionality between the central site and the satellite sites would be something like this:

Central site (Focused on Ecommerce):

• Accepts payment payment
• Handles sales reporting
• Sponsorship sales and credentials collection (e.g. logos)

Satellite site - Everything else that COD currently does:

• Attendee management/checkin
• Session submission

Data to be synced between sites:

• Who's going to what event and what kind of registration status they have (Registration.module information)
• Who bought what product (Commerce.module and related modules)
• Sponsorship assets, including full sized source images
• Users associated with a sponsorship (referenced in the sponsor content type)

Benefits to a satellite site architecture:

• More Flexibility for each event website
• Simplifies cross-event reporting (for commerce-related data)
• Streamlines unselling across conferences (Registered for event A? Try event B)
• For on-site payment, you only have to secure one site to accept payment, not one site per-event

Drawbacks:

• More complex, involves synchronizing data between sites.
• Less out-of-the-box segmentation of permissions to administer orders
• Depending on reporting requirements, may require more complex data synchronization between satellite and centralized sites.

Action items for solution B

• Verify that the list above accurately describes which data we woud want to synchronize
• Generalize the drupalorg_* modules to synchronize this information in a way that works for non-Drupal Association sites
• #1597500: Implement bakery hooks to save user information (as one approach to single sign on)