Email — your friendly neighborhood Analytics reporting platform (Part 3)
In part 1, we discussed the shortcomings of the visualization and analytics platforms
In part 2, we discussed how emails can solve this conundrum
Now we get a glimpse of what is possible and how it will change the manager’s perspective about analytics reports — to see them as being helpful assistance rather than an insatiable monster that you have to feed with your very soul. Lets start with how a data analytics report might look like in your inbox:
As you can see just simple key figures and optional links to further details — In other words, this is called
Putting your customer first (not technology)
We have already talked a lot about the pros and cons of this approach, but let us get down to the tech stack required to get from a database to this kind of an end solution.
DATABASE WITH ABILITY TO CREATE CALCULATED KEY FIGURES
There is no question we need a database, but for the sake of speed in such an operation it is better to create data pipelines that integrate and aggregate the data at the database level (periodically throughout the day) and keep the final key figures updated and refreshed. Any database is capable of doing that, however this can be made a lot easier if the organization is using the likes of snowflake or palantir platforms.
DATA SET WITH THE KEY INFORMATION ABOUT THE EMAIL SUBSCRIBERS
An email subscription app can be built within the Django application (discussed below) and the information it captures should be at the least comprised of the following:
- Email address
- Key items to filter for the report: For example users might want to receive information at global or regional level — if its regional, then which countries to be included — Other filters could relate to date range or inclusion or exclusion of certain sections.
- Frequency of emails: Hourly, daily, weekly or monthly
REST API
All modern front end applications connect to data through API — in short API are communication channels between two machines — We humans can read what is being sent to and fro but everything in there lovingly called JSON is meant for machine talk.
The Django rest framework (DRF) is a great app which runs within — well — a Django application. The database models can be defined through the application or already existing datasets in an existing database can be modelled inside the application — Either way the application creates the required API with the required set of filters.
BACK END
I have been working with the Django web framework (which uses python as its programming language) for the past many years and it is one of the best frameworks out there to build robust web applications that can be easily scaled up.
It is equally good for creating the link between the API and weaving the front end with the occasional computation of numbers.
A Django application typically uses the MVC (Model, View, Controller) architecture which means the data, the user interface and the logic of how users interact with the data are all well defined but separated entities — More on this here but in the Django world, views are ideally called templates which we will get to in the next section.
TEMPLATES
This is the colors and tables and fonts that make up everything that is pleasing on the eyes and easier on the brains. Templates usually have placeholders which can then be connected to the new data that is being thrown in through the API.
Pretty emails that we receive all the time in our subscribed list or the junk list are created a bit differently than the websites. They contain within themselves all the HTML and CSS that is required to make them pretty — therefore — it is not recommended to hand code such a task. Instead, there are online websites available which will do this for us — There are free templates available or we can get a month’s subscription for around $10 which is sufficient to put together a couple of templates and download the required HTML+CSS. Some good websites for this are beefree, stripo and unlayer.
JOINING THE DOTS
How to create a Django email is discussed here but in short, we need to:
- Bring in the information from the email subscriptions API to know who wants what
- Get the required numbers from each API that we configured for our calculated key figures data sets.
- Insert these numbers into the placeholders within the email template
- Attach the template to the email body
- Send it out
SETTING THE FREQUENCY AND AUTOMATING
Once the application is deployed to a server, we need to automate email creation and sending. In the simplest terms, this can be done through cronjob on Linux which is usually how all applications are deployed these days. cronjob is an ideal choice to set up the time and date and frequency of running certain commands — in our case, the Django command module commands.
So finally, we can have that cup of coffee that is well deserved and wholly satisfying. We tried to keep it general but then also had to provide some pointers towards the technical solutions. Of course, these are some tools that I have employed and there could be numerous others.
The idea was not to indulge in the technicalities of this venture but to understand what our internal customers are looking for most of the time and how to make their lives information rich without compromising their time and effort.
