-
Notifications
You must be signed in to change notification settings - Fork 6
Alerts architecture and content generation
The alerts infrastructure was originally created to provide text and email based alerts to Energy Sparks users. Alert classes from the analytics library were categorised into weekly, termly and before each holiday and would be run on a weekly basis with emails and SMS message getting sent out immediately. Current process
The alerts have evolved into a standardised interface for running analytics processing against a school. The results provide basic data such as a “rating” for the alert (i.e. is this good/bad for the school) and more detailed variable data for templating, associated charts and table data and benchmarking data for school comparison.
The “alerts” are no longer used just to send notification-type communication to users but are now used for the basis for generating the majority of the dynamic content on EnergySparks. A more general term might be more appropriate for describing this functionality but the nomenclature “alerts” has persisted.
An alert run is carried our each night that runs through each school and each alert class from the analytics library that is appropriate for the school. The results of running each alert is saved in to the database and grouped to easily identify each run that was carried out for each school. The alerts are still categorised into weekly, termly, before holiday but that categorisation is only related to the sending of emails and SMS as each alert is now run every night.
An Energy sparks admin can managed pre-defined types of content against each alert type. The management involves activating a particular type of site feature and setting the content that appears for that feature using the alert’s template variables to include calculation results from the analytics in within the content. For example, an administrator might activate email content for a “Your heating has come on too early” alert and create some email copy that includes the “time your heating came on” variable and the “money you could save” variable for alerts that have a rating of 0-3 (i.e. badly performing schools). Multiple rating ranges can be created or each alert type allowing the display of “positive” and “negative” content for the schools. Content edited by an administrator is versioned on each edit.
Once we have run the overnight alert process we pair the alert data with the latest version of the activated content from the administration process that meets the rating requirements. We add a record to the database, grouped by each school, that records what content is available for each alert type so the pairings don’t have to be calculated on the fly.
The process for sending emails and SMS is run on a weekly basis and stores the emails and SMS that are sent in a separate run.
Running the analytics code overnight allows us to record which calls to the analytics will error and which alerts are not relevant for particular schools and hide their respective content from the interface. Given the complexity of the analytics calculations and the variety in the energy data sets we have, running the analytics calculations live within a request comes with inherent risks. It also allows us to do long-running or expensive analysis at a quieter time for the server and only do quick databases fetches to get the result of those calculations when the site is being used during the day. Storing the resulting alerts and their generated content on a nightly basis forms an audit trail of the what a school would see on each day which is useful for debugging and historic analysis.
The overnight process does mean that content updates and analysis changes aren’t seen without re-generating the alerts and regenerating the content. It is possible to re-run the alert and content generation runs during the day but it can be resource intensive and slow down the servers so it not recommended on the live servers. As the energy data is only imported once a day there isn’t an expectation that content on the site will change more regularly than daily during normal running of the site (i.e. not during active development of new features)